C++/WinRT-problémák elhárítása

Megjegyzés:

Ha információt keres a C++/WinRT Visual Studio-bővítmény (VSIX) telepítéséről és használatáról, amely projekt sablontámogatást nyújt, tekintse meg a Visual Studio C++/WinRTtámogatását.

Ez a témakör azért van elöl, hogy azonnal tudjon róla, még akkor is, ha nincs rá szüksége. Az alábbi hibaelhárítási tüneteket és megoldásokat tartalmazó táblázat hasznos lehet önnek, akár új kódot vág, akár meglévő alkalmazást portoz. Ha portolást végez, és szeretne előrehaladni, és el szeretne jutni a projekt összeállításának és futtatásának szakaszához, akkor ideiglenesen továbbléphet a problémákat okozó nem alapvető kód megjegyzésével vagy csonkolásával, majd később visszatérhet a tartozás kiegyenlítéséhez.

A gyakori kérdések listáját a Gyakori kérdések című témakörben találja.

XAML-problémák nyomon követése

Az XAML-elemzési kivételeket nehéz diagnosztizálni – különösen akkor, ha a kivételen belül nincsenek értelmes hibaüzenetek. Győződjön meg arról, hogy a hibakereső úgy van konfigurálva, hogy elkapja az első esélyű kivételeket (az elemzési kivétel korai észleléséhez). A hibakeresőben megvizsgálhatja a kivételváltozót annak megállapításához, hogy a HRESULT vagy az üzenet hasznos információkkal rendelkezik-e. Emellett ellenőrizze a Visual Studio kimeneti ablakában, hogy az XAML-elemző által küldött hibaüzenetek ki lesznek-e adva.

Ha az alkalmazás leáll, és csak annyit tud, hogy nem kezelt kivétel történt az XAML-korrektúra elemzése során, akkor ez egy hiányzó erőforrásra mutató hivatkozás (kulcs alapján) eredménye lehet. Vagy lehet egy kivétel, amelyet egy UserControlben, egy egyéni vezérlőben vagy egy egyéni elrendezési panelen dobtak. A végső megoldás egy bináris felosztás. Távolítsa el a korrektúra körülbelül felét egy XAML-oldalról, és futtassa újra az alkalmazást. Ezután tudni fogja, hogy a hiba valahol az eltávolított félen belül van -e (amelyet most mindenképpen vissza kell állítania), vagy a felében, amelyet nem távolított el. Ismételje meg a folyamatot úgy, hogy azt a részt osztja fel, amely hibát tartalmaz, és így tovább, amíg meg nem találja a problémát.

Tünetek és jogorvoslatok

