Les noms dans l'assembly interop ont une mauvaise capitalisation

Question

J'ai un composant COM VC++ avec une bibliothèque de types. La bibliothèque de type de ce composant déclare une interface et une co-classe:

[ 
    object, 
    uuid(ActualUuidHere), 
    dual, 
    nonextensible, 
    oleautomation, 
    hidden, 
    helpstring(ActualHelpStringHere) 
] 
interface IWorkflow : IDispatch 
{ 
    //irrelevant properties here  
} 

[ 
    uuid(ActualClassIdHere), 
    noncreatable 
] 
coclass Workflow { 
    [default] interface IWorkflow; 
}; 

Pour consommer le composant à partir d'une application C# ajouter une référence au projet C# et un ensemble interop est généré.

Dans l'Explorateur d'objets de Visual Studio 2003, je vois que le Interop contient:

public abstract interface IWorkflow; 
public abstract interface workflow : IWorkflow; 
public class workflowClass : System.Object; 

Il est clair que cela pour une raison quelconque le nom de la classe et l'interface diffèrent en majuscules. Cela ne se produit pas pour les autres interfaces 20+ déclarées dans la même bibliothèque de type - pour eux ISomething correspond à Something et SomethingClass.

J'ai parcouru les fichiers .idl du projet - l'identifiant Workflow n'est utilisé nulle part ailleurs.

Quelle est la raison de ce comportement étrange et comment peut-on le contourner?

Answer 1

Regardez dans votre code et voir s'il y a un paramètre, la propriété ou le nom de la méthode qui a l'orthographe exacte et la capitalisation des "workflow". Ce sera presque certainement un paramètre pour une fonction d'interface COM. Changez le nom pour être paramWorkflow et votre problème devrait disparaître.

Pourquoi cela se produit-il? Il existe un bogue dans les outils de la bibliothèque de types où ils stockent les identifiants de manière insensible à la casse en interne. Donc, si vous avez deux noms avec une capatilisation différente, ils seront stockés dans le même emplacement. Ces noms sont ensuite directement utilisés au moment de la génération, de sorte que les différents boîtiers seront émis.

La façon de contourner ce problème est d'empêcher le conflit en créant des noms différents.

Answer 2

Jetez un oeil à ce nouvel outil de tlbimp personnalisable sur CodePlex:

http://blogs.msdn.com/clrteam/archive/2009/03/19/new-tlbimp-release-on-codeplex-full-customization-of-interop-assemblies.aspx

Answer 3

Yup-- cela arrive vraiment. Nous avions une propriété avec un nom donné, et un paramètre à une autre méthode qui a été modifié et est ensuite entré en collision. Même nom, différente casing-- wham. Pour rendre les choses encore plus intéressantes, nous avons deux cibles de construction, et quelque chose de juuuuuust assez différent au sujet de l'ordre de construction que nous avons eu une capitalisation en un - qui a fonctionné - et l'autre dans l'autre - qui a échoué. Vraiment amusant quand les deux projets vérifient la même source et les mêmes fichiers .sln, etc.