Diagnostic des conditions d'erreur du composant Windows Runtime

Cet article fournit des informations supplémentaires sur les restrictions applicables aux composants Windows Runtime écrits en code managé. Il développe les informations fournies dans les messages d'erreur de Winmdexp.exe (outil d'exportation de métadonnées Windows Runtime) et complète les informations sur les restrictions fournies dans Création de composants Windows Runtime en C# et Visual Basic.

Cet article n'aborde pas toutes les erreurs. Les erreurs traitées ici sont groupées par catégorie générale, chaque catégorie comprend un tableau des messages d'erreur associés. Recherchez le texte du message (en omettant les valeurs spécifiques pour les espaces réservés) ou le numéro du message. Si vous ne trouvez pas les informations dont vous avez besoin ici, merci de nous aider à améliorer la documentation à l'aide du bouton de commentaires à la fin de cet article. Inclure le message d'erreur. Vous pouvez aussi entrer un bogue dans le site Web Microsoft Connect.

Cet article contient les sections suivantes :

• Lorsque vous implémentez un modèle asynchrone, le message d'erreur fournit un type incorrect

• Références manquantes dans mscorlib.dll et/ou System.Runtime.dll

• Surcharge d'opérateur non autorisée

• Constructeurs d'une classe ayant le même nombre de paramètres

• Spécification obligatoire d'une valeur par défaut pour les surcharges ayant le même nombre de paramètres

• Erreurs d'espace de noms et noms valides pour le fichier de sortie

• Exportation des types qui ne sont pas des types Windows Runtime

• Structures contenant des champs de types rejetés

• Restrictions sur les tableaux dans les signatures de membre

• Les paramètres de tableau doivent spécifier si le contenu du tableau est accessible en lecture ou en écriture

• Membre avec un paramètre nommé « valeur »

Type incorrect fourni par le message d'erreur pour l'implémentation de l'interface asynchrone

Les composants Windows Runtime managés ne peuvent pas implémenter les interfaces Windows Runtime qui représentent des actions ou des opérations asynchrones (IAsyncAction, IAsyncActionWithProgress<TProgress>, IAsyncOperation<TResult> ou IAsyncOperationWithProgress<TResult, TProgress>). Au lieu de cela, le .NET Framework fournit la classe AsyncInfo pour générer des opérations asynchrones dans les composants Windows Runtime. Le message d'erreur affiché par Winmdexp.exe lorsque vous essayez d'implémenter une interface asynchrone de manière incorrecte fait référence à cette classe par son ancien nom, AsyncInfoFactory. Le .NET Framework n'inclut plus la classe AsyncInfoFactory.

Références manquantes dans mscorlib.dll ou System.Runtime.dll

Ce problème se produit uniquement lorsque vous utilisez Winmdexp.exe à partir de la ligne de commande. Nous vous recommandons d'utiliser l'option /reference pour inclure des références à la fois vers mscorlib.dll et vers System.Runtime.dll à partir des assemblys de référence principale du .NET Framework, qui sont définis dans « %ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5" ("%ProgramFiles % \… » sur un ordinateur 32 bits).

Surcharge d'opérateur non autorisée

Dans un composant Windows Runtime écrit en code managé, vous ne pouvez pas exposer les opérateurs surchargés sur les types publics.

Constructeurs d'une classe ayant le même nombre de paramètres

Dans Windows Runtime, une classe peut uniquement avoir un constructeur ayant un nombre donné de paramètres ; par exemple, vous ne pouvez pas avoir de constructeur ayant un seul paramètre de type String et un autre ayant un seul paramètre de type int (Integer en Visual Basic). La seule solution consiste à utiliser un nombre différent de paramètres pour chaque constructeur.

Spécification obligatoire d'une valeur par défaut pour les surcharges ayant le même nombre de paramètres

Dans Windows Runtime, les méthodes surchargées peuvent avoir le même nombre de paramètres uniquement si une surcharge est spécifiée en tant que celle par défaut. Consultez « Méthodes surchargées » dans Création de composants Windows Runtime en C# et Visual Basic.

