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.

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).

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.

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.

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.

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).

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).

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.

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} Hinweis 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.

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.

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.

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. Hinweis 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