Diagnose von C#/WinRT-Komponentenfehlern

Dieser Artikel bietet zusätzliche Informationen zu Einschränkungen bei Windows-Runtime-Komponenten, die mit C#/WinRT geschrieben wurden. Er führt die Informationen weiter aus, die in Fehlermeldungen von C#/WinRT bereitgestellt werden, wenn ein Autor seine Komponente erstellt. Bei bestehenden, verwalteten .NET Native-UWP-Komponenten werden die Metadaten für C#/WinRT-Komponenten mithilfe von Winmdexp.exe, einem .NET-Tool, generiert. Da die Windows-Runtime-Unterstützung nun von .NET entkoppelt ist, stellt C#/WinRT die Tools zum Generieren einer WINMD-Datei aus Ihrer Komponente bereit. Die Windows-Runtime weist mehr Einschränkungen für Code auf als eine C#-Klassenbibliothek, und der C#/WinRT-Diagnosescanner macht Sie vor dem Generieren einer WINMD-Datei auf diese Tatsache aufmerksam.

In diesem Artikel werden die Fehler behandelt, die in Ihrem Build von C#/WinRT gemeldet werden. Dieser Artikel dient als aktualisierte Version der Informationen zu Einschränkungen für bestehende verwaltete .NET Native-UWP-Komponenten, die das „Winmdexp.exe“-Tool verwenden.

Suchen Sie nach dem Fehlermeldungstext (ohne bestimmte Werte für Platzhalter) oder der Meldungsnummer. Falls Sie die benötigten Informationen hier nicht finden, können Sie mithilfe der Feedback-Schaltfläche am Ende dieses Artikels zur Verbesserung der Dokumentation beitragen. Fügen Sie in Ihrem Feedback die Fehlermeldung ein. Alternativ können Sie einen Fehler im C#/WinRT-Repository melden.

In diesem Artikel werden Fehlermeldungen nach Szenario organisiert.

Implementieren von Schnittstellen, die keine gültigen Windows-Runtime-Schnittstellen sind

C#/WinRT-Komponenten können keine bestimmten Windows-Runtime-Schnittstellen implementieren, wie z. B. die Windows-Runtime-Schnittstellen, die asynchrone Aktionen oder Vorgänge darstellen (IAsyncAction, IAsyncActionWithProgress<TProgress>, IAsyncOperation<TResult> oder IAsyncOperationWithProgress<TResult, TProgress>). Verwenden Sie stattdessen die AsyncInfo-Klasse zum Generieren von asynchronen Vorgängen in Windows-Runtime-Komponenten. Hinweis: Dies sind nicht die einzigen ungültigen Schnittstellen, z. B. kann eine Klasse nicht System.Exception implementieren.

Fehlernummer

Meldungstext

CsWinRT1008

Windows-Runtime-Komponententyp{0} kann die Schnittstelle {1} nicht implementieren, da die Schnittstelle keine gültige Windows-Runtime-Schnittstelle ist.

In der Windows-Runtime können überladene Methoden nur dann über dieselbe Anzahl von Parametern verfügen, wenn eine Überladung als Standardüberladung angegeben wird. Verwenden Sie das Attribut Windows. Foundation.Metadata.DefaultOverload (CsWinRT1015, 1016).

Wenn Arrays als Eingaben oder Ausgaben in Funktionen oder Eigenschaften verwendet werden, müssen sie entweder schreibgeschützt oder lesegeschützt sein (CsWinRT 1025). Die Attribute System.Runtime.InteropServices.WindowsRuntime.ReadOnlyArray und System.Runtime.InteropServices.WindowsRuntime.WriteOnlyArray werden zu Ihrer Verwendung für Sie bereitgestellt. Die bereitgestellten Attribute dürfen nur für Parameter des Arraytyps (CsWinRT1026) verwendet werden, und es sollte immer nur eins pro Parameter angewendet werden (CsWinRT1023).

Sie müssen kein Attribut auf einen array-Parameter anwenden, der als out gekennzeichnet ist, da angenommen wird, dass er lesegeschützt ist. Es wird eine Fehlermeldung angezeigt, wenn Sie ihn in diesem Fall mit schreibgeschützt versehen (CsWinRT1024).

Die Attribute System.Runtime.InteropServices.InAttribute und System.Runtime.InteropServices.OutAttribute dürfen nicht für Parameter, egal welchen Typs, verwendet werden (CsWinRT1021,1022).

Fehlernummer

Meldungstext

CsWinRT1015

In Klasse {2}: Mehrere {0}-Parameterüberladungen von '{1}' sind mit „Windows.Foundation.Metadata.DefaultOverloadAttribute“ versehen. Das Attribut kann nur auf eine Überladung der Methode angewendet werden.

CsWinRT1016

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

CsWinRT1021

Die Methode „{0}“ weist den Parameter „{1}“ auf. Hierbei handelt es sich um ein Array, das entweder ein System.Runtime.InteropServices.InAttribute oder ein System.Runtime.InteropServices.OutAttribute enthält. In der Windows-Runtime müssen Arrayparameter entweder über „ReadOnlyArray“ oder „WriteOnlyArray“ verfügen. Entfernen Sie diese Attribute, oder ersetzen Sie sie bei Bedarf durch das entsprechende Windows-Runtime-Attribut.

