Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Bez ohledu na to, jestli píšete novou aplikaci pro UPW nebo migrujete existující aplikaci pro Windows 8.x (dříve označovanou také jako aplikace z Microsoft Storu), můžete postupovat podle stejné sady postupů. Pokud chcete vytvořit aplikaci .NET Native, postupujte takto:
Vyvíjejte aplikaci pro Universal Windows Platform (UWP)a otestujte ladicí buildy vaší aplikace, abyste měli jistotu, že funguje správně.
Ručně vyřešte chybějícímetadat a opakujte krok 3, dokud se nevyřeší všechny problémy.
Poznámka:
Pokud migrujete existující aplikaci pro Windows 8.x do .NET Native, nezapomeňte zkontrolovat Migrace aplikace pro Windows 8.x do .NET Native.
Krok 1: Vyvíjejte a testujte ladící sestavení vaší aplikace pro UWP
Bez ohledu na to, jestli vyvíjíte novou aplikaci nebo migrujete existující aplikaci, postupujete stejně jako u jakékoli aplikace pro Windows.
Vytvořte nový projekt UPW v sadě Visual Studio pomocí šablony univerzální aplikace pro Windows pro Visual C# nebo Visual Basic. Ve výchozím nastavení se všechny aplikace UPW zaměřují na CoreCLR a jejich buildy vydaných verzí se kompilují pomocí řetězce nástrojů .NET Native.
Všimněte si, že mezi kompilací projektů aplikací pro UPW s řetězem nástrojů .NET Native a bez něj existují některé známé problémy s kompatibilitou. Další informace najdete v průvodci migrací .
Teď můžete napsat kód jazyka C# nebo Visual Basic pro plochu rozhraní .NET Native, která běží v místním systému (nebo v simulátoru).
Důležité
Při vývoji aplikace si poznamenejte jakékoli použití serializace nebo reflexe v kódu.
Ve výchozím nastavení jsou sestavení pro ladění kompilována pomocí JIT pro rychlé nasazení F5, zatímco vydání sestavení jsou kompilována pomocí technologie předběžné kompilace .NET Native. To znamená, že byste měli sestavit a otestovat ladicí buildy vaší aplikace, abyste měli jistotu, že fungují normálně, než je zkompilujete pomocí řetězu nástrojů .NET Native.
Krok 2: Zpracování další reflexe a použití serializace
Při vytváření se do projektu automaticky přidá soubor direktiv modulu runtime Default.rd.xml. Pokud vyvíjíte v jazyce C#, najdete ho ve složce Vlastnosti projektu. Pokud vyvíjíte v jazyce Visual Basic, najdete ho ve složce Můj projekt.
Poznámka:
Přehled procesu kompilace .NET Native, který poskytuje pozadí o tom, proč je potřeba soubor direktiv modulu runtime, najdete v tématu .NET Native a kompilace.
Soubor direktiv runtime slouží k definování metadat, která vaše aplikace potřebuje za běhu. V některých případech může být výchozí verze souboru dostačující. Určitý kód, který spoléhá na serializaci nebo reflexi, však může vyžadovat další položky v souboru direktiv modulu runtime.
serializace
Existují dvě kategorie serializátorů a oba mohou vyžadovat další položky v souboru direktiv modulu runtime:
Serializátory bez použití reflexe. Serializátory, jako jsou třídy DataContractSerializer, DataContractJsonSerializera XmlSerializer, nalezené v knihovně tříd rozhraní .NET Framework, nespoléhají na reflexi. Vyžadují však, aby byl kód generován na základě objektu, který má být serializován nebo deserializován. Další informace naleznete v sekci "Microsoft Serializers" v části Serializace a metadata.
Serializátory třetích stran. Knihovny serializace třetích stran, z nichž nejběžnější je serializátor Newtonsoft JSON, jsou obecně založené na reflexi a vyžadují položky v souboru *.rd.xml pro podporu serializace a deserializace objektů. Další informace najdete v části „Serializátory třetích stran“ v Serializace a metadata.
metody, které spoléhají na reflexi
V některých případech není použití reflexe v kódu zřejmé. Některá běžná rozhraní API nebo programovací vzory se nepovažují za součást rozhraní API reflexe, ale využívají reflexi k úspěšnému provedení. To zahrnuje následující metody vytváření instancí typů a metod:
Metoda Type.MakeGenericType
Metody Array.CreateInstance a Type.MakeArrayType
Metoda MethodInfo.MakeGenericMethod.
Další informace najdete v tématu rozhraní API, která spoléhají na reflexi.
Poznámka:
Názvy typů používané v souborech direktiv modulu runtime musí být plně kvalifikované. Například soubor musí místo "String" zadat "System.String".
Krok 3: Nasazení a testování hotových buildů aplikace
Po aktualizaci souboru direktiv runtime můžete znovu sestavit a nasadit verze pro uvolnění vaší aplikace. Binární soubory .NET Native se umístí do podadresáře ILC.out adresáře zadaného ve výstupní cestě Sestavení textovém poli dialogového okna Vlastnosti projektukarta Kompilace. Binární soubory, které nejsou v této složce, nebyly zkompilovány pomocí .NET Native. Důkladně otestujte aplikaci a otestujte všechny scénáře, včetně scénářů selhání, na jednotlivých cílových platformách.
Pokud vaše aplikace nefunguje správně (zejména v případech, kdy během běhu vyvolá výjimku MissingMetadataException nebo MissingInteropDataException), postupujte podle pokynů v další části, Krok 4: Ruční řešení chybějících metadat. Povolení výjimek s první šancí vám může pomoct tyto chyby najít.
Po otestování a odstranění chyb v laděných sestaveních vaší aplikace a po přesvědčení, že jste eliminovali výjimky MissingMetadataException a MissingInteropDataException, byste měli aplikaci testovat jako optimalizovanou aplikaci .NET Native. Chcete-li to provést, změňte aktivní konfiguraci projektu z ladicího režimu na verzi pro vydání.
Krok 4: Ruční řešení chybějících metadat
Nejběžnějším selháním, na které narazíte u .NET Native a které se na desktopu nevyskytuje, je výjimka runtime: MissingMetadataException, MissingInteropDataExceptionnebo MissingRuntimeArtifactException. V některých případech může absence metadat vést k nepředvídatelnému chování nebo dokonce k selhání aplikace. Tato část popisuje, jak můžete tyto výjimky ladit a vyřešit přidáním direktiv do souboru direktiv běhového prostředí. Informace o formátu direktiv modulu runtime naleznete v tématu Direktivy modulu runtime (rd.xml) Referenční informace o konfiguračním souboru. Po přidání direktiv modulu runtime byste měli znovu nasadit a otestovat aplikaci a vyřešit všechny nové MissingMetadataException, MissingInteropDataExceptiona MissingRuntimeArtifactException výjimky, dokud nenarazíte na žádné další výjimky.
Návod
Zadejte direktivy modulu runtime na vysoké úrovni, abyste aplikaci umožnili odolnost vůči změnám kódu. Doporučujeme přidávat direktivy runtime na úrovni oboru názvů a typů, nikoli na úrovni členských prvků. Mějte na paměti, že může dojít k kompromisu mezi odolností a většími binárními soubory s delší dobou kompilace.
Při řešení chybějící výjimky metadat zvažte tyto problémy:
Co se aplikace pokoušela udělat před výjimkou?
- Byla to například datová vazba, serializace nebo deserializace dat, nebo přímé použití Reflection API?
Jedná se o izolovaný případ, nebo se domníváte, že u jiných typů narazíte na stejný problém?
- Například výjimka MissingMetadataException je vyvolána při serializaci typu v objektovém modelu aplikace. Pokud znáte další typy, které budou serializovány, můžete přidat direktivy runtime pro tyto typy (nebo pro jejich obsahující obory názvů v závislosti na tom, jak dobře je kód uspořádán) ve stejnou dobu.
Můžete kód přepsat, aby se nepoužívala reflexe?
Například používá kód klíčové slovo
dynamic, když víte, jaký typ má očekávat?Volá kód metodu, která závisí na reflexi, když je k dispozici nějaká lepší alternativa?
Poznámka:
Další informace o řešení problémů, které vycházejí z rozdílů v reflexi a dostupnosti metadat v desktopových aplikacích a .NET Native, najdete v tématu rozhraní API, která spoléhají na reflexi.
Některé konkrétní příklady zpracování výjimek a dalších problémů, ke kterým dochází při testování aplikace, najdete tady:
výjimky modulu runtime v .NET Native Apps
Viz také
- Referenční soubor direktiv modulu runtime () ke konfiguraci (rd.xml)
- .NET nativní a kompilační
- Reflexe a .NET Native
- rozhraní API, která spoléhají na reflexe
- Serializace a Metadata
- Migrace vaší aplikace pro Windows 8.x na .NET Native