Felsöka problem med C++/WinRT

Note

Information om hur du installerar och använder VSIX (C++/WinRT Visual Studio Extension) (som tillhandahåller stöd för projektmall) finns i Visual Studio stöd för C++/WinRT.

Det här ämnet kommer först så att du känner till det direkt, även om du inte behöver det än. Tabellen med felsökningssymptom och åtgärder nedan kan vara till hjälp om du klipper ny kod eller porterar en befintlig app. Om du porterar och är angelägen om att gå vidare och komma till den fas där projektet bygger och körs kan du göra tillfälliga framsteg genom att kommentera eller stubba ut eventuell icke-nödvändig kod som orsakar problem och sedan återgå till att betala av den skulden senare.

En lista över vanliga frågor finns i Vanliga frågor och svar.

Spåra XAML-problem

XAML-parsningsfel kan vara svåra att diagnostisera, särskilt om det inte finns några meningsfulla felmeddelanden i undantaget. Kontrollera att felsökaren är konfigurerad för att fånga undantag från första chansen (för att försöka fånga upp parsningsfelet tidigt). Du kanske kan inspektera undantagsvariabeln i felsökningsprogrammet för att avgöra om HRESULT eller meddelandet har någon användbar information. Kontrollera också Visual Studio utdatafönster för felmeddelanden som matas ut av XAML-parsern.

Om appen avslutas och allt du vet är att ett ohanterat undantag genererades vid parsning av XAML-märkning, kan det bero på en referens (med nyckel) till en resurs som saknas. Eller så kan det vara ett undantag som utlöses i en UserControl, en anpassad kontroll eller en anpassad layoutpanel. En sista utväg är en binär delning. Ta bort ungefär hälften av markeringen från en XAML-sida och kör appen igen. Sedan vet du om felet finns någonstans inom den halva som du tog bort (som du nu bör återställa i alla fall) eller i den halva som du inte tog bort. Upprepa processen genom att dela upp den halva som innehåller felet och så vidare tills du har nollställt problemet.

Symtom och åtgärder