CsWinRT1022

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

CsWinRT1023

Die Methode „{0}“ weist den Parameter „{1}“ auf, bei dem es sich um ein Array handelt, das sowohl über „ReadOnlyArray“ als auch über „WriteOnlyArray“ verfügt. Die Inhalte von Arrayparametern müssen in der Windows-Runtime entweder lesbar oder schreibbar sein. Entfernen Sie eines der Attribute aus '{1}'.

CsWinRT1024

Die Methode „{0}“ weist den Ausgabeparameter „{1}“ auf, bei dem es sich zwar um ein Array handelt, das jedoch das Attribut „ReadOnlyArray“ besitzt. Die Inhalte von Ausgabearrays sind in der Windows-Runtime schreibbar. Entfernen Sie das Attribut aus '{1}'.

CsWinRT1025

Die Methode „{0}“ weist den Parameter „{1}“ auf, bei dem es sich um ein Array handelt. Die Inhalte von Array-Parametern müssen in der Windows-Runtime entweder lesbar oder schreibbar sein. Wenden Sie entweder „ReadOnlyArray“ oder „WriteOnlyArray“ auf „{1}“ an.

CsWinRT1026

Die Methode „{0}“ weist den Parameter „{1}“ auf, der kein Array ist und entweder über ein ReadOnlyArray-Attribut oder ein WriteOnlyArray-Attribut verfügt. Windows-Runtime unterstützt nicht das Markieren von Nichtarrayparametern mit „ReadOnlyArray“ oder „WriteOnlyArray“.

Namespacefehler und ungültige Namen für die Ausgabedatei

In der 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 Ihr Visual Studio-Projekt beispielsweise A.B heißt (d. h. die Komponente für Windows-Runtime ist A.B.WINMD), kann es die öffentlichen Klassen A.B.Class1 und A.B.C.Class2 enthalten, aber nicht A.Class3 oder D.Class4.

Hinweis

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

Für A.Class3 können Sie Class3 in einen anderen Namespace verschieben oder den Namen der Komponente für Windows-Runtime in A.WINMD ändern. Im vorherigen Beispiel kann A.Class3 nicht vom Code, der A.B.WINMD aufruft, gefunden werden.

Im Fall von D.Class4 kann kein Dateiname beides, D.Class4 und Klassen im A.B-Namespace, enthalten. Das Ändern des Namens der Komponente für Windows-Runtime ist daher keine Lösung. Sie können D.Class4 entweder in einen anderen Namespace verschieben oder in eine andere Komponente für Windows-Runtime einfügen.

Das Dateisystem kann nicht zwischen Groß- und Kleinbuchstaben unterscheiden. Namespaces mit unterschiedlicher Groß-/Kleinschreibung sind daher nicht zulässig (CsWinRT1002).

Fehlernummer

Meldungstext

CsWinRT1001

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 sich in einem Subnamespace des im Dateinamen enthaltenen Namespace befinden.

CsWinRT1002

Mehrere Namespaces mit dem Namen „{0}“. Namespacenamen können sich in der Windows-Runtime nicht nur hinsichtlich der Groß-/Kleinschreibung unterscheiden.

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

Die öffentliche Schnittstelle Ihrer Komponente darf nur Windows-Runtime-Typen verfügbar machen. .NET stellt jedoch Zuordnungen für eine Reihe häufig verwendeter Typen bereit, die sich in .NET und der Windows-Runtime geringfügig unterscheiden. Somit können .NET-Entwickler mit bekannten Typen arbeiten, anstatt sich erst mit neuen Typen vertraut machen zu müssen. Sie können diese zugeordneten .NET Framework-Typen in der öffentliche Schnittstelle der Komponente verwenden. Weitere Informationen finden Sie unter Deklarieren von Typen in Windows-Runtime-Komponenten, Übergeben von Windows-Runtime-Typen an verwalteten Code und .NET-Zuordnungen von Windows-Runtime-Typen.

Viele dieser Zuordnungen sind Schnittstellen. Zum Beispiel wird IList<T> der Windows-Runtime-Schnittstelle IVector<T> zugeordnet. Wenn Sie List<string> anstelle von IList<string> als Parametertyp verwenden, stellt C#/WinRT eine Liste von Alternativen zur Verfügung, die alle von List<T> implementierten zugeordneten Schnittstellen enthält. Bei Verwendung geschachtelter generischer Typen, wie List<Dictionary<int, string>> bietet C#/WinRT verschiedene Optionen für jede Schachtelungsebene an. Diese Listen können recht umfangreich sein.

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> am besten geeignet.

Fehlernummer

Meldungstext

CsWinRT1006

