Technology Experience

.NET World

Programmazione, libri, snippet di codice, articoli tecnici

.NET WorldVisualStudioTips.net

[Ammy.1] Primi passi con Ammy

Per chi mi legge, se benissimo che lavoro tantissimo nel mondo delle applicazioni desktop, quindi ho a che fare principalmente con lo XAML, sia per quanto riguarda WPF che UWP. Quando ho sentito parlare di Ammy, quindi, mi sono interessato, ma la domanda successiva è stata:

devo buttare via lo XAML
ed imparare Ammy ?

 

La risposta è tranquillizzante, perchè in un progetto WPF è possibile utilizzare XAML ed Ammy, senza alcun problema. In un progetto WPF, quindi, possiamo avere delle Window/Page create con XAML, ed altre con Ammy XAML ovviamente non lo butti via, semplicemente è possibile dare un’occhiata ad Ammy e vedere se fa al caso nostro. Questo mi ha tranquillizzato, perchè questo significa in parole povere che posso integrare Ammy nei miei progetti esistenti, e sfruttarne le caratteristiche peculiari che per certi versi lo rendono più potenti rispetto allo XAML.

Quali sono queste caratteristiche?

modifica a runtime delle view
alias e mixin
JSON al posto dello XAML

 

Scriverò un po’ di posto su Ammy, perciò se siete interessati seguitemi e non ve ne pentirete.

Primi passi con Visual Studio
La prima cosa da fare è scaricare dal Marketplace di Visual Studio l’extension per il supporto ad Ammy. Da questo link scaricate il file Ammy.VisualStudio.vsix, di circa 59Kb, che aggiungerà alcuni Item Template molto molto comodi per lavorare con Ammy. Ne parleremo fra poco.

La seconda cosa da fare è creare un progetto WPF. Ammy, ad oggi, si applica solo ed esclusivamente su questo tipo di progetti. Quindi apriamo Visual Studio 2015, creiamo un progetto WPF e poi utilizziamo NuGet per recuperare il pacchetto Ammy.Lo possiamo fare attraverso la Package Manager Console oppure tramite la voce Manage NuGet Packages del nodo References. Decidete voi qual è la strada che preferite.

image

Qui sopra vedete la Package Manager Console, mentre qui sotto NuGet.

image

Fatto questo, possiamo provare a scrivere la nostra prima Window con Ammy.

Aggiunta di una Window nel progetto
Andiamo nella solita dialog “Add new Item” di Visual Studio. L’extension per Visual Studio ci ha installato 4 Item Template, che si trovano nel nodo “Visual C#”; per trovarli più facilmente, vi suggerisco di impostare l’ordinamento “Name Ascending”, oppure di fare una ricerca con “Ammy” nella casella in alto a destra. Fatto questo…

image

…troverete quattro Item Template: Ammy Application, Ammy Mixins, Ammy User Control ed infine Ammy Window. Selezioniamo quest’ultimo, poi diamo un nome, per esempio “StartWindow.ammy”.

Fatto. Notare che, come dicevo prima, il nostro progetto ha la solita MainWindow.xaml (scritta in XAML) ed un altro file, StartWindow.ammy, che è un’altra Window, questa volta scritta in Ammy.

Se facciamo doppio-click su questo file apparirà un codice sorgente simile al JSON:

Window "StudyAmmy.StartWindow" {
}

Il codice qui sopra di fatto crea una Window di WPF. Il primo elemento root di Ammy deve avere un nome, che di fatto indica il nome della classe di code-behind. Un concetto importante di Ammy è che dietro le quinte viene sempre auto-generato del codice XAML; questa cosa è importante ed utile allo stesso tempo, perchè possiamo costantemenet verificare che il codice Ammy che abbiamo scritto produca il codice XAML che desideriamo. Mi spiego meglio: clicchiamo il pulsante Show All Files nel Solution Explorer di Visual Studio. Comparirà il file StartWindow.g.xaml, che possiamo tranquillamente aprire tramite doppio-click.

Facciamo un passettino ulteriore. Editiamo il file StartWindow.ammy in questo modo:

Window "StudyAmmy.StartWindow" {
    StackPanel { Orientation: Horizontal,
    Children: [
        TextBlock { Text: "I Love Ammy!!!" }
    ] }
}

