Freigeben über


Diagnostizieren von Fehlerbedingungen der Windows-Runtime-Komponente

Dieser Artikel enthält zusätzliche Informationen zu den Einschränkungen bei Windows-Runtime Komponenten, die mit verwaltetem Code geschrieben wurden. Sie erfahren mehr zu den Fehlermeldungen von Winmdexp.exe (Windows-Runtime-Metadaten-Exporttool) sowie zu den Einschränkungsinformationen in Erstellen von Windows-Runtime-Komponenten in C# und Visual Basic.

Allerdings werden nicht alle Fehler abgedeckt. Die beschriebenen Fehler wurden in allgemeine Kategorien eingeteilt, wobei jede Kategorie eine Tabelle mit zugehörigen Fehlermeldungen enthält. Suchen Sie nach dem Meldungstext (vermeiden Sie Werte für Platzhalter) oder nach der Meldungsnummer. Sollten Sie die gewünschten Informationen nicht finden, können Sie mithilfe der Feedbackschaltfläche am Ende dieses Artikels zur Inhaltsverbesserung beitragen. Geben Sie die Fehlermeldung an. Oder melden Sie den Fehler auf der Microsoft Connect-Website.

Dieser Artikel umfasst folgende Abschnitte:

  • Bei Implementierung asynchroner Muster, stellt Fehlermeldung falschen Typ bereit

  • Fehlende Verweise an mscorlib.dll und/oder System.Runtime.dll

  • Operatorüberladung ist nicht erlaubt

  • Konstruktoren einer Klasse verfügen über die gleiche Anzahl von Parametern

  • Ein Standard für Überladungen, die die gleiche Anzahl von Parametern haben, muss festgelegt werden

  • Namespacefehler und ungültige Namen für die Ausgabedatei

  • Exportieren von Typen, die keine zulässigen Windows-Runtime-Typen sind

  • Strukturen, die Felder unzulässiger Typen enthalten

  • Einschränkungen für Arrays in Membersignaturen

  • Arrayparameter müssen angeben, ob Arrayinhalte lesbar oder schreibbar sind

  • Member mit einem Parameter namens "Wert"

Fehlermeldung zum Implementieren der asynchronen Schnittstelle stellt falschen Typ bereit

Verwaltete Windows-Runtime-Komponenten ermöglichen keine Implementierung der Windows-Runtime-Schnittstellen, die asynchrone Aktionen oder Vorgänge darstellen (IAsyncAction IAsyncActionWithProgress<TProgress>, IAsyncOperation<TResult> und IAsyncOperationWithProgress<TResult, TProgress>). Stattdessen stellt das .NET Framework die AsyncInfo-Klasse zum Generieren von asynchronen Operationen in Windows-Runtime-Komponenten bereit. Die von der Winmdexp.exe bei dem Versuch eine asynchrone Schnittstelle falsch zu implementieren angezeigte Fehlermeldung, bezeichnet diese Klasse mit ihrem früheren Namen AsyncInfoFactory. .NET Framework schließt keine AsyncInfoFactory-Klasse mehr ein.

Fehlernummer

Meldungstext

WME1084

Der Typ '{0}' implementiert die Async-Schnittstelle '{1}' für Windows-Runtime. Windows-Runtime-Typen dürfen keine Async-Schnittstellen implementieren. Verwenden Sie die System.Runtime.InteropServices.WindowsRuntime.AsyncInfoFactory-Klasse, um asynchrone Vorgänge für den Export in die Windows-Runtime zu erstellen.

Fehlende Verweise an mscorlib.dll oder System.Runtime.dll

Dieses Problem tritt nur auf, wenn Sie Winmdexp.exe aus der Befehlszeile ausführen. Wir empfehlen die Verwendung der Option /reference, um Verweise auf mscorlib.dll und System.Runtime.dll von .NET Framework-Kernverweisassemblys einzuschließen, die sich in "%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5" befinden ("%ProgramFiles%\..." auf einem 32-Bit-Computer).

