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.

Già dal 2012, con l’introduzione di Windows Server 2012, Microsoft ha presentato ReFS (Resilient File System), un nuovo file system per gli ambienti Windows progettato per i workload moderni e, idealmente, per sostituire NTFS appena possibile. Le prime versioni di ReFS non brillavano per velocità ma con Windows Server 2016 ReFS è diventato il file system raccomandato per workload importanti come i cluster di storage S2D o per le infrastrutture iperconvergenti basate su Hyper-V, promuovendolo ormai senza riserve all’uso in produzione.

Nel mondo di Windows Server è certamente inusuale discutere di file-system alternativi a NTFS, discussioni più comuni nel mondo Linux nel quale le alternative sono numerose, ma se Microsoft ha deciso di introdurre una alternativa a NTFS lo ha fatto probabilmente per superare le limitazioni di una tecnologia disegnata tantissimi anni fa

ReFS include novità come l’introduzione dei B+ trees per incrementare le prestazioni, una tecnologia di block cloning che riduce la necessità di trasferire i dati da una parte all’altra del disco implementando l’operazione come una modifica di puntatori che possono essere aggiornati con pochissimo I/O e lo sparse VDL (Valid Data Length) che può inizializzare in modo super-veloce i nuovi file e che rende quindi la creazione di file molto grandi una operazione che dura pochissimi secondi. Accanto a questo, la dimensione massima di ogni volume passa a 1 yottabyte, cioè un miliardo di terabyte, garantendo il supporto per dati di dimensioni difficilmente immaginabili quando il vecchio NTFS fu progettato e proiettando ReFS nell’era del cloud.

Ci sono però 4 funzionalità killer che consentono al nuovo file system di fare da subito la differenza anche quando non si abbiano necessità particolari come l’implementazione di cluster di storage o di virtualizzazione o sistemi complessi. Alcune di queste non sono novità assolute ma richiedevano controller hardware per essere implementate mentre ReFS è un modulo completamente software che non usa i controller RAID hardware.

Funzionalità #1: chkdsk senza downtime Con l’avvento del cloud i workload sono diventati ancora più complessi e la mole di dati da gestire è aumentata a dismisura. In passato il danneggiamento di un file system richiedeva l’uso di chkdsk ma, soprattutto, la sospensione delle attività del volume per la correzione degli errori. L’unità doveva essere messa offline e verificata, una operazione che poteva durare anche decine di ore per volumi molto grandi e questo spesso incoraggiava e creare volumi più piccoli per rendere questi tempi accettabili.

Nell’era del cloud la sospensione dell’attività di un volume, e quindi l’indisponibilità dei relativi dati, per ore non è più accettabile. ReFS non ha quindi più bisogno di chkdsk e nemmeno di sospendere l’attività del volume perché il file system può correggere (se possibile) i problemi in modo automatico e, nei casi in cui la correzione non sia possibile, può rimuovere le aree danneggiate dalla gestione del volume senza andare ad intaccare gli altri dati.

Perchè è importante Chiunque si sia trovato davanti alla necessità di effettuare un chkdsk di un volume, magari a causa di un file danneggiato che non poteva essere rimosso nè rinominato, e abbia [...]

Windows Azure Pack is a great technology but sometimes Microsoft seems to be missing the complexity of providing services to hundreds if not thousands of customers, each of them with different needs. Standardization is good but it should provide enough flexibility to manage things in a reasonable way. So here’s the scenario: you deployed WAP and your customer starts to buzz into your server because how good WAP actually is. Rock solid, able to run most demanding websites. Great technology, I said.

However, one of your customers runs over his allotted quota of one of the seventeen metrics you can monitor for your websites. Since your customer didn’t opt for a pay-per-use billing model, you just suspend his website, like any hoster in the world would do, and your customer calls in to buy more “of that something”. He pays (if needed), if you’re like us he gets an add-on to increase his quota over a standardized plan and, after a while and a little synchying, WAP states that his account is now back in quota. End of story.