Abbiamo creato uno StackPanel orizzontale, ed abbiamo aggiunto un unico controllo TextBlock. Notare la sintassi json-like. Notare che l’Intellisense è perfettamente funzionante. Se salviamo il file e diamo un’occhiata al file “StartWindow.g.xaml”, il codice è il seguente:

<Window x:Class="StudyAmmy.StartWindow"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:ns0="clr-namespace:AmmySidekick;assembly=AmmySidekick"
  ns0:Ammy.Register="/StudyAmmy;component/StartWindow.g.xaml">
  <StackPanel Orientation="Horizontal">
    <StackPanel.Children>
      <TextBlock Text="I Love Ammy!!!"/>
    </StackPanel.Children>
  </StackPanel>
</Window>

Nota importante. NON modificate mai lo XAML direttamente. Questo XAML viene auto-generato dal file .ammy che abbiamo visto prima. Qui la lesson-learned è che Ammy non fa nient’altro che produrre XAML al posto nostro, quindi tutto ciò che era possibile con XAML lo è anche con Ammy.

Solo che Ammy ha delle feature in più, come alias e mixin che citavo prima, che semplificano e velocizzano tantissimo il nostro lavoro.

Per concludere…

Ok, diciamo che per questa prima puntata abbiamo fatto abbastanza.

Non perdete i miei prossimi post perchè ne vedremo delle belle.

Send to Kindle
.NET WorldVisualStudioTips.net

DevOps.bat : il cuore del sistema di deploy per applicazioni desktop WPF

Nel post precedente ci eravamo interrotti sul più bello, ovvero sul contenuto del file batch DevOps.bat. Questo file ha un compito tanto importante quanto banale.

Ad ogni esecuzione deve produrre le cartelle per distribuire l’applicazione WPF secondo i tre modelli: WPF, Portable Zip e per il Windows Store.

Come nel post precedente, andiamo un passo alla volta ed arriveremo al risultato finale.

Primo passo: avere un folder per ciascun deploy
Le prime righe del file DevOps.bat fanno quanto segue:

@echo TASK - Remove and rebuild directories
rmdir "ClickOnce" /S /Q
rmdir "Portable" /S /Q
rmdir "Windows Store" /S /Q
mkdir "ClickOnce"
mkdir "Portable"
mkdir "Windows Store"

Abbiamo sostanzialmente a che fare con tre folder:

  • ClickOnce
  • Portable
  • Windows Store

Direi che il nome è abbastanza esplicativo: ognuna di queste conterrà i file per ciascun deploy. I parametri del comando rmdir (ovvero /S e /Q) dicono di piallare ad ogni esecuzione tutto il contenuto delle cartelle e sottocartelle (/S), senza chiedere alcuna conferma (/Q).

Secondo passo: ClickOnce

Per generare automaticamente la cartella ClickOnce è necessario ricorrere a msbuild.

@echo TASK - ClickOnce
"C:Program Files (x86)MSBuild14.0inmsbuild.exe"
    "..CharMapMe.sln" /target:publish /p:Configuration=Release
xcopy   "..CharMapMeinReleaseapp.publish*.*"
        "ClickOnce*.*" /E /Q /Y

Il primo comando esegue msbuild.exe dicendo di compilare il file CharMapMe.sln, nella configurazione Release, generando nel contempo la pubblicazione per ClickOnce.

Il risultato di questo comando è un folder “binReleaseapp.publish” che contiene solo ed esclusivamente i file specifici di ClickOnce. Ma non mi piace che sia dentro “app.publish”. Motivo per cui il secondo comando utilizza xcopy per copiare i file all’interno del folder “ClickOnce”.

E difatti, eccoli qua. E’ sufficiente prendere questa cartella ed inviarla via FTP per distribuire a tutti gli effetti l’ultima versione dell’applicazione.

image

Missione compiuta.

Terzo passo: Portable zip

Possiamo passare alla generazione del file zip per il download Portable.

I comandi contenuti nel file DevOps.bat sono i seguenti:

@echo TASK - Portable
xcopy "....CharMapMeinRelease*.*" "..Portable"
cd "..Portable"
del "*.pdb"
del "*.application"
del "*.config"
del "*vshost*"
del "*.manifest"
"..7z" a -tzip "CharMapMe.zip" -sdel -r *.*