Fehlernummer

Meldungstext

WME1009

Es wurde kein Verweis auf "mscorlib.dll" festgelegt. Für den ordnungsgemäßen Export ist ein Verweis auf diese Metadatendatei erforderlich.

WME1090

Die Kernverweisassembly konnte nicht ermittelt werden. Vergewissern Sie sich, dass mit dem Schalter "/reference" auf mscorlib.dll und System.Runtime.dll verwiesen wird.

Operatorüberladung ist nicht erlaubt

In einer Windows-Runtime Komponente, die in verwaltetem Code geschrieben wurde, können Sie keine überladenen Operatoren auf öffentlichen Typen verfügbar machen.

Hinweis

In der Fehlermeldung wird der Operator über die Metadaten identifiziert, zum Beispiel op_Addition, op_Multiply, op_ExclusiveOr, op_Implicit (implizite Konvertierung) usw.

Fehlernummer

Meldungstext

WME1087

"{0}" ist eine Operatorüberladung. Verwaltete Typen können Operatorüberladungen in Windows-Runtime nicht verfügbar machen.

Konstruktoren einer Klasse verfügen über die gleiche Anzahl von Parametern

In Windows-Runtime kann eine Klasse nur über einen Konstruktor mit einer bestimmten Anzahl von Parametern verfügen. Sie können beispielsweise keinen Konstruktor nutzen, der einen einzelnen Parameter vom Typ String und einen anderen einzelnen Parameter vom Typ int (Integer in Visual Basic) aufweist. Das Problem kann nur umgangen werden, indem für jeden Konstruktor eine andere Anzahl von Parametern verwendet wird.

Fehlernummer

Meldungstext

WME1099

Typ "{0}" verfügt über mehrere Konstruktoren mit "{1}" Argumenten. Windows-Runtime-Typen können nicht mehrere Konstruktoren mit der gleichen Anzahl von Argumenten aufweisen.

Ein Standard für Überladungen, die die gleiche Anzahl von Parametern haben, muss festgelegt werden

In Windows-Runtime können überladene Methoden nur dann über die gleiche Anzahl von Parametern verfügen, wenn eine Überladung als Standardüberladung angegeben wird. Weitere Informationen finden Sie in "Überladene Methoden" unter Erstellen von Windows-Runtime-Komponenten in C# und Visual Basic.

Fehlernummer

Meldungstext

WME1059

Mehrere {0}-Parameterüberladungen von "{1}.{2}" sind mit Windows.Foundation.Metadata.DefaultOverloadAttribute versehen.

WME1085

Für die {0}-Parameterüberladungen von {1}.{2} muss genau eine Methode als Standardüberladung angegeben werden, indem diese mit Windows.Foundation.Metadata.DefaultOverloadAttribute versehen wird.

Namespacefehler und ungültige Namen für die Ausgabedatei

In Windows-Runtime müssen sich alle öffentlichen Typen in einer Windows-Metadatendatei (WINMD) in einem Namespace, der den WINMD-Dateinamen freigibt, oder in den Subnamespaces des Dateinamens befinden. Wenn Sie Ihr Visual Studio 2012-Projekt A.B nennen (also die Windows-Runtime-Komponente A.B.WINMD ist), kann es die öffentlichen Klassen A.B.Class1 und A.B.C.Class2 enthalten, jedoch nicht A.Class3 (WME0006) oder D.Class4 (WME1044).

Hinweis

Diese Einschränkungen gelten nur für öffentliche Typen, nicht für die privaten Typen, die in der Implementierung verwendet werden.

Bei A.Class3 können Sie entweder Class3 auf einen anderen Namespace verschieben oder den Namen der Windows-Runtime-Komponente in A.WINMD ändern. Obwohl WME0006 eine Warnung ist, sollten Sie sie als Fehler behandeln. Im vorherigen Beispiel konnte A.Class3 nicht vom Code, der A.B.WINMD aufruft, gefunden werden.

