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.
Numéro de l'erreur |
Texte du message |
---|---|
WME1084 |
Le type '{0}' implémente l'interface asynchrone Windows Runtime '{1}'. Les types Windows Runtime ne peuvent pas implémenter d'interfaces asynchrones. Utilisez la classe System.Runtime.InteropServices.WindowsRuntime.AsyncInfoFactory pour générer les opérations asynchrones lors de l'exportation vers le Windows Runtime. |
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).
Numéro de l'erreur |
Texte du message |
---|---|
WME1009 |
Aucune référence n'a été faite à mscorlib.dll. Une référence à ce fichier de métadonnées est requise pour exporter correctement. |
WME1090 |
Impossible de déterminer le principal assembly de référence. Assurez-vous que mscorlib.dll et System.Runtime.dll sont référencés à l'aide du commutateur /reference. |
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.
Notes
Dans le message d'erreur, l'opérateur est identifié par son nom de métadonnées, tel qu'op_Addition, op_Multiply, op_ExclusiveOr, op_Implicit (conversion implicite), et ainsi de suite.
Numéro de l'erreur |
Texte du message |
---|---|
WME1087 |
« {0} » est une surcharge d'opérateur. Les types managés ne peuvent pas exposer de surcharges d'opérateur dans Windows Runtime. |
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.
Numéro de l'erreur |
Texte du message |
---|---|
WME1099 |
Le type « {0} » a plusieurs constructeurs avec « {1} » arguments. Les types Windows Runtime ne peuvent pas avoir plusieurs constructeurs avec le même nombre d'arguments. |
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.
Numéro de l'erreur |
Texte du message |
---|---|
WME1059 |
Plusieurs surcharges de paramètre {0} de « {1}.{2} » sont décorés de Windows.Foundation.Metadata.DefaultOverloadAttribute. |
WME1085 |
Les surcharges de paramètre {0} de {1}.{2} doivent avoir une seule méthode spécifiée en tant que surcharge par défaut en la décorant avec Windows.Foundation.Metadata.DefaultOverloadAttribute. |
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).
Notes
Ces restrictions s'appliquent uniquement aux types publics, pas aux types privés utilisés dans votre implémentation.
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).
Avertissement
Si vous appelez Winmdexp.exe directement et n'utilisez pas l'option /out pour spécifier un nom pour votre composant Windows Runtime, Winmdexp.exe essaie de générer un nom qui inclut tous les espaces de noms dans le composant. Le fait de renommer les espaces de noms peut modifier le nom de votre composant.
Numéro de l'erreur |
Texte du message |
---|---|
WME0006 |
« {0} » n'est pas un nom de fichier winmd valide pour cet assembly. Tous les types d'un fichier de métadonnées Windows doivent exister dans un sous espace de noms de l'espace de noms impliqué par le nom de fichier. Les types qui n'existent pas dans un tel sous espace de noms ne peuvent pas être localisés au moment de l'exécution. Dans cet assembly, le plus petit espace de noms commun pouvant faire office de nom de fichier est « {1} ». |
WME1042 |
Le module d'entrée doit contenir au moins un type public qui se trouve dans un espace de noms. |
WME1043 |
Le module d'entrée doit contenir au moins un type public qui se trouve dans un espace de noms. Les seuls types présents dans des espaces de noms sont privés. |
WME1044 |
Un type public a un espace de noms (« {1} ») qui ne partage aucun préfixe commun avec d'autres espaces de noms (« {0} »). Tous les types d'un fichier de métadonnées Windows doivent exister dans un sous espace de noms de l'espace de noms impliqué par le nom de fichier. |
WME1067 |
Les noms d'espaces de noms ne peuvent pas différer uniquement par la casse : « {0} », « {1} ». |
WME1068 |
Le type « {0} » ne peut pas avoir le même nom que l'espace de noms « {1} ». |
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>.
Important
JavaScript utilise l'interface qui apparaît en premier dans la liste des interfaces implémentées par un type managé. Par exemple, si vous retournez Dictionary<int, string> au code JavaScript, il apparaît comme IDictionary<int, string> quelle que soit l'interface que vous spécifiez comme type de retour. Cela signifie que si la première interface n'inclut pas un membre qui apparaît sur les interfaces ultérieures, ce membre n'est pas visible dans JavaScript.
Avertissement
Évitez d'utiliser les interfaces non génériques IList et IEnumerable si votre composant est utilisé par JavaScript. Ces interfaces correspondent à IBindableVector et IBindableIterator respectivement. Elles prennent en charge la liaison pour les contrôles XAML, et sont invisibles dans JavaScript. JavaScript émet l'erreur d'exécution « La fonction « X » a une signature non valide et ne peut pas être appelée ».
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.
Numéro de l'erreur |
Texte du message |
---|---|
WME1060 |
La structure « {0} » possède le champ « {1} » de type « {2} ». « {2} » n'est pas un type de champ Windows Runtime valide. Les champs de la structure Windows Runtime doivent uniquement avoir la valeur UInt8, Int16, UInt16, Int32, UInt32, Int64, UInt64, Single, Double, Boolean, String, Enum, ou bien correspondre à une structure. |
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.
Notes
Cette restriction ne s'applique pas aux tableaux utilisés en interne dans votre implémentation.
Numéro de l'erreur |
Texte du message |
---|---|
WME1034 |
La méthode « {0} » possède un tableau de type « {1} » avec une limite inférieure non égale à zéro dans sa signature. Les tableaux dans les signatures de méthode Windows Runtime doivent avoir une limite inférieure de zéro. |
WME1035 |
La méthode « {0} » possède un tableau multidimensionnel de type « {1} » dans sa signature. Les tableaux dans les signatures de méthode Windows Runtime doivent être unidimensionnels. |
WME1036 |
La méthode « {0} » possède un tableau imbriqué de type « {1} » dans sa signature. Les tableaux dans les signatures de méthode Windows Runtime ne peuvent pas être imbriqué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.
Numéro de l'erreur |
Texte du message |
---|---|
WME1101 |
La méthode « {0} » a un paramètre « {1} » qui est un tableau, et qui a à la fois {2} et {3}. Dans Windows Runtime, le contenu des paramètres de tableau doit être accessible en lecture ou en écriture. Supprimez l'un des attributs de « {1} ». |
WME1102 |
La méthode « {0} » a un paramètre de sortie « {1} » qui est un tableau, mais qui a {2}. Dans Windows Runtime, le contenu des tableaux de sortie est accessible en écriture. Supprimez l'attribut de « {1} ». |
WME1103 |
La méthode « {0} » possède le paramètre « {1} » qui est un tableau possédant un attribut System.Runtime.InteropServices.InAttribute ou System.Runtime.InteropServices.OutAttribute. Dans le Windows Runtime, les paramètres de tableau doivent posséder soit « {2} », soit « {3} ». Supprimez ces attributs ou remplacez-les par l'attribut Windows Runtime approprié si nécessaire. |
WME1104 |
La méthode « {0} » possède le paramètre « {1} » qui n'est pas un tableau et qui est associé à un « {2} » ou un « {3} ». Windows Runtime ne prend pas en charge le marquage des paramètres autres que des tableaux associés à « {2} » ou « {3} ». |
WME1105 |
La méthode « {0} » possède le paramètre « {1} » possédant l'attribut System.Runtime.InteropServices.InAttribute ou System.Runtime.InteropServices.OutAttribute. Le Windows Runtime ne prend pas en charge le marquage des paramètres par System.Runtime.InteropServices.InAttribute ou System.Runtime.InteropServices.OutAttribute. Supprimez System.Runtime.InteropServices.InAttribute, puis remplacez System.Runtime.InteropServices.OutAttribute par le modificateur 'out'. La méthode « {0} » possède le paramètre « {1} » possédant l'attribut System.Runtime.InteropServices.InAttribute ou System.Runtime.InteropServices.OutAttribute. Le Windows Runtime ne prend en charge que le marquage des paramètres ByRef par System.Runtime.InteropServices.OutAttribute, et ne prend en charge aucune autre utilisation de ces attributs. |
WME1106 |
La méthode « {0} » a un paramètre « {1} » qui est un tableau. Dans Windows Runtime, le contenu des paramètres de tableau doit être accessible en lecture ou en écriture. Indiquez {2} ou {3} pour « {1} ». |
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