In breve: copio tutti i file dalla “binRelease” nella mia cartella “Portable”. Inizialmente, questa cartella conterrà anche un certo numero di file che NON è necessario distribuire: ecco perchè le righe successive vanno a cancellare i file pdb, application, config, vshost e manifest.

Poi utilizzo 7z.exe (ricordate il post precedente? si trovava nella cartella Deploy) per creare al volo uno zip con tutti i file. Il parametro “-sdel” dice di rimuovere i file dopo la creazione del file zip. Il parametro “-r” dice di includere anche i file in eventuali sottocartelle, ma non è il nostro caso.

Fatto questo, nella cartella “Portable” ottengo il file “CharMapMe.zip”, pronto da mettere online.

image

Quarto passo: Windows Store

Il terzo modello di deploy prevede la distribuzione sul Windows Store.

La prima parte di comandi necessari sono i seguenti:

@echo TASK - Windows Store
xcopy "..CharMapMeinRelease*.*" "Windows Store"
xcopy "Support*.*" "Windows Store*.*" /Q /Y
cd "Windows Store"
del "*.pdb"
del "*.application"
del "*.config"
del "*vshost*"
del "*.manifest"

Sono praticamente gli stessi visti prima per la modalità Portable. Copio tutti i file dalla “binRelease” a “Windows Store”. Poi copio tutti quelli contenuti nella cartella “Support” nella cartella “Windows Store”: adesso vi dico la ragione di questa operazione. Poi, esattamente come prima, cancello quelli superflui, che non devono essere inclusi nel package.

A cosa serve la cartella “Support”? Essa contiene 4 file.

image

  • AppxManifest.xml : è il file di manifest per l’applicazione UWP
  • *.png : sono 3 tile in diverse dimensioni per creare il package UWP

E’ un po’ OT, in questo post, raccontare esattamente nel dettaglio questo passaggio. Facciamola breve: per distribuire un’app UWP ci vuole necessariamente un file di manifest. Sempre, in ogni caso. Ma CharMapMe NON è nata come app UWP, quindi il file di manifest l’ho dovuto creare da zero, con il blocco note. Idem le immagini per avere le tile. Per maggiori informazioni su questo particolare aspetto vi consiglio di leggere questo post sul blog di MSDN Italia.

Ok, fino a questo punto ci siamo. Nella cartella “Windows Store” ci sono i file necessari per creare il package: tutti quelli contenuti in “binRelease” + file di manifest + 3 immagini per le tile. Possiamo generare il file di package vero e proprio.

"C:Program Files (x86)Windows Kits10inx64makeappx.exe"
    pack -d . -p "CharMapMe_nosigned.appx"

Eseguo il tool makeappx.exe, dicendo di prendere la cartella corrente, e di generare il file “CharMapMe_nosigned.appx”.

Poi mi duplico il file con il nome “CharMapMe_signed.appx”

copy "CharMapMe_nosigned.appx" "CharMapMe_signed.appx" /Y

Perchè avere due file? Quello “nosigned” sarà quello che invieremo sul Dev Center per tentare la certificazione, mentre quello “signed” potrà essere installato sulla nostra macchina (o su altre di sviluppo e/o test) per testare l’installer vero e proprio, e capire se l’app WPF convertita in UWP parte e funziona correttamente come previsto. Come faccio a firmare un file .appx?

SignTool sign /fd SHA256 /a /f
    ..VivendoByte.pfx /p 123456
    CharMapMe_signed.appx

Utilizzo il tool SignTool per firmare il file “CharMapMe_signed.appx”, passando come parametri il certificato digitale “VivendoByte.pfx”, la password e l’algoritmo di cifratura (SHA256). Fatto, il package è firmato. Ripeto, ne abbiamo due: quello “nosigned” va inviato sul Dev Center, oppure all’ingegnere Microsoft con cui state collaborando per certificare la vostra app; quello “signed” serve a voi e solo a voi per testare la vostra app.

Infine, giusto per fare un lavoro pulito, cancello tutti i file nel folder “Windows Store” che non hanno l’estensione .appx. Così facendo, ottengo una bella cartella pulita con solo i due file package.

for /f %%F in ('dir /b /a-d ^| findstr /vile ".appx"') do del "%%F"

Per ottenere quindi una cosa simile:

image

 

Conclusioni