Erreurs d'espace de noms et noms valides pour le fichier de sortie

Dans Windows Runtime, tous les types publics dans un fichier de métadonnées Windows (.winmd) doivent se trouver dans un espace de noms qui partage le nom du fichier .winmd, ou dans des sous-espaces de noms du nom de fichier. Par exemple, si votre projet Visual Studio 2012 est nommé A.B (autrement dit, votre composant Windows Runtime est A.B.winmd), il peut contenir des classes publiques A.B.Class1 et A.B.C.Class2, mais pas A.Class3 (WME0006) ou D.Class4 (WME1044).

Dans le cas de A.Class3, vous pouvez déplacer Class3 dans un autre espace de noms ou remplacer le nom du composant Windows Runtime par A.winmd. Bien que WME0006 soit un avertissement, vous devez le traiter comme une erreur. Dans l'exemple précédent, le code qui appelle A.B.winmd ne pourra pas localiser A.Class3.

Dans le cas de D.Class4, aucun nom de fichier ne peut contenir à la fois D.Class4 et des classes dans l'espace de noms A.B, la modification du nom du composant Windows Runtime n'est donc pas possible. Vous pouvez déplacer D.Class4 vers un autre espace de noms, ou le placer dans un autre composant Windows Runtime.

Le système de fichiers ne peut pas faire la distinction entre majuscules et minuscules, les espaces de noms dont la casse diffère ne sont pas autorisés (WME1067).

Votre composant doit contenir au moins un type public sealed (Public NotInheritable en Visual Basic). Sinon, vous obtiendrez WME1042 ou WME1043, selon que votre composant contient ou non des types privés.

Un type dans un composant Windows Runtime ne peut pas avoir un nom identique à un espace de noms (WME1068).

Exportation des types qui ne sont pas types Windows Runtime valides

L'interface publique de votre composant doit exposer uniquement les types Windows Runtime. Toutefois, .NET Framework fournit des mappages pour plusieurs types couramment utilisés qui sont légèrement différents dans .NET Framework et Windows Runtime. Cela permet au développeur .NET Framework de travailler avec des types familiers au lieu d'en apprendre de nouveaux. Vous pouvez utiliser ces types .NET Framework mappés dans l'interface publique de votre composant. Consultez « Déclaration des types dans des composants Windows Runtime » et « Passage des types Windows Runtime au code managé » dans Création de composants Windows Runtime en C# et Visual Basic et Mappages .NET Framework des types Windows Runtime.

Plusieurs de ces mappages sont des interfaces. Par exemple, IList<T> mappe vers l'interface Windows Runtime IVector<T>. Si vous utilisez List<string> (List(Of String) en Visual Basic) au lieu de IList<string> comme type de paramètre, Winmdexp.exe fournit une liste d'alternatives qui inclut toutes les interfaces mappées implémentées par List<T>. Si vous utilisez des types génériques imbriqués, tels que List<Dictionary<int, string>> (List(Of Dictionary(Of Integer, String)) en Visual Basic), Winmdexp.exe offre des choix pour chaque niveau d'imbrication. Ces listes peuvent considérablement s'allonger.

En général, le meilleur choix est l'interface qui est la plus proche du type. Par exemple, pour Dictionary<int, string>, le meilleur choix est sans doute IDictionary<int, string>.

