Il titolo di questo post riassume in maniera precisa l’ultima settima di lavoro.
Dovendo implementare una serie di single-page application con un struttura comune, ho cercato di automatizzare il più possibile le operazioni ricorrenti. In particolar modo le operazione di build, in modo da velocizzare le fasi di deploy e di creazione del pacchetto di distribuzione.
Continua a leggere Visual Studio Code, Typescript, Sass e GulpGli elementi fondamentali della struttura di docker sono le immagini, i containers, i services e lo stack. Si possono considerare immagini e containers come l’equivalente di classi / istanze utilizzate nei linguaggi di programmazione ad oggetti. Analogamente a quanto avviene per una classe che viene istanziata tramite la keyword new, anche le immagini sono “istanziate” utiilizando il comando docker run .
Continua a leggere Docker – StrutturaDurante la fase di test di un’applicazione può essere utile accedere a IIS Express da remoto. Normalmente quando viene eseguito il debug da visual studio, IIS Express è eseguito come http://localhost:80, quindi con il binding sulla porta 80 di localhost.
Da qualsiasi altro client di rete (ma anche da internet in caso di NAT), il debug non è possibile. E’ possibile configurare il binding di IIS, modificandone il file di configurazione.
Nella directory della soluzione .NET troviamo la cartella nascosta denominata .vs .
Al suo interno, un’altra cartella denominata config .
La configurazione di IIS Express viene fatta utilizzando il file applicationhost.config.
E’ sufficiente ricercare la configurazione legata al binding modificando l’attributo “bindingInformation” da ‘localhost‘ a ‘*‘. In questo modo, IIS Express effettuerà il binding su tutte le interfacce di rete presenti sul nostro dispositivo.
A questo è necessario abilitare l’accesso all’url, tramite powershell:
netsh http add urlacl url=http://*:18460/ user=everyone
Per l’accesso da altri pc della rete è necessario configurare il firewall del pc utilizzato per il debug, garantendo l’accesso alla porta impostata al passaggio precedente. A questo punto qualsiasi pc della rete potrà accedere alla webapplication in running e sarà possibile debuggarne gli steps.
Dopo il post introduttivo sulla programmazione asincrona in .NET, analizziamo le parole chiave async e await, introdotte a partire da C# 5.0. Async e Await consentono di scrivere codice asincrono in modo semplice: il codice risulta molto simile a quello sincrono, con tutti i vantaggi che ne derivano in termini di gestione di thread. Nella programmazione asincrona vengono generati thread separati, che non permetto di effettuare chiamate non bloccanti.
Continua a leggere Programmazione asincrona con async – await (parte 2)
ASP.NET Core utilizza la variabile d’ambiente ASPNETCORE_ENVIRONMENT per determinare l’ambiente di esecuzione corrente. I valori predefiniti che questa variabile può assumere sono Development, Staging oppure Production. Inoltre è possibile personalizzarne il valore con uno custom. Le variabili d’ambiente sono case insensitive.
WebHostBuilder è l’oggetto che consente di determinare l’ambiente in cui l’applicazione è in esecuzione. Per poter recuperare il contesto attuale è possibile utilizzare IHostingEnvironment , in modo da poter determinare un comportamento specifico in base all’ambiente. Ad esempio, nell’ambiente Production l’applicazione potrebbe abilitare la minimizzazione delle risorse, mentre in Development non eseguire nessuna particolare ottimizzazione.
Continua a leggere Impostazione delle variabili d’ambiente per ASP.NET Core