Beh, missione compiuta! Ci sarebbe molto altro da dire o da raccontare, per esempio:

  • Posso mettere DevOps.bat nelle “post build events” di Visual Studio?
  • Perchè non effettuare davvero il deploy in produzione, facendo l’upload dei file nel posto giusto? Ad eccezione del deploy del Windows Store, perchè quest’ultimo ad oggi passa ancora attraverso una procedura manuale di submission
  • Eseguire “DevOps.bat > DevOps.log” permette di ottenere il log dell’ultima esecuzione, il che può sempre fare comodo

Lascio le porte aperte ad ulteriori sviluppi.

Send to Kindle
.NET WorldVisualStudioTips.net

Automatizzare il deploy di una tradizionale (e banale) applicazione WPF

Mi piacerebbe dedicare qualche post a descrivervi come ho deciso di organizzare il deploy di una piccola e normalissima applicazione desktop implementata in WPF. Penso che la conoscerete, perchè si tratta di CharMapMe, l’applicazione di cui ho già parlato qualche giorno fa. Il caso secondo me è interessante, perchè l’app non è complessa, e mira al cuore di un problema ben preciso, che si può riassumere velocemente con la seguente domanda.

Quanto è complesso ottenere in modo automatizzato i file corretti da distribuire nel caso di deploy tramite ClickOnce, Portable e magari Windows Store?

Ok, andiamo con calma.

Introduzione
CharMapMe sorge dalle ceneri di Show Cars, come vi ho raccontato qui. Vale a dire, quindi, che è un piccolo tool per sviluppatori (ma non solo) nato diversi anni fa, ritagliando tempo libero qua e là e risolvendo un problema che mi affliggeva, ovvero sfogliare tutti i font possibili ed immaginabili alla ricerca di simboli da inserire nelle mie view XAML. Utilizzare charmap, quello predefinito di Windows, è davvero impossibile, non sto qui a raccontare il perchè.

CharMapMe, quindi, è una normale applicazione WPF, puramente desktop, composta dai seguenti file:

image

Un eseguibile ed un po’ di dipendenze esterne. Nulla di che, estremamente banale.

Ho deciso sin da subito di distribuire CharMapMe sicuramente attraverso ClickOnce dal sito ufficiale https://charmapme.azurewebsites.net. E poi di distribuirla attraverso un file zip, in modalità portable, così eventualmente uno si mette l’applicazione dove più gli pare e piace, su una chiavetta USB o da altre parti. ClickOnce dà il vantaggio degli auto-aggiornamenti, ma anche la modalità portable è comoda e perfettamente legittima.

Ho voluto anche distribuirla attraverso il Windows Store, quindi trasformarla in Universal Windows Platform. Avevo due scelte: o la riscrivevo daccapo oppure utilizzavo Centennial, alias Desktop Bridge, per convertirla più velocemente. Ho optato per questa seconda scelta, più veloce e meno invasiva per il mio cervello (LOL). Sì, nei prossimi giorni vi racconterò anche qualcosa su questa esperienza, non tanto dal punto di vista tecnico, quanto piuttosto per descrivervi esattamente cosa accade, perchè non è un processo totalmente automatico.

Quindi, per riassumere…
Voglio distribuire CharMapMe attraverso ClickOnce, uno zip ed il Windows Store.

Di per sè, non è affatto complicato ottenere i package per ciascuna distribuzione.
ClickOnce è in pratica un wizard integrato dentro Visual Studio; dopo averlo configurato la prima volta, sono sufficienti 2-3 click per ottenere i file da uploadare sul sito via FTP.
Ottenere uno zip è pressoché banale: si copiano i file in Bin/Release in un folder dedicato, si cancellano i file non necessari (stando bene attenti), si zippano ed il gioco è fatto.
Ottenere il file .appx è più complesso, ma per ora sorvoliamo.

Ma la questione è: posso automatizzare tutto?
Certo che sì. Andiamo gradualmente. Questa è la struttura di cartelle che compongono CharMapMe, così come vengono scaricate dal TFS su cui sono memorizzati i sorgenti. CharMapMe, perdonatemi, non è (ancora?) open-source.

image

C’è il file di solution CharMapMe.sln, c’è il folder “packages” di NuGet, e poi c’è un folder per ciascuno dei progetti (CharMapMe è l’applicazione client WPF vera e propria, tutti gli altri sono assembly di supporto e di dipendenza).

Ho creato una cartella “Deploy” prima per avere un punto preciso dove finiranno i tre differenti deploy che mi interessa gestire. Vediamo cosa contiene.