Bei D.Class4 kann der Dateiname weder D.Class4 noch Klassen im A.B-Namespace enthalten. Der Windows-Runtime-Komponentenname lässt sich also nicht ändern. Sie können D.Class4 entweder auf einen anderen Namespace verschieben oder in eine andere Windows-Runtime-Komponente einfügen.

Das Dateisystem kann nicht zwischen Groß- und Kleinschreibung unterscheiden. Namespaces mit unterschiedlicher Groß- und Kleinschreibung sind also nicht zulässig (WME1067).

Die Komponente muss mindestens einen public sealed-Typ (Public NotInheritable in Visual Basic) enthalten. Ansonsten erhalten Sie die Fehlermeldungen WME1042 oder WME1043 (abhängig davon, ob die Komponente private Typen enthält oder nicht).

Ein Typ in einer Windows-Runtime-Komponente kann nicht wie ein Namespace benannt werden (WME1068).

Warnung

Wenn Sie Winmdexp.exe direkt aufrufen und für die Benennung der Windows-Runtime-Komponente nicht die /out-Option verwenden, generiert Winmdexp.exe einen Namen, der alle Namespaces in der Komponente enthält. Die Umbenennung von Namespaces kann zur Änderung des Komponentennamens führen.

Fehlernummer

Meldungstext

WME0006

"{0}" ist kein gültiger WINMD-Dateiname für diese Assembly. Alle Typen in einer Windows-Metadatendatei müssen in einem Subnamespace des im Dateinamen enthaltenen Namespace vorhanden sein. Typen, die nicht in solch einem Subnamespace vorhanden sind, werden während der Laufzeit nicht gefunden. In dieser Assembly lautet der kleinste gemeinsame Namespace, der als Dateiname verwendet werden kann, "{1}".

WME1042

Das Eingabemodul muss mindestens einen öffentlichen Typ enthalten, der sich in einem Namespace befindet.

WME1043

Das Eingabemodul muss mindestens einen öffentlichen Typ enthalten, der sich in einem Namespace befindet. In den Namespaces wurden nur private Typen gefunden.

WME1044

Ein öffentlicher Typ hat einen Namespace ("{1}"), der kein gemeinsames Präfix mit anderen Namespaces ("{0}") aufweist. Alle Typen in einer Windows-Metadatendatei müssen in einem Subnamespace des im Dateinamen enthaltenen Namespace vorhanden sein.

WME1067

Namespace-Namen dürfen sich nicht nur in der Groß-/Kleinschreibung unterscheiden: "{0}", "{1}".

WME1068

Der Typ ''{0}" darf nicht denselben Namen wie der Namespace ''{1}" aufweisen.

Exportieren von Typen, die keine gültigen Windows-Runtime-Typen sind

Die öffentliche Schnittstelle der Komponente darf nur Windows-Runtime-Typen verfügbar machen. Das .NET Framework stellt aber auch Zuordnungen für einige häufig verwendete Typen bereit, die in .NET Framework und in Windows-Runtime Unterschiede aufweisen. Somit kann der .NET Framework-Entwickler mit bekannten Typen arbeiten, anstatt sich erst mit neuen Typen vertraut machen zu müssen. Sie können diese verwenden zugeordnetes .NET Framework in die öffentliche Schnittstelle der Komponente. Weitere Informationen finden Sie in "Typen in Windows-Runtime-Komponenten deklarieren" und "Windows-Runtime-Typen an verwalteten Code übergeben" unter Erstellen von Windows-Runtime-Komponenten in C# und Visual Basic und .NET Framework-Zuordnungen von Windows-Runtime-Typen.