Numéro de l'erreur	Texte du message
WME1033	La méthode « {0} » a un paramètre « {1} » type « {2} ». « {2} » n'est pas un type de paramètre Windows Runtime valide.
WME1038	La méthode « {0} » a un paramètre de type « {1} » dans sa signature. Bien que ce type ne soit pas un type Windows Runtime valide, il implémente des interfaces qui sont des types Windows Runtime valides. Modifiez la signature de la méthode pour utiliser l'un des types suivants à la place : « {2} ».
WME1039	La méthode « {0} » a un paramètre de type « {1} » dans sa signature. Bien que ce type générique ne soit pas un type Windows Runtime valide, le type ou ses paramètres génériques implémente les interfaces étant des types Windows Runtime valides. {2} Remarque Pour {2}, Winmdexp.exe ajoute une liste d'alternatives, par exemple « Remplacer le type « System.Collections.Generic.List<T> » dans la signature de méthode par l'un des types suivants : « System.Collections.Generic.IList<T>, System.Collections.Generic.IReadOnlyList<T>, System.Collections.Generic.IEnumerable<T> ».
WME1040	La méthode « {0} » a un paramètre de type « {1} » dans sa signature. Au lieu d'utiliser un type de tâche managé, utilisez un type Windows.Foundation.IAsyncAction, Windows.Foundation.IAsyncOperation, ou bien l'une des autres interfaces asynchrones Windows Runtime. Le modèle d'awaiter .NET standard s'applique également à ces interfaces. Pour plus d'informations sur la conversion d'objets de tâches managées en interfaces asynchrones Windows Runtime, consultez System.Runtime.InteropServices.WindowsRuntime.AsyncInfo.

Structures contenant des champs de types rejetés

Dans Windows Runtime, une structure peut contenir uniquement des champs, et seules les structures peuvent contenir des champs. Ces champs doivent être publics. Les types de champ valides incluent des énumérations, des structures et des types primitifs.

Restrictions sur les tableaux dans les signatures de membre

Dans Windows Runtime, les tableaux dans les signatures de membre doivent être unidimensionnelles avec une limite inférieure de zéro (0). Les types de tableaux imbriqués tels que myArray[][] (myArray()() en Visual Basic) ne sont pas autorisés.

Les paramètres de tableau doivent spécifier si le contenu du tableau est accessible en lecture ou en écriture

Dans Windows Runtime, les paramètres doivent être en lecture seule ou en écriture seule. Les paramètres ne peuvent pas être marqués ref (ByRef sans l'attribut OutAttribute en Visual Basic). Cela s'applique au contenu des tableaux, les paramètres de tableau doivent donc indiquer si le contenu du tableau est en lecture seule ou en écriture seule. La direction est claire des paramètres out (paramètre ByRef avec l'attribut OutAttribute en Visual Basic), mais les paramètres de tableau passés par la valeur (ByVal en Visual Basic) doivent être marqués. Consultez Transmission de tableaux à un composant Windows Runtime.

Membre avec un paramètre nommé « valeur »

Dans Windows Runtime, les valeurs de retour sont considérées comme des paramètres de sortie, et les noms de ces paramètres doivent être uniques. Par défaut, Winmdexp.exe donne à la valeur de retour le nom « value ». Si votre méthode possède un paramètre nommé « valeur », l'erreur WME1092 est générée. Il existe deux manières de corriger cette situation :

• Donnez à votre paramètre un nom différent de « value » (dans les accesseurs de propriété, un nom différent de « returnValue »).

• Utilisez l'attribut ReturnValueNameAttribute pour modifier le nom de la valeur de retour, comme indiqué ci-après :

  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
  

  Notes

  Si vous modifiez le nom de la valeur de retour, et que ce nouveau nom est en conflit avec le nom d'un autre paramètre, vous obtenez l'erreur WME1091.

Le code JavaScript peut accéder aux paramètres de sortie d'une méthode par nom, notamment la valeur de retour. Pour obtenir un exemple, consultez l'attribut ReturnValueNameAttribute.

Numéro de l'erreur	Texte du message
WME1091	La méthode « {0} » est la valeur de retour « {1} » qui est identique à un nom de paramètre. Les paramètres de méthode Windows Runtime et la valeur de retour doivent avoir des noms uniques.
WME1092	La méthode « {0} » a un paramètre nommé « {1} » qui est identique au nom par défaut de la valeur de retour. Définissez un autre nom pour le paramètre ou utilisez System.Runtime.InteropServices.WindowsRuntime.ReturnValueNameAttribute pour spécifier explicitement le nom de la valeur de retour. Remarque Le nom par défaut est « returnValue » pour les accesseurs de propriété et « valeur » pour toutes les autres méthodes.

Voir aussi

Référence

Winmdexp.exe (outil d'exportation de métadonnées Windows Runtime)

Concepts

Création de composants Windows Runtime en C# et Visual Basic