.NET Native–co je nového při kompilování aplikací

Vývojáři, kteří se pustili do tvorby univerzálních aplikací pro Windows 10 (zkráceně UWP), si určitě všimli, že se cosi změnilo při kompilaci. Jednak trvá zpracování Release konfigurace déle a také například není možné vybrat platformu AnyCPU. Pojďte se s námi podívat, jak kompilace probíhá a co se děje na pozadí.

.NET Native

O kompilování aplikací pro UWP se nově stará technologie, která nese označení .NET Native. Všechny řízené (managed) UWP aplikace ji využívají. Všichni uživatelé, kteří si stáhnou aplikaci ze Storu, ji dostanou zkompilovanou pomocí .NET Native do nativního kódu dané platformy.

Důsledkem toho je vyšší výkon, a to v desítkách procent.

  • Zlepšení až 60 % pro studený start aplikace (tedy nebyla zavedena v paměti a uživatel ji nově spustil).
  • Zlepšení až 40 % pro "teplý" start.
  • Menší spotřeba paměti.

Poznámka: Časy pro svou aplikaci si můžete změřit sami .

Zároveň mizí závislost na verzi .NET, která je na daném zařízení nainstalovaná (protože dostane aplikaci již v nativním kódu).

Celé se to hodně podobá nativním aplikacím napsaným pomocí C++, s tím zásadním rozdílem, že můžete pořád používat C# a VB.NET a všechny nástroje, které s nimi souvisí.

Debug vs. Release

Kompilace do .NET Native opravdu není nejrychlejší (obzvlášť v porovnání se stávajícím způsobem). Za vyšší výkon a optimalizace platíme časem. Aby se daly aplikace rozumně vyvíjet, Visual Studio důsledně rozlišuje Debug a Release konfigurace.

Poznámka: Aktuální stav není konečný, tým Visual Studia aktivně pracuje na zkrácení kompilace. Je to však komplexní proces.

Když zvolíte Debug konfiguraci, proběhne build podobně jako na Windows 8.1 – kód se přeloží do IL (Intermediate Language) a poté se nechá CoreCLR, ať ho kompiluje za běhu. Proces je rychlejší a navíc máte možnost připojit debugger i analytické nástroje.

Po přepnutí na Release se začne využívat .NET Native. Balíček s aplikací se přeloží do nativního kódu a už nepotřebuje .NET Framework. V tomto případě pak aplikace běží v totožném prostředí, v jakém bude fungovat na koncovém zařízení uživatele.

Je dobré delší dobu kompilace jednou za čas překousnout a vyzkoušet Release build, protože .NET Native ještě nepodporuje úplně všechny mechanismy dostupné v klasickém .NET Frameworku (jedná se ale o zřídka využívané věci jako třeba čtyř a více-dimenzionální pole, drtivá většina aplikací by na problémy narazit neměla).

Z nastavení buildu také zmizela konfigurace AnyCPU – nativní kompilace je totiž závislá na platformě. Když tedy vytváříte ve Visual Studiu aplikační balíček, nechte zaškrtnuté architektury, na které chcete cílit (což by měly být všechny – vytváříme přece univerzální appky ;) ).

image

Windows Store provozuje vlastní cloudový kompilátor .NET Native. Když projdete ve Visual Studiu průvodce vytvořením balíčku, vypadnou z něj dva důležité soubory: testovací .appx pro sideloading a .appxupload.

Balíček .appxupload obsahuje kód MSIL a referenci na konkrétní verzi .NET Native, podle které pak Store rozhodne, jaký .NET Native použije. Všimněte si na obrázku, že nemáte přístup ke všem číslům verze – pokud vypnete automatické inkrementování, stále nebude dostupné poslední číslo. Má ho rezervované Store pro případ, že by potřeboval vaši aplikaci znovu přeložit po opravě bugů v kompilátoru. V tom případě nebudete muset nahrávat nový balíček, Store provede kompilaci za vás.

Poznámka: V textovém editoru samozřejmě poslední číslo editovat dokážete, ale nedělejte to – Store takový balíček nemusí přijmout.

Důsledkem toho, že Store nyní všechny aplikace kompiluje sám, je, že není možné do něj nahrát soubory vytvořené lokálním .NET Native. Dejte si proto pozor, abyste při vytváření balíčků pro Store zvolili v prvním kroku průvodce "Yes":

image

Něco je špatně?

Může se stát, že aplikace v Debug režimu šlape jako hodinky, ale po kompilaci pomocí .NET Native najednou přestane. Kvůli tomu, že Release konfigurace optimalizuje kód a odebírá z něj debug symboly, nedá se moc dobře ladit. Řešením je vytvořit si vlastní konfiguraci, povolit v ní .NET Native a zakázat optimalizaci kódu.

image

Můžete si také do aplikace doinstalovat NuGet balíček Microsoft.NETNative.Analyzer, který vás upozorní na to, že váš kód není kompatibilní s .NET Native.

Pokud vám selhává Windows App Cert Kit (WACK) na chybě spojené s Windows.Networking.Vpn, přidejte do souboru .rd.xml pod Properties vašeho projektu tento řádek:

<Namespace Name=”Windows.Networking.Vpn” Dynamic=”Excluded” Serialize=”Excluded” Browse=”Excluded” Activate=”Excluded” />

A pokud narazíte na bug kompilátoru, nahlašte ho na Connect.

Martin