Symptom Lösning
Ett undantag genereras under körning med HRESULT-värdet REGDB_E_CLASSNOTREGISTERED. Se Varför får jag en "class not registered"-exception?
C++-kompilatorn genererar felet "'implements_type': är inte medlem i någon direkt eller indirekt basklass av "<projekterad typ>". Detta kan inträffa när du anropar make med det namn på din implementeringstyp som saknar namnområdeskvalificering (MyRuntimeClass, till exempel), och du inte har inkluderat den typens huvudfil. Kompilatorn tolkar MyRuntimeClass som den projicerade typen. Lösningen är att inkludera rubriken för din implementeringstyp (till exempel MyRuntimeClass.h).
C++-kompilatorn genererar felet "försöker referera till en borttagen funktion". Detta kan inträffa när du anropar make och implementationstypen som du skickar som mallparameter har en = delete standardkonstruktor. Redigera implementeringstypens huvudfil och ändra = delete till = default. Du kan också ange en konstruktor i IDL:n för körningsklassen.
Du har implementerat INotifyPropertyChanged, men dina XAML-bindningar uppdateras inte (och användargränssnittet prenumererar inte på PropertyChanged). Kom ihåg att ange Mode=OneWay (eller TwoWay) på bindningsuttrycket i XAML-markering. Se XAML-kontroller; binda till en C++/WinRT-egenskap.
Du binder en XAML-objektkontroll till en observerbar samling och ett undantag genereras vid körning med meddelandet "Parametern är felaktig". I din IDL och din implementering deklarerar du alla observerbara samlingar som typen Windows. Foundation.Collections.IVector<IInspectable>. Men returnera ett objekt som implementerar Windows. Foundation.Collections.IObservableVector<T>, där T är din elementtyp. Se XAML-objektkontroller; binda till en C++/WinRT-samling.
C++-kompilatorn genererar ett fel i formuläret "'MyImplementationType_base<MyImplementationType>': ingen lämplig standardkonstruktor tillgänglig". Detta kan inträffa när du har ärvt från en typ som har en icke-triviell konstruktor. Konstruktorn för den härledda typen måste vidarebefordra de parametrar som bastypens konstruktor behöver. För ett genomarbetat exempel, se Att härleda från en typ som har en konstruktor som inte är trivial.
C++-kompilatorn skapar felet "det går inte att konvertera från 'const std::vector<std::wstring,std::allocator<_Ty>>' till 'const winrt::p aram::async_iterable<winrt::hstring> &'". Detta kan inträffa när du skickar en std::vector av std::wstring till ett Windows Runtime API som förväntar sig en samling. Mer information finns i Standard C++-datatyper och C++/WinRT.
C++-kompilatorn skapar felet "det går inte att konvertera från 'const std::vector<winrt::hstring,std::allocator<_Ty>>' till 'const winrt::p aram::async_iterable<winrt::hstring> &'". Detta kan inträffa när du skickar en std::vector för winrt::hstring till ett asynkront Windows Runtime API som förväntar sig en samling, och du varken har kopierat eller flyttat vektorn till asynkront anropare. Mer information finns i Standard C++-datatyper och C++/WinRT.
När du öppnar ett projekt genererar Visual Studio felet "Programmet för projektet är inte installerat". Om du inte redan har gjort det måste du installera Windows App SDK C++-mallar och C++/WinRT-Visual Studio-tillägget (VSIX) (se Visual Studio stöd för C++/WinRT).
Windows App Certification Kit-testerna ger ett felmeddelande om att en av dina runtimeklasser "inte härleds från en basklass i Windows. Alla komponerbara klasser måste i slutändan härledas från en typ i namnrymden Windows". Alla körningsklasser (som du deklarerar i ditt program) som härleds från en basklass kallas för en sammansättningsbar klass. Den ultimata basklassen för en sammansättningsbar klass måste vara en typ som har sitt ursprung i ett Windows.* eller Microsoft.* namnområde, till exempel Microsoft. Användargränssnitt. Xaml.DependencyObject. Mer information finns i XAML-kontroller; bind till en C++/WinRT-egenskap .
C++-kompilatorn skapar ett "T måste vara WinRT-typ"-fel för en EventHandler- eller TypedEventHandler-delegatspecialisering. Överväg att använda winrt::delegate<...T> i stället. Se Skapa händelser i C++/WinRT.
C++-kompilatorn skapar felet "T måste vara WinRT-typ" för en Windows Runtime asynkron åtgärdsspecialisering. Överväg att i stället returnera en PPL-uppgift (Parallel Patterns Library). Se Samtidighet och asynkrona åtgärder.
C++-kompilatorn skapar felet "T måste vara WinRT-typ" när du anropar winrt::xaml_typename. Använd den projicerade typen med winrt::xaml_typename (till exempel BgLabelControlApp::BgLabelControl) och inte implementeringstypen (använd till exempel inte BgLabelControlApp::implementation::BgLabelControl). Se anpassade XAML-kontroller (mallstyrda).
C++-kompilatorn skapar "fel C2220: varning behandlas som fel – ingen objektfil genereras". Korrigera antingen varningen eller ange C/C++>Allmänt>Behandla varningar som feltill Nej (/WX-).
Appen kraschar eftersom en händelsehanterare i C++/WinRT-objektet anropas efter att objektet har förstörts. Se Säker åtkomst till this-pekaren med en delegat för händelsehantering.
C++-kompilatorn genererar "fel C2338: Detta är endast för svagt referensstöd". Du begär en svag referens för en typ som angav markörstrukturen winrt::no_weak_ref som ett mallargument till sin basklass. Se Inaktivera stöd för svaga referenser.
C++-kompilatorn skapar funktionen "consume_Something: som returnerar "auto" kan inte användas innan den definieras" Se C3779: Varför ger kompilatorn mig felet "consume_Something: funktion som returnerar "auto" kan inte användas innan den definieras?.
C++-länkaren skapar "fel LNK2019: Olöst extern symbol" Se Varför ger länkaren mig felet "LNK2019: Olöst extern symbol"?
Verktygskedjan LLVM och Clang genererar fel när de används med C++/WinRT. Vi stöder inte LLVM- och Clang-verktygskedjan för C++/WinRT, men om du vill emulera hur vi använder den internt kan du prova ett experiment som det som beskrivs i Kan jag använda LLVM/Clang för att kompilera med C++/WinRT?.
C++-kompilatorn skapar "ingen lämplig standardkonstruktor tillgänglig" för en projekterad typ. Om du försöker fördröja initieringen av ett körningsklassobjekt eller använda och implementera en körningsklass i samma projekt måste du anropa konstruktorn std::nullptr_t . Mer information finns i Använda API:er med C++/WinRT.
C++-kompilatorn genererar felet C3861: "from_abi": identifieraren hittades inte" och andra fel med ursprung i base.h. Du kan se det här felet om du använder Visual Studio 2017 (version 15.8.0 eller senare) och riktar in dig på Windows SDK version 10.0.17134.0 (Windows 10 version 1803). Ange antingen en senare (mer överensstämmande) version av Windows SDK eller ange projektegenskapen C/C++>Language>Conformance mode: Nej (även om /permissive- visas i projektegenskapen C/C++>Language>kommandorad under Ytterligare alternativ och ta sedan bort den).
C++-kompilatorn skapar felet C2039: 'IUnknown': är inte medlem i ''global namespace''". Se Så här gör du om ditt C++/WinRT-projekt till en senare version av Windows SDK.
C++-länkaren skapar "fel LNK2019: olöst extern symbol _WINRT_CanUnloadNow@0 refereras i funktion _VSDesignerCanUnloadNow@0" Se Så här gör du om ditt C++/WinRT-projekt till en senare version av Windows SDK.
Byggprocessen genererar felmeddelandet C++/WinRT VSIX tillhandahåller inte längre stöd för projektbygge. Lägg till en projektreferens till Microsoft.Windows. CppWinRT Nuget-paket. Installera Microsoft.Windows. CppWinRT NuGet-paketet i projektet. Mer information finns i Tidigare versioner av VSIX-tillägget.
C++-länkaren genererar fel LNK2019: olöst extern symbol, med ett omnämnande av winrt::impl::consume_Windows_Foundation_Collections_IVector. Från och med C++/WinRT 2.0, om du använder en intervallbaserad for på en Windows Runtime-samling måste du nu #include <winrt/Windows.Foundation.Collections.h>.
C++-kompilatorn skapar felet C4002: För många argument för funktionsliknande makroanrop GetCurrentTime. Se Hur löser jag tvetydigheter med GetCurrentTime och/eller TRY?.
C++-kompilatorn genererar felet C2334: oväntade token(er) före {; hoppar över den synliga funktionskroppen". Se Hur löser jag tvetydigheter med GetCurrentTime och/eller TRY?.
C++-kompilatorn producerar "winrt::impl::p roduce<D,I> cannot instantiate abstract class, due to missing GetBindingConnector". Du behöver #include <winrt/Microsoft.UI.Xaml.Markup.h>.
C++-kompilatorn genererar felet C2039: "promise_type": är inte medlem i "std::experimental::coroutine_traits<void>". Din coroutine måste antingen returnera ett asynkront åtgärdsobjekt eller winrt::fire_and_forget. Se Samtidighet och asynkrona åtgärder.
Projektet ger "tvetydig åtkomst till "PopulatePropertyInfoOverride". Det här felet kan inträffa när du deklarerar en basklass i din IDL och en annan basklass i XAML-markering.
När du läser in en C++/WinRT-lösning för första gången visas "Designtidsversionen kunde inte skapas för projektet 'MyProject.vcxproj' och konfigurationen 'Debug|x86'. IntelliSense kanske inte är tillgängligt.". Det här IntelliSense-problemet löser sig när du har skapat för första gången.
Att ange winrt::auto_revoke när du registrerar en delegerad resulterar i ett winrt::hresult_no_interface-undantag. Se Om ombudet för automatisk återkallelse inte kan registreras.
När du använder en C#-Windows Runtime komponent som använder XAML i en C++/WinRT-app genererar kompilatorn ett fel i formuläret "'MyNamespace_XamlTypeInfo': är inte medlem i 'winrt::MyNamespace'"- där MyNamespace är namnet på Windows Runtime komponentens namnområde. I pch.h i den C++/WinRT-app som använder den lägger du till #include <winrt/MyNamespace.MyNamespace_XamlTypeInfo.h> — ersätt MyNamespace efter behov.
I ett C++/WinRT-projekt i Visual Studio genererar IntelliSense ett fel av typen "fel E1696: kan inte öppna källfilen". Kompilera det nyligen skapade projektet minst en gång. Högerklicka sedan i källkodsredigeraren >Skanna om>Skanna om filen. Det löser alla IntelliSense-fel, inklusive E1696.

Note

Om det här avsnittet inte besvarade din fråga kan du få hjälp genom att gå till Visual Studio C++-utvecklarcommunityn eller genom att använda taggenc++-winrt på Stack Overflow.

Note

Många C++/WinRT-ämnen håller på att migreras från UWP-dokumentationen till det här avsnittet. Tills migreringen är klar kan länkar i listan nedan leda till avsnittet UWP-dokument. C++/WinRT-språkprojektionen är densamma för både UWP- och WinUI 3-appar, så att innehållet är tillämpligt i båda kontexterna. Alla UWP-specifika mönster (till exempel applivscykel eller Windows.UI namnområdes-API:er) anges uttryckligen i dessa artiklar.

  • Last updated on