image

Elenco e descrivo i file uno ad uno.

  • 7z.exe : è il comando appartenente a 7-Zip per zippare i file (mi serve per creare la distribuzione in modalità Portable)
  • DevOps.bat : è il cuore del sistema, ne parleremo nei prossimi post
  • DevOps.log : log generato automaticamente dall’ultima esecuzione di DevOps.bat
  • VivendoByte.* : certificati digitali per gestire e testare il package Windows Store

Ok, il sistema è pronto.

DevOps.bat è il file batch che si occuperà di generare i tre deploy, invocato on-demand oppure come post build events da Visual Studio.

Ne parleremo con calma nei prossimi post.

Send to Kindle
.NET WorldVisualStudioTips.net

Ammy al posto dello Xaml?

L’altra notte, complice un po’ di insonnia e tensione, non riuscivo a dormire. Mi sono svegliato ed ho cominciato a sfogliare dal telefono la mia timeline di Twitter.

Fino a quando trovo questo:

image

Un certo Miguel da Icaza mi porta a conoscenza dell’esistenza di Ammy. Di cosa si tratta? Lo riassumo in qualche punto per chiarire le idee:

  • il sito di riferimento è il seguente: https://www.ammyui.com/
  • è un linguaggio json-like da utilizzare al posto dello XAML per descrivere la UI
  • è un package da scaricare via NuGet: solo 59Kb
  • rispetto a XAML presenta dei vantaggi: è più compatto (ma va?), supporta nativamente la capacità di modificare a run-time la Window o la Page, implementa il concetto di mixin, l’Intellisense nei file .ammy in Visual Studio funziona a meraviglia
  • ci sono anche svantaggi: essendo json, non è possibile in questo momento collassare/espandere porzioni di view, tecnica che io utilizzo molto per nascondere parti di Window o di Page che non mi interessano in quel momento. Al momento supporta solamente WPF e non UWP. Non ho ancora utilizzato Ammy in produzione (è uscito il 22/12/2016), quindi non ho esperienze dirette

Ad esempio, una porzione di XAML come questa:

   1: <StackPanel>

   2:     <TextBlock Text="A story to tell" />

   3:     <TextBlock Text="{Binding Story}" Style="{StaticResource StoryStyle}" />

   4: </StackPanel>

 

Diventa il seguente blocco Ammy:

   1: StackPanel {

   2:     TextBlock { "A story to tell" }

   3:     TextBlock {

   4:         Text: bind Story

   5:         Style: resource "StoryStyle"

   6:     }

   7: }

 

Più compatto, è vero, ma Ammy supporta delle feature davvero molto interessanti, come il poter definire una sorta di “funzione” (mixin) da richiamare dove serve per generare controlli più o meno complessi. Ammy è da provare senz’altro, tanto più che è possibile mischiare tranquillamente view implementate in XAML con altre in Ammy. Le view implementate in Ammy sono salvate in file con estensione .ammy, che all’atto della compilazione vengono tradotte e convertite in XAML. Il team di sviluppo afferma che qualsiasi cosa fattibile con XAML è fattibile anche con Ammy.

CharMapMe 1.2 supporta già adesso Ammy!

Ho subito adattato il mio CharMapMe affinchè possa generare Label, TextBlock e TextBox in linguaggio Ammy. La versione 1.2 è già online, pronta per essere installata via ClickOnce.

Ho scritto al team di sviluppo di Ammy, giusto per metterli al corrente del mio tool, mi hanno risposto entusiasti ed hanno capito il valore di CharMapMe.

Send to Kindle
.NET WorldVisualStudioTips.net

UWP, SharpDX e font installati

Tempo fa ho avuto la necessità di recuperare l’elenco dei font installati in Windows da un’app UWP. La cosa non è possibile utilizzando il framework UWP di base, per cui ho trovato ed utilizzato la libreria SharpDX, che è una libreria wrapper open-source verso il mondo DirectX. Tramite SharpDX è possibile accedere a funzioni grafiche 2D e 3D e delle varie componenti più a basso livello (DirectSound, DirectX 9-11 e 12, DirectInput, eccetera). La cosa interessante è che SharpDX supporta .NET 4.5 ed è scritta all’interno di una libreria Portable, per cui è disponibile un po’ ovunque.

