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

Note

A C++/WinRT Visual Studio bővítmény (VSIX) telepítéséről és használatáról (amely projektsablonok támogatását biztosítja) a C++/WinRT Visual Studio támogatásával kapcsolatos információkért tekintse meg.

Ez a témakör már az elején szerepel, hogy rögtön tudjon róla, még akkor is, ha egyelőre 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ő konfigurálva van az első esélyű kivételek észlelésére (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 Visual Studio kimeneti ablakát, hogy az XAML-elemző hibaüzeneteket ad-e ki.

Ha az alkalmazás leáll, és csak annyi ismert, hogy egy nem kezelt kivétel történt az XAML-jelölőnyelv feldolgozása során, akkor ezt egy hiányzó erőforrásra való, kulcs szerinti hivatkozás is okozhatta. Vagy egy UserControlban, egy egyéni vezérlőben vagy egy egyéni elrendezési panelben keletkezett kivétel is lehet. 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 felosztja azt a felét, amelyben a hiba van, és így tovább, amíg pontosan be nem azonosítja a problémát.

Tünetek és jogorvoslatok

Hibajelenség	Orvoslat
Futásidőben REGDB_E_CLASSNOTREGISTERED HRESULT-értékkel kivétel keletkezik.	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 make függvényt a megvalósítási típus névtérrel nem minősített nevével (például MyRuntimeClass) hívja meg, és nem foglalta bele a típus fejlécfájlját. A fordító a MyRuntimeClass-t vetített típusként értelmezi. 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" hibaüzenetet eredményezi.	Ez akkor fordulhat elő, ha meghívja a make függvényt, és a sablonparaméterként átadott implementációs típus rendelkezik = delete alapértelmezett konstruktorral. Szerkessze az implementációtípus fejlécfájlját, és a(z) = delete helyére írja a következőt: = default. A futtatókörnyezeti osztály IDL-jéhez egy konstruktort is hozzáadhat.
Implementálta az INotifyPropertyChanged parancsot, de az XAML-kötések nem frissülnek (és a felhasználói felület nem a PropertyChangedre iratkozott fel).	Ne felejtse el beállítani a kötési kifejezésben a Mode=OneWay (vagy a TwoWay) értéket az XAML-jelölőnyelvben. 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 minden megfigyelhető gyűjteményt Windows.Foundation.Collections.IVector<IInspectable> típusként deklaráljon. De olyan objektumot adjon vissza, amely megvalósítja a Windows.Foundation.Collections.IObservableVector<T> felületet, ahol a 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: nincs 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. Egy bevált példáért lásd: Származtatás olyan típusból, amelynek nem triviális konstruktora van.
A C++ fordító a következő hibát adja: "nem lehet konvertálni innen: 'const std::vector<std::wstring,std::allocator<_Ty>>' ide: 'const winrt::param::async_iterable<winrt::hstring> &'".	Ez akkor fordulhat elő, ha std::vector of std::wstring értéket ad át egy Windows-futtatókörnyezet 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: "cannot convert from 'const std::vector<winrt::hstring,std::allocator<_Ty>>' to 'const winrt::param::async_iterable<winrt::hstring> &'".	Ez akkor fordulhat elő, ha egy gyűjteményt váró aszinkron Windows-futtatókörnyezet API-nak ad át egy std::vector of winrt::hstring parancsot, és nem másolta és nem is helyezte át a vektort az aszinkron callee-be. További információ: Standard C++ adattípusok és C++/WinRT.
Projekt megnyitásakor Visual Studio "A projekthez tartozó alkalmazás nincs telepítve" hibaüzenet jelenik meg.	Ha még nem tette meg, telepítenie kell a Windows App SDK C++ sablonokat és a C++/WinRT Visual Studio bővítményt (VSIX) (lásd Visual Studio C++/WinRT támogatását).
A Windows-alkalmazás minősítési 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írható osztálynak végül a Windows névtér egyik 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 egy Windows.* vagy Microsoft.* névtérből származó típusnak kell lennie, például Microsoft. UI. Xaml.DependencyObject. További részletekért lásd: XAML-vezérlők; kötés egy C++/WinRT tulajdonsághoz .
A C++ fordító egy EventHandler vagy TypedEventHandler delegálási specializáció esetén "T kell WinRT-típusnak lennie" hibaüzenetet eredményez.	Fontolja meg inkább a winrt::delegate<...T> használatát. Lásd: Szerzői események a C++/WinRT-ben.
A C++ fordító "T must be WinRT type" hibaüzenetet ad egy Windows-futtatókörnyezet aszinkron művelet specializációhoz.	Fontolja meg inkább egy Parallel Patterns Library (PPL) task visszaadását. 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 leképezett típust a winrt::xaml_typename típussal (például használja a BgLabelControlApp::BgLabelControl típust), ne pedig a megvalósítási típust (például ne használja a BgLabelControlApp::implementation::BgLabelControl típust). Lásd: XAML egyéni (sablonalapú) vezérlők.
A C++ fordító a következő hibaüzenetet adja: "C2220 hiba: a figyelmeztetés hibaként van kezelve – nem jön létre objektumfájl".	Javítsa ki a figyelmeztetést, vagy állítsa a C/C++>Általános>figyelmeztetések hibaként való kezelésétnem (/WX-) értékre.
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: Az egérmutató biztonságos elérése eseménykezelő meghatalmazottal.
A C++ fordító a következő hibát adja: "error C2338: Ez csak a gyenge hivatkozások támogatására szolgál".	Gyenge hivatkozást kér egy olyan típushoz, amely a winrt::no_weak_ref marker struktúrát sablonargumentumként adta át az alaposztályának. Lásd : A gyenge referenciatámogatás elutasítása.
A C++ fordító "consume_Something: az "auto" értéket visszaadó függvényt nem lehet használni a definiálás előtt.	Lásd C3779: Miért adja a fordító ezt a hibát: „consume_Something: az „auto” értéket visszaadó függvény nem használható, mielőtt definiálva lenne”?.
A C++ linker a következő hibát adja: "error LNK2019: nem feloldott 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ó "nincs megfelelő alapértelmezett konstruktor" értéket állít elő egy előrejelzett típushoz.	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ó: API-k felhasználása C++/WinRT használatával.
A C++ fordító a következő hibát adja: "C3861-es hiba: 'from_abi': azonosító nem található", valamint a base.h fájlból származó egyéb hibákat is. Ez a hiba akkor jelenhet meg, ha a Visual Studio 2017-es (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.	Vagy a Windows SDK egy későbbi (nagyobb megfelelőséget biztosító) verzióját célozza meg, vagy állítsa a projekt tulajdonságát C/C++>Language>Conformance mode: No értékre (továbbá, ha a /permissive- megjelenik a projekt tulajdonság C/C++>Language>Command Line részében, a Additional Options alatt, akkor törölje azt).
A C++ fordító a "C2039: "IUnknown" hibát állítja elő: nem tagja a "globális névtérnek".	Lásd: A C++/WinRT-projekt újraépítése a Windows SDK egy későbbi verziójára.
A C++-linker a következő hibát adja: "hiba LNK2019: feloldatlan külső szimbólum: _WINRT_CanUnloadNow@0; hivatkozás történt rá a(z) _VSDesignerCanUnloadNow@0 függvényben"	Lásd: A C++/WinRT-projekt újraépítése a Windows SDK egy későbbi verziójára.
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 csomag.	Telepítse a Microsoft.Windows. CppWinRT NuGet-csomag a projektbe. További részletekért lásd a VSIX-bővítmény korábbi verzióit.
A C++ csatoló hibát LNK2019: megoldatlan külső szimbólumot eredményez, a winrt::impl::consume_Windows_Foundation_Collections_IVector említéssel.	A C++/WinRT 2.0 verziótól kezdve, ha egy Windows-futtatókörnyezet-gyűjteményen tartományalapú for használ, akkor most már szüksége lesz erre: #include <winrt/Windows.Foundation.Collections.h>.
A C++ fordító a következő hibát adja: "C4002 hiba: Túl sok argumentum a(z) GetCurrentTime függvényszerű makró meghívásához".	Lásd: Hogyan oldhatom fel a getCurrentTime és/vagy a TRY használatával kapcsolatos kétértelműségeket?
A C++ fordító a következő hibaüzenetet adja: "C2334 hiba: váratlan token(ek) a(z) '{' előtt; a feltételezett 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ó a következő üzenetet adja: "winrt::impl::produce<D,I> nem lehet példányosítani az absztrakt osztályt a hiányzó GetBindingConnector miatt".	Önnek kell #include <winrt/Microsoft.UI.Xaml.Markup.h>.
A C++ fordító a "C2039: "promise_type" hibát állítja elő: nem tagja az "std::experimental::coroutine_traits<void>" kifejezésnek.	A korutinnak vagy egy aszinkron műveletet reprezentáló objektumot, vagy winrt::fire_and_forget-et kell visszaadnia. Lásd: Egyidejűség és aszinkron műveletek.
A projekt "a "PopulatePropertyInfoOverride" nem egyértelmű hozzáférését hozza létre.	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.
Egy C++/WinRT-megoldás első betöltésekor a következő üzenet jelenik meg: "A(z) „MyProject.vcxproj” projekt „Debug|x86” konfigurációjához tartozó tervezéskori build meghiúsult. Előfordulhat, hogy az IntelliSense nem lesz elérhető."	Ez az IntelliSense-probléma az első buildelés után megoldódik.
A winrt::auto_revoke megadása delegált regisztrálásakor winrt::hresult_no_interface kivételt eredményez.	Ellenőrizze , hogy az automatikus visszavonási meghatalmazott nem regisztrál-e.
A C++/WinRT-alkalmazásokban az XAML-t használó C# Windows-futtatókörnyezet összetevő használatakor a fordító "MyNamespace_XamlTypeInfo" formában hibát eredményez: nem tagja a "winrt::MyNamespace"-nek– ahol a MyNamespace az Windows-futtatókörnyezet összetevő névterének neve.	A(z) pch.h részben az azt felhasználó C++/WinRT-alkalmazásban adja hozzá a(z) #include <winrt/MyNamespace.MyNamespace_XamlTypeInfo.h> elemet — szükség szerint a(z) MyNamespace-et lecserélve.
Egy C++/WinRT-projektben Visual Studio intelliSense "E1696 hiba: nem nyílt forráskód fájl" hibaüzenetet ad ki.	Állítsa össze az újonnan létrehozott projektet legalább egyszer. Ezután kattintson a jobb gombbal a forráskódszerkesztőben a >Rescan>Rescan File elemre. Ez megoldja az Összes IntelliSense-hibát, beleértve az E1696-ot is.

Note

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ég felkeresésével, vagy a c++-winrt Stack Overflow címkéjének használatával.

Kapcsolódó témakörök

Note

Számos C++/WinRT-témakör áttelepítése folyamatban van az UWP dokumentációjából ebbe a szakaszba. A migrálás befejezéséig az alábbi listában szereplő hivatkozások az UWP-dokumentumok szakaszához vezethetnek. A C++/WinRT nyelvi kivetítés az UWP és a WinUI 3 alkalmazások esetében is megegyezik, így a tartalom mindkét környezetben alkalmazható. Ezek a cikkek kifejezetten feljegyzik az UWP-specifikus mintákat (például az alkalmazás életciklusát vagy Windows.UI a névtér API-kat).