Sviluppando una applicazione per Azure Service Fabric e aggiungendo una libreria .NET Standard al progetto ci si potrebbe imbattere in una serie di warning di Visual Studio come questo

Warning MSB3270 There was a mismatch between the processor architecture of the project being built “MSIL” and the processor architecture of the reference “C:\[…]”, “AMD64”. This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

Si tratta di un warning che indica che l’architettura selezionata per la CPU non è l’unica supportata da Azure Service Fabric e cioè x64. Probabilmente l’impostazione è AnyCPU e la libreria funzionerà correttamente ma per fare sparire i warning è sufficiente modificare il target di compilazione nell’apposita sezione Build di Visual Studio:

oppure impostare l’architettura target direttamente nel file .csproj del progetto:

<PropertyGroup> <TargetFramework>netcoreapp2.0</TargetFramework> <PlatformTarget>x64</PlatformTarget> <RootNamespace>Microsoft.*.Tests</RootNamespace> </PropertyGroup>

E’ sufficiente salvare il file ed effettuare una nuova compilazione : non si dovrebbero visualizzare altri warning.

Ovviamente bisogna ricordare che questa modifica renderà inutilizzabile la libreria nel contesto di una applicazione a 32bit.

Con un post sul blog di Microsoft, il gigante di Redmond ha chiarito la situazione che circonda il framework .NET e la sua relazione con .NET Core ed ha annunciato che il .NET Framework 4.8  sarà l’ultima versione del framework  che Microsoft renderà disponibile. Dopo il rilascio di .NET Core 3 la prossima major version sarà .NET Core 5 che deve essere la versione che tutti gli sviluppatori .NET useranno dopo il rilascio di .NET Core 3.

Microsoft ha anche confermato alcuni dettagli interessanti come il fatto che salterà la numerazione 4 per il framework .NET Core per evitare confusione tra gli sviluppatori quindi la prossima versione di .NET (qualsiasi piattaforma) sarà .NET Core 5 per consentire agli sviluppatori che usano il framework .NET di passare dalla 4.8 alla 5 in modo naturale. Inoltre alcune tecnologie che erano molto popolari non verrano implementate in .NET Core e, sebbene saranno comunque oggetto di aggiornamenti e manutenzione (ma per quanto tempo ? Microsoft ha iniziato a non onorare più la promessa di supporto per 10 anni delle tecnologie deprecate…), gli sviluppatori devono iniziare a pensare alla conversione delle proprie applicazioni. Tecnologie come  WebForms, WCF e Windows Worflow non saranno reimplementate , tutte tecnologie che erano molto popolari in passato nello settore Windows.

Infine, la conferma che la data di rilascio di .NET Core 3 sarà Settembre 2019, cosa che rende la prossima major version di .NET (attualmente in preview5) molto vicina.

Con un post su GitHub,  Damian Edwards ha annunciato che la nuova release di ASP.NET, la versione 5, non verrà più eseguita da IIS come ISAPI ma attraverso il modulo HTTPPlatformHandler che per l’occasione verrà aggiornato con alcune modifiche e reso disponibile anche per Windows Server 2008R2, la versione minima per eseguire ASP.NET 5. La modifica sarà disponibile già con la beta8 del software e quindi al prossimo aggiornamento previsto per il 5 Ottobre 2015.

ASP.NET ed IIS

A prima vista questa modifica potrebbe sembrare ininfluente ma segna un cambiamento piuttosto importante se si considera che sin dalla sua introduzione con IIS 6 e Windows Server 2003, ASP.NET è stata eseguita da IIS come ISAPI, la configurazione che garantiva le prestazioni migliori sulla piattaforma. Lo stesso avveniva ed avviene per altre tecnologie come ASP classico mentre storicamente altri framework o estensioni provenienti dal mondo Unix usavano invece una tecnologia meno sofisticata a cui si fa riferimento in generale come CGI.

Le perplessità potrebbero sorgere proprio perché da sempre l’esecuzione ISAPI è considerata la più efficiente e quella capace di fornire prestazioni di molto più elevate sulla piattaforma Windows Server, soprattutto perché la creazione di nuovi processi è in effetti una operazione onerosa sui sistemi Windows, molto più di quanto lo sia sui sistemi Unix.

In realtà sin da Windows Server 2003 Microsoft ha affinato il supporto per le tecnologie CGI, in particolare per garantire la compatibilità con framework molto popolari come PHP. La tecnologia FastCGI è in effetti l’antesignana del modulo HTTPPlatformHandler e, sebbene con FastCGI la piattaforma Windows Server abbia efficacemente ottenuto l’esecuzione di framework come PHP con prestazioni pari o addirittura superiori a quelle dei sistemi Unix, fino a poco tempo fa era considerato impossibile che Microsoft decidesse di passare ad una modalità di esecuzione diversa per le proprie tecnologie.

HTTPPlatformHandler : l’evoluzione della specie

La notizia non può che significare che Microsoft ha ormai ottenuto una parità di performance tra l’esecuzione ISAPI e quella CGI e la chiave è senza dubbio il modulo HTTPPlatformHandler. Anticipando le perplessità di qualcuno, Edwards aggiunge che Microsoft si aspetta una differenza di prestazioni tra le due modalità solo per applicazioni triviali come una Hello World, cioè piccole applicazioni che fungono più da esempio che da reali implementazioni. Per tutti gli altri casi, probabilmente Microsoft crede di raggiungere prestazioni uguali o anche maggiori a quelle ottenibili con la tecnologia ISAPI. Certamente così facendo ottiene una flessibilità notevolmente maggiore, soprattutto in un contesto nel quale ASP.NET è diventato open-source ed in teoria qualsiasi utente potrebbe compilare la propria versione della tecnologia.

Il modulo HTTPPlatformHandler è l’evoluzione di quello FastCGI che ha consentito a Windows Server di diventare una piattaforma ideale anche per PHP a partire dalla versione 2003 e da IIS 6. FastCGI risolve il problema dell’onerosità della creazione di nuovi processi con l’attivazione di una singola istanza che verrà usata in modo efficace da IIS per gestire un numero variabile di richieste, isolandole da quelle degli altri siti Web ma gestendole sempre con un processo unico. Di tanto in tanto, in modo configurabile, [...]

In contemporanea con il lancio di Visual Studio 2015, Microsoft ha rilasciato anche l’ultima versione del noto framework .NET, la v.4.6. Sono molte le novità di questa versione, pur essendo un aggiornamento minore. Tra queste la disponibilità del nuovo compilatore JIT denominato RyuJIT che promette di ridurre di molto i tempi di caricamento delle applicazioni .NET e nuove funzionalità del Garbage Collector (GC) che ottimizza meglio l’uso della memoria.

La nuova versione include anche aggiornamenti per i linguaggi standard (C#, VB.NET, F#) e nuove funzionalità collegate al compilare Roslyn che sostituisce il precedente. Inoltre, ASP.NET supporta HTTP/2 quando usato con Windows10 e ci sono molte altre novità legate ad ASP.NET in attesa della nuova versione 5 attualmente in BETA.

Inutile dire che tutti gli sviluppatori che lavorano con il framework .NET troveranno tante nuove funzionalità per migliorare i propri software. Una analisi più completa delle novità (in Inglese) è disponibile a questo indirizzo.