Viele dieser Zuordnungen sind Schnittstellen. Beispielsweise wird IList<T> der Windows-Runtime-Schnittstelle IVector<T> zugeordnet. Wenn Sie als Parametertyp List<string> (List(Of String) in Visual Basic) anstelle von IList<string> verwenden, stellt Winmdexp.exe stellt eine Liste von Alternativen zur Verfügung, die alle zugeordneten Schnittstellen enthält, die von List<T> implementiert wurden. Bei Verwendung von geschachtelten generischen Typen, wie List<Dictionary<int, string>> (List(Of Dictionary(Of Integer, String)) in Visual Basic) bietet Winmdexp.exe verschiedene Optionen für jede Schachtelungsebene an. Diese Listen können recht lang sind.

Im Allgemeinen sollte die Schnittstelle ausgewählt werden, die dem Typ am nächsten ist. Für Dictionary<int, string> ist beispielsweise IDictionary<int, string> die beste Auswahl.

Wichtig

JavaScript verwendet die Schnittstelle, die zuerst in der Liste der Schnittstellen angezeigt wird, die ein verwalteter Typ implementiert. Wenn Sie beispielsweise Dictionary<int, string> an JavaScript-Code zurückgeben, wird es stets als IDictionary<int, string> angezeigt, unabhängig vom angegebenen Rückgabetyp. Dies bedeutet, dass die erste Schnittstelle Member enthalten muss, die auch auf den neueren Schnittstellen erscheinen. Ansonsten ist ein Member nicht für JavaScript sichtbar.

Warnung

Vermeiden Sie die nicht generischen Schnittstellen IList und IEnumerable, wenn die Komponente von JavaScript verwendet wird. Diese Schnittstellen enthalten Zuordnungen zu IBindableVector und IBindableIterator. Sie unterstützen Bindung für XAML-Steuerelemente und sind für JavaScript nicht sichtbar. JavaScript generiert eine Laufzeitfehlermeldung mit der Aussage, dass die Funktion "X" über eine ungültige Signatur verfügt und nicht aufgerufen werden kann.

Fehlernummer

Meldungstext

WME1033

Die Methode "{0}'' weist den Parameter ''{1}" vom Typ "{2}'' auf. ''{2}" ist kein gültiger Windows-Runtime-Parametertyp.

WME1038

Die Methode "{0}'' weist in der Signatur einen Parameter vom Typ "{1}'' auf. Obwohl dieser Typ kein gültiger Windows-Runtime-Typ ist, implementiert er Schnittstellen, bei denen es sich um gültige Windows-Runtime-Typen handelt. Ändern Sie eventuell die Methodensignatur für die Verwendung eines der folgenden Typen: "{2}".

WME1039

Die Methode "{0}'' weist in der Signatur einen Parameter vom Typ "{1}'' auf. Obwohl es sich bei diesem generischen Typ nicht um einen gültigen Windows-Runtime-Typ handelt, werden von diesem Typ oder von dessen generischen Parametern Schnittstellen implementiert, die gültige Windows-Runtime-Typen sind. {2}

HinweisHinweis
Für {2}, fügt Winmdexp.exe eine Liste von Alternativen an, wie "Ändern Sie eventuell den Typ 'System.Collections.Generic.List<T>' in der Methodensignatur zu einem der folgenden Typen: 'System.Collections.Generic.IList<T>, System.Collections.Generic.IReadOnlyList<T>, System.Collections.Generic.IEnumerable<T>'."

WME1040

Die Methode "{0}'' weist in der Signatur einen Parameter vom Typ "{1}'' auf. Verwenden Sie anstelle eines verwalteten Aufgabentyps Windows.Foundation.IAsyncAction, Windows.Foundation.IAsyncOperation oder eine der anderen Async-Schnittstellen für Windows-Runtime. Das Standardmuster für .NET-Await wird auch auf diese Schnittstellen angewendet. Weitere Informationen zum Konvertieren von verwalteten Task-Objekten in Async-Schnittstellen für Windows-Runtime finden Sie unter System.Runtime.InteropServices.WindowsRuntime.AsyncInfo.

Strukturen, die Felder unzulässiger Typen enthalten

