Visual Studio 2010, TlbImp genera interpolazioni .net 4.0 in progetti 2.0

Question

In un progetto C# aggiungiamo un riferimento a un oggetto COM tramite l'impostazione Aggiungi riferimenti che punta a un oggetto COM che genera l'IDE che genera automaticamente l'assembly di interoperabilità. Quindi questo va bene e bene, ma stiamo costruendo sulla base di .net 3.5 SP1 aka CLR 2.0, e gli interpossi generati stanno usando il CLR 4.0 rendendoli incompatibili. C'è un modo per impedirlo?

Suppongo che l'altra opzione sia configurare il nostro script di build per provare a utilizzare tlbimp.exe con il parametro/references? puntare a mscorlib v2.0?

In ogni caso, spero che ci sia una bandiera da qualche parte per consentire questo.

Answer 1

Ho riscontrato esattamente questo problema. La soluzione che ho trovato era usare la versione 3.5 di tlbimp da .Net Framework SDK (o Windows Platform SDK?) Che si trova in% ProgramFiles% \ Microsoft SDK \ Windows \ v6.0A \ bin che utilizza CLR 2.

I Ho anche trovato che avevo bisogno di queste informazioni per ottenere la corretta libreria di tipi dal file exe che stavo importando, poiché VS userebbe solo la prima libreria di tipi:

"Un ID risorsa può essere aggiunto a un file di libreria dei tipi quando si importa un digita libreria da un modulo contenente più librerie di tipi. "

tlbimp MyModule.dll \ 1

da http://msdn.microsoft.com/en-us/library/tt0cf3sx%28VS.80%29.aspx

Answer 2

Ho avuto lo stesso problema esatto, ma anche con v2.0 di Tlbimp.exe, ho ancora una dll 4.0, che non funziona .
Ho trovato una soluzione più semplice, nel caso qualcuno si imbattesse in questo:
Registra la dll con regsvr32 (assicurati di eseguirlo come amministratore o riceverai un errore) quindi quando aggiungi il riferimento nel progetto, tu troverai la tua DLL nella scheda COM.
Ha funzionato come un fascino!

A meno che non si desideri creare la DLL di interoperabilità per spedirla con l'applicazione, è necessario calcolare la rotta tlbimp.exe.

Answer 3

La soluzione al problema è configurare tlbimp.exe per l'esecuzione con la versione di runtime .NET 2.0.

1. Passare a C: \ Programmi (x86) \ Microsoft SDK \ Windows \ v7.0A \ Bin e aprire il file tlbimp.exe.config.

2. Aggiungere le seguenti righe al file nella sezione di configurazione:

   <startup> 
       <supportedRuntime version="v2.0.50727"/> 
   </startup> 
   

3. Salvare il file, quindi eseguire il file eseguibile Tlbimp.exe come si farebbe normalmente.

Answer 4

Se si utilizza Eventi di generazione, provate questo:

"$(SDK35ToolsPath)tlbimp" tlbimp arguments 

$ (SDK35ToolsPath) indica C: \ Program Files (x86) \ Microsoft SDK \ Windows \ v7.0A \ Bin

E se si desidera fare riferimento a 4.0, $ (SDK40ToolsPath) è la macro che punta a Strumenti C: \ Programmi (x86) \ Microsoft SDK \ Windows \ v7.0A \ Bin \ NETFX 4.0.

Nella riga di comando di VS 2010, "dove tlbimp" mostrerà tlbimp.exe nella cartella Strumenti di NETFX 4.0. Quindi abbiamo bisogno di $ (SDK35ToolsPath) per 3.5 tlbimp.exe.

Answer 5

Basta eseguire

C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\TlbImp.exe 

Per generare una libreria Interops Net versione 2.0

Answer 6

Per me (Visual Studio 2013) era solo una questione di usare il diritto eseguibile TlbImp.

scoprire quello che si sta utilizzando per impostazione predefinita:

where tlbimp

che per me era

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\TlbImp.exe

invece usare uno da una versione più bassa, ad esempio

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\tlbimp

che ha prodotto un assembly .Net 2 per me, non è necessario modificare il file di configurazione. È possibile utilizzare CorFlags sull'exe per determinare quale versione .Net utilizza. O potresti semplicemente usare Corflags sul tuo output.