Vi lascio qualche link utile:

Wiki dedicata a SharpDX

SharpDX su NuGet

SharpDX su GitHub

Purtroppo in questo momento sto utilizzando Open Live Writer per bloggare, per cui non riesco a postarvi alcuna riga di codice utile per ottenere l’elenco dei font – anche perchè la cosa non è così banale ed immediata. All’interno di OLW infatti non sono ancora supportati. Confido nei prossimi giorni di riuscire a pubblicare qualcosa su GitHub per darvi una mano! Stay tuned!

Send to Kindle
.NET WorldVisualStudioTips.net

Installazione offline di Visual Studio

E’ possibile? Ovviamente sì, ma c’è qualcosa da sapere prima. Vediamo.

Visual Studio 2015
E’ possibile scaricare un installer offline di Visual Studio 2015 dal command prompt di Windows usando questa sintassi:

vs_enterprise /Layout C:CartellaDownload

Morale: si scaricare l’installer “vs_enterprise.exe” dal sito Microsoft (circa 800Kb). Successivamente si lancia il comando specificato qui sopra. Così facendo vengono scaricati tutti i pacchetti e le dipendenze di Visual Studio 2015, in modo da procedere all’installazione di tutto anche rimanendo sconnessi dalla rete. Io l’ho fatto per la versione Enterprise e la dimensione è di 25,8 GB (6.755 file divisi in 2.641 cartelle).

Visual Studio 2017
E’ possibile fare la stessa cosa anche con la versione corrente (Release Candidate) di Visual Studio 2017. Ma la sintassi è leggermente differente:

vs_enterprise –-layout C:CartellaDownload

La morale però è sempre la stessa. Alla fine del download nella cartella specificata vi ritroverete tutto il necessario per procedere senza avere connettività. Trovate maggiori informazioni a questo indirizzo.

image

Una volta lanciato il comando, partirà un download più o meno lungo in base alla vostra connessione.

image

Non è solo questione di offline
Questa procedura è utilissima anche perchè se dobbiamo installare Visual Studio su N postazioni, è inutile fare il download ogni volta: lo facciamo una volta e poi si va via lisci. E’ anche questione di risparmio di banda e soprattutto di tantissimo tempo. Ad esempio, sul mio PC se installo Visual Studio 2015 partendo dall’iso, ed installando tutto, impiego circa 4h30min. Parliamo di un PC desktop, con i7, 16GB di RAM, ed un SSD Crucial da 750Gb. Eh insomma, parecchio tempo.

Se comincio la stessa installazione sullo stesso PC, ma utilizzando l’installer offline, tutto il setup viene chiuso in poco meno di un’ora e mezza. Eh insomma, un bel risparmio di tempo.

Note dolenti
Tutto questo funziona alla grande, tranne che per il setup dell’SDK di Android che – come recita la pagina che vi ho linkato prima – “does not support an offline installation experience”. Quindi, sappiate che se installate qualcosa riguardante Android (sviluppo nativo o cross-platform con Xamarin Forms) qualcosa potrebbe andare storto, e quindi in questo caso avete bisogno di Internet dietro le quinte. Pazienza, a quanto pare ad oggi non c’è soluzione.

Send to Kindle
.NET World

Docker Free ebook

Segnalo velocemente questo indirizzo dal quale potete scaricare un simpatico ebook in formato PDF di circa 60 pagine (4,69 Mb la dimensione del file) utilissimo per capire le basi dietro Docker.

Serve per entrare in contatto con i concetti base dietro lo sviluppo di applicazioni da “containerizzare” con Docker, quali strumenti dobbiamo utilizzare (da Visual Studio Code a tutti gli altri più o meno open-source), quali linguaggi dobbiamo apprendere (.NET Core, per esempio, rimanendo su tecnologie puramente Microsoft), ma soprattutto come cambia l’approccio. L’ebook tratta sia l’utilizzo con Visual Studio 2015 che con il nuovo 2017 (che ad oggi non è ancora in RTM). E la cosa interessante, per chiudere, è che Docker viene raccontato e sviscerato da diversi punti di vista: partendo da chi scrive il codice, fino ad arrivare al deploy in Continuous Delivery, etc. etc.

Visto che è gratuito, un’occasione da non perdere.

Il link è il seguente:

https://blogs.msdn.microsoft.com/cesardelatorre/2016/11/16/free-ebook-on-containerized-docker-application-lifecycle-with-microsoft-tools-and-platform/

Send to Kindle
.NET World

Software WPF e pagamenti via PayPal

Oggi vi voglio raccontare una storia.

Qualcuno di voi lettori sa che ormai da anni faccio parte di Piloti Virtuali Italiani. E’ un’associazione italiana, senza scopo di lucro, che mira alla diffusione di cultura aeronautica in tutti i modi che riesce: attività online di vario tipo, corsi di volo virtuale tenuti da piloti ed ex-piloti, contest, partecipazione a fiere ed eventi correlati al volo, e molto altro ancora. Cosa utilizziamo? I nostri PC, con Microsoft Flight Simulator X (attualmente in vendita su Steam), X-Plane, Prepar 3D ed altri software minori (volo in elicottero, missioni spaziali, etc.).

Raccontata così sembra più che altro un videogioco, ma vi assicuro che la cosa è serissima: bisogna preparare il piano di volo, imbarcare il carburante giusto, dialogare con i controllori di volo in lingua inglese, seguire le stesse regole del volo reale per l’avvicinamento e l’atterraggio finale, gestire eventuali emergenze, controllare continuamente lo stato dei motori, le velocità, etc. etc. Come si può ben facilmente immaginare, io sono un po’ (insieme ad altre persone, non sono solo) il ramo informatico di PVI e come tale ho scritto un piccolo software, battezzato VivendoByte Fsx Logger, che è una sorta di scatola nera degli aerei simulati.

L’interfaccia è piuttosto semplice: uno Start per cominciare la registrazione del volo ed uno Stop per fermarlo. C’è dell’altro, ovviamente, ma sorvolerò. Questa applicazione WPF parla via P/Invoke con una DLL proprietaria di FSX (messa a disposizione da Microsoft stessa), oppure con un’altra DLL che è diventata lo standard di riferimento (FSUIPC.dll). In ogni secondo di volo vengono registrate diverse decine di parametri di volo (se siete interessati andate qui), che alla fine vengono impacchettati in un bel file zip protetto e spediti via WCF ad un server che si occupa di ricevere lo zip e di elaborarlo. Ogni volo viene promosso o bocciato, ottiene dei punti (in ottica social), generare statistiche, etc. etc. Ed è così che si ottengono pagine come questa che elenca i voli effettuati dai soci PVI o come questa che invece dettaglia il volo singolo. Flight Simulator X permette di scattare delle foto durante il volo: in tal caso il mio Fsx Logger se ne accorge, cattura i JPG generati, li include nel pacchetto e finiscono online. E si ottengono pagine come questa, che mostra le foto catturate durante un certo volo. Fsx Logger, lato client e lato server, fa tantissime cose, ma lo scopo del post non è quello di raccontarvele tutte. Sappiate – giusto per parlare – che si tratta di un sistema davvero molto ampio, che utilizza tantissime tecnologie:

  • Windows Presentation Foundation
  • Windows Communication Foundation
  • P/Invoke
  • ASP.NET MVC
  • Google Calendar, Google Maps, Facebook, Twitter
  • Varie app per Windows Phone (deprecata), Windows 8 / 10, etc.
  • Distribuzione via ClickOnce, setup completamente on-line
  • Altro che sicuramente mi sto dimenticando

E’ un software che è in produzione da diversi anni, non è su Azure, ma è hostato sullo stesso provider dove state leggendo il mio blog. Su Azure ho solamente posizionato tutto lo storage: i file zip, i log di volo, gli screenshot catturati occupano ad oggi circa 85GB di dati, accumulati dal 2009 circa (anno di prima pubblicazione) ad oggi. Nessun hosting provider è in grado di offrire uno spazio di storage di tali dimensioni, ma Azure sì, tra l’altro per pochi euro al mese.

VivendoByte Fsx Logger è gratuito per i soci di Piloti Virtuali Italiani – poco meno di 400 persone in tutta Italia e non solo, che ogni giorno volano virtualmente ogni giorno e pubblicano i loro log di volo sul sito. E’ anche in vendita per tutti gli altri.