In Windows-Runtime kann eine Struktur nur Felder enthalten, und nur Strukturen können Felder enthalten. Diese Felder müssen öffentlich sein. Gültige Feldtypen umfassen Strukturen, Enumerationen und primitive Typen.

Fehlernummer

Meldungstext

WME1060

Die Struktur "{0}" weist das Feld ''{1}" vom Typ ''{2}" auf. ''{2}" ist kein gültiger Windows-Runtime-Feldtyp. Die Felder in einer Windows-Runtime-Struktur müssen vom Typ UInt8, Int16, UInt16, Int32, UInt32, Int64, UInt64, Single, Double, Boolean, String, oder Enum sein, oder sie müssen selbst eine Struktur darstellen.

Einschränkungen für Arrays in Membersignaturen

In Windows-Runtime müssen Arrays in den Membersignaturen eindimensional sein und eine Untergrenze von 0 (null) aufweisen. Geschachtelte Arraytypen wie myArray[][] (myArray()() in Visual Basic) sind nicht zulässig.

Hinweis

Diese Einschränkung gilt nicht für Arrays, die Sie intern in der Implementierung verwenden.

Fehlernummer

Meldungstext

WME1034

Die Methode ''{0}" weist ein Array des Typs ''{1}" auf, dessen untere Grenze in der Signatur ungleich null ist. Arrays in Windows-Runtime-Methodensignaturen müssen eine Untergrenze von null aufweisen.

WME1035

Die Methode ''{0}" weist in der Signatur ein mehrdimensionales Array des Typs ''{1}" auf. Arrays in Windows-Runtime-Methodensignaturen müssen eindimensional sein.

WME1036

Die Methode ''{0}" weist in der Signatur ein geschachteltes Array des Typs ''{1}" auf. Arrays in Windows-Runtime-Methodensignaturen können nicht geschachtelt werden.

Arrayparameter müssen angeben, ob Arrayinhalte lesbar oder schreibbar sind