Tünet	Orvosság
Futtatás közben kivétel keletkezik, amelynek HRESULT értéke REGDB_E_CLASSNOTREGISTERED.	Lásd Miért kapok egy "osztály nincs regisztrálva" kivételt?.
A C++ fordító a "implements_type" hibát állítja elő: nem tagja a "<tervezett típus>" közvetlen vagy közvetett alaposztályának.	Ez akkor fordulhat elő, ha a megvalósítási típus névtér nélküli nevét () használja a meghívásakor (példáulMyRuntimeClass), és nem tartalmazza ennek a típusnak a fejlécét. A fordító MyRuntimeClass értelmezi előrejelzett típusként. A megoldás az implementáció típusának fejlécének belefoglalása (MyRuntimeClass.hpéldául).
A C++ fordító a "törölt függvényre való hivatkozás kísérlete" hibaüzenetet generálja.	Ez akkor fordulhat elő, ha meghívja , és a sablonparaméterként átadott implementációs típusnak van egy = delete alapértelmezett konstruktora. Szerkessze a megvalósítási típus fejlécfájlját, és módosítsa a = delete értéket = default-re. Konstruktort is hozzáadhat a futtatókörnyezeti osztály IDL-éhez.
Implementálta az INotifyPropertyChanged-t, de az XAML-kötések nem frissülnek (és a felhasználói felület nem feliratkozik PropertyChanged-ra).	Ne felejtse el beállítani a Mode=OneWay (vagy TwoWay) a kötési kifejezésben az XAML jelölésben. Lásd: XAML-vezérlők; kötés egy C++/WinRT tulajdonsághoz.
Egy XAML-elem vezérlőelemet egy megfigyelhető gyűjteményhez köt, és a rendszer kivételt küld futásidőben a "A paraméter helytelen" üzenettel.	Az IDL-ben és a megvalósításban deklaráljon minden megfigyelhető gyűjteményt Windows.Foundation.Collections.IVector<IInspectable> típusként. De adjon vissza egy objektumot, amely implementálja a Windows.Foundation.Collections.IObservableVector<T> objektumot, ahol T az elem típusa. Lásd: XAML-elemek vezérlői; kötés egy C++/WinRT-gyűjteményhez.
A C++ fordító a "MyImplementationType_base<MyImplementationType>"űrlap hibáját eredményezi: nem érhető el megfelelő alapértelmezett konstruktor".	Ez akkor fordulhat elő, ha nem triviális konstruktort tartalmazó típusból származik. A származtatott típus konstruktorának át kell adnia az alaptípus konstruktorának szükséges paramétereket. Kidolgozott példáért lásd: Olyan típusból származtatás, amelynek nem triviális konstruktora van.
A C++ fordító a "hibaüzenetet adja: 'nem lehet 'const std::vector<std::wstring,std::allocator<_Ty>>' értéket átalakítani 'const winrt::param::async_iterable<winrt::hstring> &'-ra'".	Ez akkor fordulhat elő, ha egy std::vector of std::wstring értéket ad át egy windowsos futtatókörnyezeti API-nak, amely gyűjteményt vár. További információ: Standard C++ adattípusok és C++/WinRT.
A C++ fordító a következő hibát adja: "nem lehet konvertálni a 'const std::vector<winrt::hstring,std::allocator<_Ty>>'-ből 'const winrt::param::async_iterable<winrt::hstring> &'-ra".	Ez akkor fordulhat elő, ha egy gyűjteményt váró aszinkron Windows Runtime API-nak ad át egy std::vector of winrt::hstring értéket, és a vektort nem másolta és nem is helyezte át az aszinkron callee-be. További információ: Standard C++ adattípusok és C++/WinRT.
Projekt megnyitásakor a Visual Studio a „A projekthez tartozó alkalmazás nincs telepítve” hibát produkálja.	Ha még nem tette meg, telepítenie kell Windows Univerzális windowsos eszközöket a C++ fejlesztési a Visual Studio Új projekt párbeszédpaneljén. Ha ez nem oldja meg a problémát, akkor a projekt a C++/WinRT Visual Studio Bővítménytől (VSIX) függhet (lásd a Visual Studio C++/WinRT támogatását.
A Windows Alkalmazástanúsítvány-készlet tesztjei hibát eredményeznek, amely miatt az egyik futtatókörnyezeti osztály "nem Windows alaposztályból származik. Az összes összeállítható osztálynak végső soron a Windows névtér egy típusából kell származnia".	Minden olyan futtatókörnyezeti osztályt (amelyet az alkalmazásban deklarál), amely egy alaposztályból származik, összeállítható osztálynak nevezzük. A összeállítható osztály végső alaposztályának Windows-névtérből származó típusnak kell lennie. például Windows.UI.Xaml.DependencyObject. Lásd: XAML-vezérlők; kötést egy C++/WinRT tulajdonsághoz további részletekért.
A C++ fordító egy EventHandler vagy TypedEventHandler delegált specializáció esetén "T kell WinRT-típusnak lennie" hibaüzenetet eredményez.	Fontolja meg a winrt::delegate<... T> használatát helyett. Lásd a szerzői eseményeket a C++/WinRT-ben.
A C++ fordító egy "T-nek WinRT típusnak kell lennie" hibaüzenetet ad a Windows Futtatókörnyezet aszinkron műveleteinek specializációja során.	Érdemes lehet inkább egy párhuzamos mintatárat (PPL) visszaadni feladat. Lásd: Egyidejűség és aszinkron műveletek.
A C++ fordító a winrt::xaml_typename hívásakor "T-nek WinRT-típusnak kell lennie" hibaüzenetet eredményez.	Használja a tervezett típust winrt::xaml_typename (például használja a BgLabelControlApp::BgLabelControl), és ne a megvalósítás típusát (például ne használja BgLabelControlApp::implementáció::BgLabelControl). Lásd: XAML egyéni (sablonalapú) vezérlők.
A C++ fordító "C2220- hiba: hibaként kezelt figyelmeztetést állít elő – nem generált objektumfájl".	Javítsa ki a figyelmeztetést, vagy állítsa be C/C++>Általános>a "Figyelmeztetések hibaként való kezelése" opciótNem (/WX-)-re.
Az alkalmazás összeomlik, mert a rendszer meghív egy eseménykezelőt a C++/WinRT objektumban az objektum megsemmisítése után.	Lásd: a this mutató biztonságos elérését egy eseménykezelő delegálttal.
A C++ fordító "C2338 hibát ad: Ez csak gyenge referenciatámogatás".	Gyenge referenciát kér egy olyan típushoz, amely a winrt::no_weak_ref jelölőszerkezetet sablonargumentumként adta át az alaposztálynak. Lásd: A gyenge referenciatámogatásletiltása.
A C++ fordító az alábbi hibaüzenetet adja: "consume_Something: a függvény, amely 'auto' értéket ad vissza, nem használható, mielőtt definiálnák".	Lásd C3779: Miért ad a fordító "consume_Something: olyan függvény, amely 'auto' típust ad vissza, nem használható a definiálás előtt" hibát?.
A C++ linker "hiba LNK2019: Megoldatlan külső szimbólum"	Lásd : Miért a linker ad nekem egy "LNK2019: Megoldatlan külső szimbólum" hibaüzenetet?.
Az LLVM és a Clang eszközlánc hibát okoz a C++/WinRT használatakor.	Nem támogatjuk a C++/WinRT-hez készült LLVM és Clang eszközláncot, de ha belsőleg szeretné emulálni, akkor kipróbálhat egy olyan kísérletet, mint a Can I use LLVM/Clang to compile with C++/WinRT?.
A C++ fordító „nem érhető el megfelelő alapértelmezett konstruktor” egy projektált típus esetén.	Ha egy futtatókörnyezeti osztályobjektum inicializálását szeretné késleltetni, vagy egy futtatókörnyezeti osztályt szeretne használni és implementálni ugyanabban a projektben, akkor meg kell hívnia az std::nullptr_t konstruktort. További információért lásd: API-k fogyasztása C++/WinRT segítségével.
A C++ fordító "C3861: "from_abi" hibát állít elő: az azonosító nem található", és egyéb, base.h-ból származó hibákat. Ez a hiba akkor jelenhet meg, ha a Visual Studio 2017-et (15.8.0-s vagy újabb verziót) használja, és a Windows SDK 10.0.17134.0-s verzióját (Windows 10, 1803-at) célozza meg.	Vagy a Windows SDK egy későbbi (konformabb) verzióját célozza meg, vagy állítsa be a projekttulajdonságot C/C++>Language>konformancia mód: Nincs (ha pedig a projekttulajdonságban C/C++>> alatti További beállításokközött megjelenik a /permissive-, akkor törölje).
A C++ fordító "C2039-hiba: "IUnknown" hibát állít elő: nem tagja a "globális névtér"".	Lásd Hogyan célozza meg újra C++/WinRT projektjét a Windows SDK egy későbbi verziójának.
A C++ linker "hiba LNK2019: a _VSDesignerCanUnloadNow@0 függvényben hivatkozott megoldatlan külső szimbólum _WINRT_CanUnloadNow@0" jelzi.	Lásd Hogyan célozza meg újra C++/WinRT projektjét a Windows SDK egy későbbi verziójának.
A buildelési folyamat a következő hibaüzenetet eredményezi : A C++/WinRT VSIX már nem nyújt projektépítési támogatást. Adjon hozzá egy projekthivatkozást a Microsoft.Windows.CppWinRT Nuget csomaghoz.	Telepítse a Microsoft.Windows.CppWinRT NuGet-csomagot a projektbe. További információ: VSIX-bővítmény korábbi verziói.
A C++ csatoló hibát LNK2019: megoldatlan külső szimbólumot, winrt::impl::consume_Windows_Foundation_Collections_IVector.	A C++/WinRT 2.0használata esetén, ha tartományalapú -t alkalmaz egy Windows Runtime gyűjteményen, akkor mostantól kell.
A C++ fordító "hiba C4002: Túl sok argumentum a GetCurrentTime függvényszerű makróhíváshoz" üzenetet ad.	Lásd: Hogyan oldhatom fel a getCurrentTime és/vagy a TRY használatával kapcsolatos kétértelműségeket?
A C++ fordító "C2334-hibát eredményez: váratlan token(ek) a(z) "{" előtt; a látszólagos függvénytörzs kihagyása".	Lásd: Hogyan oldhatom fel a getCurrentTime és/vagy a TRY használatával kapcsolatos kétértelműségeket?
A C++ fordító nem tudja példányosítani az "winrt::impl::produce<D,I>" absztrakt osztályt, mert hiányzik a GetBindingConnector.	Meg kell tenned #include <winrt/Windows.UI.Xaml.Markup.h>.
A C++ fordító "C2039: "promise_type" hibát állít elő: nem tagja az "std::experimental::coroutine_traits<void>"" hibának.	A koroutinnak vagy egy aszinkron műveleti objektumot, vagy winrt::fire_and_forgetkell visszaadnia. Lásd: Egyidejűség és aszinkron műveletek.
A projekt "nem egyértelmű hozzáférést biztosít a "PopulatePropertyInfoOverride""- hoz.	Ez a hiba akkor fordulhat elő, ha egy alaposztályt deklarál az IDL-ben, és egy másik alaposztályt az XAML-korrektúrában.
C++/WinRT-megoldás első betöltésekor "A 'MyProject.vcxproj' projekt 'Debug|x86' konfigurációjának tervezési idejű buildje nem sikerült. Előfordulhat, hogy az IntelliSense nem érhető el.".	Ez az IntelliSense-probléma az első buildelés után megoldódik.
Amikor megpróbálja megadni a winrt::auto_revoke értékeket egy delegált regisztrálásakor, egy winrt::hresult_no_interface kivételt eredményez.	Lásd: Ha az automatikus visszavonási meghatalmazott nem regisztrál.
Egy C++/WinRT-alkalmazásban az XAML-t használó C# Windows-futtatókörnyezet-összetevő használatakor a fordító "MyNamespace_XamlTypeInfo" formában hibát okoz: nem tagja a "winrt::MyNamespace"-nek– ahol a MyNamespace a Windows futtatókörnyezet összetevő névterének neve.	A C++/WinRT alkalmazásban pch.h, adja hozzá #include <winrt/MyNamespace.MyNamespace_XamlTypeInfo.h>-t —és szükség szerint cserélje le MyNamespace.
Visual Studio-ban egy C++/WinRT projektben az IntelliSense a következő hibát adja: "E1696 hiba: nem tudja megnyitni aforrásfájlt".	Állítsa össze az újonnan létrehozott projektet legalább egyszer. Ezután kattintson a jobb gombbal a forráskódszerkesztőben, >Újravizsgálat>Fájl újbóli vizsgálata. Ez megoldja az Összes IntelliSense-hibát, beleértve az E1696-ot is.

Megjegyzés:

Ha ez a témakör nem válaszolt a kérdésére, akkor segítséget kaphat a Visual Studio C++ fejlesztői közösségfelkeresésével, vagy a Stack Overflow címkéjének használatával.