I nomi nell'assembly di interoperabilità hanno una maiuscola errata

Question

Ho un componente COM VC++ con una libreria di tipi. La libreria dei tipi di questo componente dichiara un'interfaccia e un 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; 
}; 

Al fine di consumare la componente da un'applicazione C# aggiungo un riferimento al progetto C# e un assembly di interoperabilità viene generato.

Nel Visualizzatore oggetti di Visual Studio 2003 Vedo che l'interoperabilità contiene:

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

E 'chiaro che che per qualche motivo il nome della classe e l'interfaccia si differenziano per capitalizzazione. Ciò non accade per altre 20 interfacce dichiarate nella stessa libreria di tipi - per loro ISomething corrisponde a Something e SomethingClass.

Ho esaminato i file .idl del progetto: l'identificatore Workflow non viene utilizzato da nessun'altra parte.

Qual è il motivo di questo strano comportamento e come può essere risolto?

Answer 1

Osservare attraverso il codice e vedere se c'è un parametro, la proprietà, o il nome del metodo che ha l'ortografia esatta e la capitalizzazione di "flusso di lavoro". Sarà quasi certamente un parametro per una funzione di interfaccia COM. Cambia il nome da paramWorkflow e il tuo problema dovrebbe andare via.

Perché succede? C'è un bug negli strumenti di libreria dei tipi in cui memorizzano internamente gli identificatori in modo non sensibile al maiuscolo/minuscolo. Quindi, se hai due nomi con diversa capatilizzazione, questi verranno memorizzati nello stesso slot. Questi nomi vengono quindi utilizzati direttamente al momento della generazione in modo che il diverso involucro venga emesso.

Il modo per aggirare questo problema è prevenire il conflitto creando nomi diversi.

Answer 2

Date un'occhiata al nuovo strumento tlbimp personalizzabile su CodePlex:

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

Answer 3

Sì, questo succede davvero. Avevamo una proprietà con un nome specifico e un parametro in un altro metodo che è stato modificato e quindi colliso. Stesso nome, involucro diverso-- wham. Per rendere le cose ancora più interessanti, abbiamo due obiettivi di costruzione, e qualcosa era abbastanza differente nell'ordine di costruzione che abbiamo ottenuto una maiuscola in una - che ha funzionato-- e l'altra nell'altra - che ha fallito. È davvero divertente quando entrambi i progetti controllano la stessa fonte e i file .sln, ecc.