Well, almost! Because your customer calls in again stating that his website is still suspended while on his portal he sees no over-quota warnings and you realized that he is right: no warnings, increased quota but website still suspended. Hmmm…

From now on, you start a journey to understand why WAP didn’t re-enable that website. You try to update plans, subscriptions, add-ons, force subscription resynchying, force plans to update, open-up Powershell to look for a well-hidden parameter that will allow you tell WAP to re-evaluate quota and re-enable website, or (at least) a cmdlet to tell WAP to re-enable that #&%$@#!$ website because I’m the one who rules here. Apparently, you discover that there isn’t anything like that: no way to re-enable a website that is over quota. So you basically look at portal where it states that counters will be reset in 29 days and you start thinking if WAP really wants to re-evaluate quota in 29 days from today. You wait in the hope that it will take a little time to start that website again but no luck. After hours, you really start to think that WAP will keep that website suspended until it will be time to reset counters, which is obviously totally unacceptable. But the most scary thing is that you cannot force it to change his mind. You’re basically powerless.

After a little checking, it turns out what I stated is not true for all quota items. For example, a short while after upgrading (by adding an add-on) sent bytes quota, a suspended website has been restarted by WAP itself. However, there are other counters that seem to be evaluated only when their configured period will expire, for example CPU burst and received bytes. No matter how long you wait after changing those, WAP won’t restart the affected website. I’m talking about hours here, not minutes, but I couldn’t wait days to check if it would happen after 29 days as suspected. [...]

A few days ago Microsoft released ASP.NET 5 beta8, the first feature-complete version of its flagship Web framework. A lot of expectations come with this new version, both because Microsoft decided to change ASP.NET down to its basis and because this one will be the first multi-platform release for the technology, allowing developers to run their Web or console applications on Windows, Linux and Mac OS X. However, the new version will also be the first one designed from the ground up for the cloud era and thus adopting all methodologies, technologies and conventions that emerged in past few years. As we detailed in a past article (sorry: Italian language only this time!), ASP.NET 5 will also change the way ASP.NET will be hosted on Windows because it will run through the famous HTTPPlatformHandler module that enabled Azure to run basically any runtime, including Java, Python, RoR and more. Later, that module has been channeled down to partners and Windows Azure Pack incorporated it in UR7.

You might be running your website or application on Windows Azure Pack and, if you do, I do really hope that you’re hosting with us at VaiSulWeb since we also have free accounts for you to try ASP.NET 5. However, even if you’re hosting at another service provider, you might be wondering if you will be able to run ASP.NET 5 starting from beta8, since this version switches to HTTPPlatformHandler. Up until beta7, hosting with Azure Pack was very easy: you only needed to publish your project to a folder and then upload that package to your WAP account. Everything was working fine since the very first second.

Spoiler: scroll down for a quick solution

There’s a quick solution waiting for you at the end of this article. If you’re only interested in understanding how you can run ASP.NET 5 from beta8 using WAP, just skip this lengthy explanation and run to the end. This article will be used to as an handy excuse to showcase some nice features that Windows Azure Pack provide its users and that our company provides its customers. We will use such features to understand what’s going on with beta8 and then provide a quick solution to host it on WAP.

Publishing your beta8 to your WAP account : Redmond we have a problem…

So you just started a new project based on ASP.NET 5 beta8 in Visual Studio 2015 or you just created a template project to check how things would shape up. Quick and easy. Now you would like to upload that project to your Web hosting account to check if your provider is compatible with the technology. So you just export your project…

Publishing your project to file system

… publishing to file system, the same way you did up to beta7. Then, after that operation completes, you upload your project on your WAP accounts via FTP or WebDeploy. Compilation time, just a few seconds, and then… uh ?

It seems that something went wrong since no shiny MVC homepage appears in your [...]