In Windows-Runtime müssen Parameter schreibgeschützt oder lesegeschützt sein. Parameter können nicht als ref (ByRef gekennzeichnet sein (ohne das OutAttribute-Attribut in Visual Basic). Dies gilt für den Inhalt von Arrays. Daher müssen Arrayparameter angeben, ob der Arrayinhalt schreibgeschützt oder lesegeschützt ist. Die Richtung ist für out-Parameter klar vorgegeben (ByRef-Parameter mit dem OutAttribute-Attribut in Visual Basic). Aber Arrayparameter, die als Wert übergeben werden (ByVal in Visual Basic), müssen markiert werden. Weitere Informationen finden Sie unter Übergeben von Arrays an eine Windows-Runtime-Komponente.

Fehlernummer

Meldungstext

WME1101

Die Methode ''{0}" weist den Parameter ''{1}" auf. Dieser Array verfügt über {2} und {3}. Die Inhalte von Arrayparametern müssen in der Windows-Runtime entweder lesbar oder schreibbar sein. Entfernen Sie eines der Attribute aus ''{1}".

WME1102

Die Methode ''{0}" weist den Ausgabeparameter ''{1}" auf. Dabei handelt es sich um einen Array mit {2}. Die Inhalte von Ausgabearrays sind in der Windows-Runtime schreibbar. Entfernen Sie das Attribut aus ''{1}".

WME1103

Die Methode "{0}" verfügt über den Parameter "{1}". Dabei handelt es sich um ein Array mit System.Runtime.InteropServices.InAttribute oder System.Runtime.InteropServices.OutAttribute. In Windows-Runtime müssen Arrayparameter entweder {2} oder {3} aufweisen. Entfernen Sie diese Attribute oder ersetzen Sie sie bei Bedarf durch das entsprechende Windows-Runtime-Attribut.

WME1104

Die Methode '''{0}" weist den Parameter ''{1}" auf. Dabei handelt es sich um ein Array mit {2} oder {3}. Das Markieren von Nichtarrayparametern mit {2} oder {3} wird von Windows-Runtime nicht unterstützt.

WME1105

Die Methode ''{0}" enthält den Parameter ''{1}" mit einem System.Runtime.InteropServices.InAttribute oder System.Runtime.InteropServices.OutAttribute. Das Markieren von Parametern mit System.Runtime.InteropServices.InAttribute oder System.Runtime.InteropServices.OutAttribute wird von Windows-Runtime nicht unterstützt. Entfernen Sie eventuell System.Runtime.InteropServices.InAttribute, und ersetzen Sie System.Runtime.InteropServices.OutAttribute stattdessen durch den 'out'-Modifizierer.

Die Methode ''{0}" enthält den Parameter ''{1}" mit einem System.Runtime.InteropServices.InAttribute oder System.Runtime.InteropServices.OutAttribute. Windows Runtime unterstützt nur das Markieren von ByRef-Parametern mit System.Runtime.InteropServices.OutAttribute und unterstützt keine andere Verwendung dieser Attribute.

WME1106

Die Methode ''{0}" weist den Parameter "{1}'' auf. Dabei handelt es sich ein Array. In der Windows-Runtime müssen die Inhalte von Arrayparametern entweder lesbar oder schreibbar sein. Wenden Sie auf "{1}" entweder {2} oder {3} an.

Member mit einem Parameter namens "Wert"

In Windows-Runtime werden Rückgabewerte als Ausgabeparameter betrachtet, und die Namen der Parameter müssen eindeutig sein. Standardmäßig gibt Winmdexp.exe dem Rückgabewert den Namen "Wert". Wenn die Methode einen Parameter namens "Wert" hat, erhalten Sie die Fehlermeldung WME1092. Es gibt zwei Korrekturmöglichkeiten:

  • Nennen Sie den Parameter nicht "Wert" (in den Eigenschaftenaccessoren sollte der Parameter nicht "returnValue" heißen).

  • Verwenden Sie das Attribut ReturnValueNameAttribute, um den Namen des Rückgabewerts zu ändern wie hier gezeigt:

    using System.Runtime.InteropServices;
    using System.Runtime.InteropServices.WindowsRuntime;
    
    [return: ReturnValueName("average")]
    public int GetAverage(out int lowValue, out int highValue)
    
    Imports System.Runtime.InteropServices Imports System.Runtime.InteropServices.WindowsRuntime Public Function GetAverage(<Out> ByRef lowValue As Integer, _ <Out> ByRef highValue As Integer) As <ReturnValueName("average")> String
    

    Hinweis

    Wenn Sie den Namen des Rückgabewerts ändern und der neue Name mit dem Namen eines anderen Parameters in Konflikt steht, erhalten Sie die Fehlermeldung WME1091.

JavaScript-Code kann auf die Ausgabeparameter einer Methode über den Namen zugreifen, einschließlich Rückgabewert. Ein Beispiel finden Sie unter der Beschreibung des ReturnValueNameAttribute-Attributs.

Fehlernummer

Meldungstext

WME1091

Die Methode ''{0}" weist den Rückgabewert mit dem Namen ''{1}" auf. Dieser ist mit dem Parameternamen identisch. Methodenparameter und Rückgabewerte müssen für Windows-Runtime eindeutige Namen aufweisen.

WME1092

Die Methode "{0}" weist einen Parameter mit dem Namen "{1}" auf, der mit dem Standardnamen des Rückgabewerts identisch ist. Verwenden Sie ggf. einen anderen Namen für den Parameter, oder verwenden Sie das System.Runtime.InteropServices.WindowsRuntime.ReturnValueNameAttribute, um den Namen des Rückgabewerts explizit anzugeben.

HinweisHinweis
Der Standardname lautet "returnValue" für Eigenschaftenaccessoren und "Wert" für alle anderen Methoden.

Siehe auch

Referenz

Winmdexp.exe (Windows-Runtime-Metadaten-Exporttool)

Konzepte

Erstellen von Windows-Runtime-Komponenten in C# und Visual Basic