Come ho implementato il sistema di pagamento? Sfruttando PayPal. Tramite questa pagina chiunque può procedere all’acquisto: a me arriva una mail di notifica e c’è una procedura automatica che crea l’utente e gli consente l’attivazione della licenza per utilizzarlo al 100%. E’ così che ogni tanto mi accorgo che viene acquistato da diverse parti del mondo, in UK, in Brasile, in diverse zone di Europa, addirittura presso alcuni dipartimenti universitari che trattano con il mondo del volo.

Recentemente ho tentato di replicare lo stesso modello di acquisto via PayPal in un’applicazione UWP, per scoprire che prima del 29 Giugno 2015 la cosa sarebbe stata possibile, oggi no. Dopo quella data, gli sviluppatori UWP devono far acquistare le licenze (ed in generale gli add-on delle app UWP) tramite le API Microsoft messe a disposizione proprio per questo scopo.

E come si fa? Ne parlerò in un prossimo post!

Send to Kindle
.NET World

Microsoft REST API Guidelines

Lo scorso 8 Luglio ho partecipato ad una giornata interamente dedicata ad ASP.NET Core 1.0, evento organizzato da Overnet Education, e portato a termine da Gabriele Gaggi ed Ugo Lattanzi. In quel frangente ovviamente si parlava di web, controller, web api, e via dicendo. Ricordo che Ugo ad un certo punto disse una cosa simile alla seguente: “secondo la convenzione, quando si invoca un metodo REST che aggiunge un oggetto al nostro repository, la response deve includere almeno due informazioni: l’ID dell’elemento appena aggiunto e l’URL al quale si possono reperire i dettagli dell’elemento stesso”. Scusate l’imprecisione, ma il web non è propriamente il mio campo. Ricordo di aver trovato interessante quell’affermazione di Ugo, al punto che lo interruppi chiedendogli…ma dove posso trovare queste regole, convenzioni, buone norme di implementazione di API di tipo REST?

Beh, oggi la risposta ce l’ho.

Su GitHub Microsoft ha pubblicato un repository denominato “Microsoft REST API Guidelines” ricco di documentazione, allo scopo di fornire a tutti gli sviluppatori le migliori guideline per l’implementazione di API REST. Tra gli autori figura un certo Mark Russinovich. Troverete informazioni su un po’ tutto: gestione degli errori, struttura degli URL, serializzazione in JSON, gestione corretta del versioning delle API, e molto altro ancora.

image

Sono piuttosto certo che troverete la lettura molto interessante!

Send to Kindle
.NET World

Ottenere le Api Key per i Cognitive Services

I Cognitive Services sono un servizio relativamente nuovo che Microsoft ha reso disponibile. Grazie a questi servizi abbiamo a disposizione tutta una serie di API che ci permettono di effettuare riconoscimenti di immagini, emozioni, volti, testi, voci, riconoscimento degli speaker in un file audio, ed altro ancora. Trovate maggiori informazioni sul sito ufficiale.

Come sempre, per accedere a queste API è necessario registrarsi sul sito ed ottenere le Api Key da includere poi nelle chiamate REST. Nulla di particolarmente complicato.

Attenzione ad un particolare, però. Se un determinato servizio si appoggia su Azure, le Api Key non saranno quelle visibili sul portale dei Cognitive Services, ma saranno quelle visibili sul portale Azure. Mi spiego meglio. Se vado sul sito https://www.microsoft.com/cognitive-services/en-US/subscriptions e do un’occhiata al mio account, vedo la situazione seguente:

image

Sto facendo esperimenti con il servizio Speaker Recognition, che in forma gratuita prevede 10.000 transazioni al mese, 20 al minuto. Ho mantenuto nascoste le Api Key per privacy, ma anche facendole vedere sarebbe stato inutile, perchè queste API si appoggiano su Azure, e quindi le Api Key giuste vanno prelevate dal portale Azure. Notare infatti la presenza del bottone Buy On Azure proprio lì accanto. Cliccando su quel link viene aperto il marketplace su Azure che permette di completare l’acquisto del servizio vero e proprio. Ed è da Azure che dovrete copiare & incollare le Api Key corrette da utilizzare all’interno del proprio codice.

image

Notare che a me il servizio Cognitive Services risulta già attivo, nella sua forma FREE. Nel momento in cui vi scrivo, tale servizio è esposto solo dal data-center in West US. Una volta che avete attivato il servizio, esso sarà raggiungibile come tutte le altre risorse allocate sul cloud, e quindi da lì banalmente potete ottenere le Api Key corrette.

image

Send to Kindle