Der Member „{0}“ hat den Typ „“{1}“ in seiner Signatur. Der Typ „{1}“ ist kein gültiger Windows-Runtime-Typ. Der Typ (oder seine generischen Parameter) implementiert jedoch Schnittstellen, die gültige Windows-Runtime-Typen sind. Erwägen Sie, den Typ „{1}“ in der Membersignatur in einen der folgenden Typen aus „System.Collections.Generic“ zu ändern: {2}.

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

Hinweis

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

Fehlernummer

Meldungstext

CsWinRT1017

Die Methode „{0}“ weist in ihrer Signatur ein geschachteltes Array des Typs „{1}“ auf. Arrays dürfen in Windows-Runtime-Methodensignaturen nicht geschachtelt sein.

CsWinRT1018

Die Methode „{0}“ weist in ihrer Signatur ein mehrdimensionales Array des Typs „{1}“ auf. Arrays in Signaturen von Windows-Runtime-Methoden müssen eindimensional sein.

Strukturen, die Felder mit unzulässigen Typen enthalten

In der Windows-Runtime kann eine Struktur nur Felder enthalten, und nur Strukturen können Felder enthalten. Diese Felder müssen öffentlich sein. Zu den gültigen Feldtypen zählen Strukturen, Enumerationen und primitive Typen.

Fehlernummer

Meldungstext

CsWinRT1007

Die Struktur {0} enthält keine öffentlichen Felder. Windows-Runtime-Strukturen müssen mindestens ein öffentliches Feld enthalten.

CsWinRT1011

Die Struktur {0} enthält ein nicht öffentliches Feld. Für Windows-Runtime-Strukturen müssen alle Felder öffentlich sein.

CsWinRT1012

Die Struktur {0} enthält ein const-Feld. Konstanten können nur in Windows-Runtime-Enumerationen vorkommen.

CsWinRT1013

Die Struktur {0} weist ein Feld vom Typ „{1}“ auf. „{1}“ 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, Enum sein oder selbst eine Struktur darstellen.

Parametername im Konflikt mit generiertem Code

In der Windows-Runtime werden Rückgabewerte als Ausgabeparameter betrachtet, und die Namen der Parameter müssen eindeutig sein. Standardmäßig gibt C#/WinRT dem Rückgabewert den Namen __retval. Wenn Ihre Methode einen Parameter mit dem Namen „__retval" besitzt, erhalten Sie die Fehlermeldung CsWinRT1010. Um dies zu korrigieren, geben Sie Ihrem Parameter einen anderen Namen als „__retvalue“.

Fehlernummer

Meldungstext

CsWinRT1010

Der Parametername „{1}“ in der Methode „{0}“ ist mit dem Parameternamen des Rückgabewerts identisch, der im generierten C#/WinRT-Interop verwendet wird. Verwenden Sie einen anderen Parameternamen.

Verschiedenes

Weitere Einschränkungen in einer mit C#/WinRT erstellten Komponente sind unter anderem:

  • Überladene Operatoren können nicht für öffentliche Typen verfügbar gemacht werden.
  • Klassen und Schnittstellen können nicht generisch sein.
  • Klassen müssen versiegelt sein.
  • Parameter können nicht als Verweis übergeben werden, z. B. mithilfe des Schlüsselworts ref.
  • Eigenschaften müssen über eine öffentliche get-Methode verfügen.
  • Im Namespace Ihrer Komponente muss mindestens ein öffentlicher Typ (Klasse oder Schnittstelle) vorhanden sein.

Fehlernummer

Meldungstext

CsWinRT1014

„{0}“ ist eine Operatorüberladung. Verwaltete Typen können in der Windows-Runtime keine überladenen Operatoren verfügbar machen.

CsWinRT1004

Der Typ „{0}“ ist generisch. Windows-Runtime-Typen können nicht generisch sein.

CsWinRT1005

Das Exportieren unversiegelter Typen wird in CsWinRT nicht unterstützt. Markieren Sie den Typ „{0}“ als versiegelt.

CsWinRT1020

In der Methode „{0}“ ist der Parameter „{1}“ als „ref“ markiert. Verweisparameter sind in Windows-Runtime nicht zulässig.

CsWinRT1000

Die Eigenschaft „{0}“ besitzt keine öffentliche getter-Methode. Windows-Runtime unterstützt keine reinen setter-Eigenschaften.

CsWinRT1003

Windows-Runtime-Komponenten müssen mindestens einen öffentlichen Typ aufweisen.

In der Windows-Runtime kann eine Klasse nur über einen Konstruktor mit einer bestimmten Anzahl von Parametern verfügen. Sie können z. B. nicht einen Konstruktor haben, der einen einzelnen Parameter vom Typ string hat, und einen anderen Konstruktor mit einem einzelnen Parameter vom Typ int verwenden. Das Problem kann nur umgangen werden, indem für jeden Konstruktor eine andere Anzahl von Parametern verwendet wird.

Fehlernummer

Meldungstext

CsWinRT1009

Klassen können nicht über mehrere Konstruktoren derselben Stelligkeit in der Windows-Runtime verfügen. Die Klasse „{0}“ verfügt über mehrere Konstruktoren mit einer Stelligkeit von {1}.