Visual Studio 2010, TlbImp genera interoperabilidades .net 4.0 en proyectos 2.0

Question

En un proyecto C# agregamos una referencia a un objeto COM a través de la configuración Agregar referencias apuntando a un objeto COM que resulta en el IDE autogenerando el ensamblado de interoperabilidad. Así que esto está bien y está bien, pero estamos construyendo en base a .net 3.5 SP1 aka CLR 2.0, y las interoperabilidades generadas están usando el CLR 4.0, lo que las hace incompatibles. ¿Hay alguna forma de prevenir esto?

Supongo que la otra opción es configurar nuestro script de compilación para intentar usar tlbimp.exe con el parámetro/references? apuntar a mscorlib v2.0?

De todos modos, espero que haya una bandera en algún lugar para permitir esto.

Answer 1

Encontré exactamente este problema. La solución que encontré fue utilizar la versión 3.5 de tlbimp del .Net Framework SDK (o Windows Platform SDK?) Ubicado en% ProgramFiles% \ Microsoft SDKs \ Windows \ v6.0A \ bin que usó CLR 2.

I También encontré que necesitaba esta información para obtener la biblioteca de tipos correcta del archivo exe que estaba importando, ya que VS solo usaría la primera biblioteca de tipos:

"Un ID de recurso puede anexarse ​​opcionalmente a un archivo de biblioteca de tipos al importar un escriba la biblioteca de un módulo que contiene bibliotecas de tipos múltiples ".

tlbimp MyModule.dll \ 1

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

Answer 2

que tenía exactamente el mismo problema, pero incluso con v2.0 de tlbimp.exe, sigo teniendo una DLL 4.0, que no va a funcionar .
Terminé con una solución más simple, en caso de que alguien se encuentre con esto:
Registre el dll con regsvr32 (asegúrese de ejecutarlo como administrador o obtendrá un error) luego al agregar la referencia en el proyecto, encontraremos tu dll en la pestaña COM.
¡Funcionó como un encanto!

A menos que desee crear el dll de interoperabilidad para enviarlo con su aplicación, deberá averiguar la ruta de tlbimp.exe.

Answer 3

La solución al problema es configurar tlbimp.exe para que se ejecute bajo la versión 2.0 .NET runtime.

1. Ir a C: \ Archivos de programa (x86) \ Microsoft SDKs \ Windows \ v7.0A \ Bin y abrir el archivo tlbimp.exe.config.

2. añadir las siguientes líneas al archivo en la sección de configuración:

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

3. Guardar el archivo, a continuación, ejecutar el ejecutable tlbimp.exe como lo haría normalmente.

Answer 4

Si está utilizando Eventos de generación, intenta esto:

"$(SDK35ToolsPath)tlbimp" tlbimp arguments 

$ (SDK35ToolsPath) apunta a C: \ Archivos de programa (x86) \ Microsoft SDKs \ Windows \ v7.0A \ bin

Y si quiere hacer referencia a 4.0, $ (SDK40ToolsPath) es la macro que apunta a C: \ Archivos de programa (x86) \ Microsoft SDKs \ Windows \ v7.0A \ Bin \ NETFX 4.0 Tools.

En la línea de comandos de VS 2010, "donde tlbimp" mostrará primero tlbimp.exe en la carpeta Herramientas de NETFX 4.0. Entonces, necesitamos $ (SDK35ToolsPath) para 3.5 tlbimp.exe.

Answer 5

Sólo tiene que ejecutar

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

Para generar una biblioteca Interops .Net versión 2.0

Answer 6

Para mí (Visual Studio 2013) que era sólo una cuestión de usar el derecho ejecutable TlbImp.

Estudia el que usted está usando de forma predeterminada:

where tlbimp

que para mí era

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

En lugar de utilizar una versión inferior, por ejemplo

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

que produjo un ensamblado .Net 2 para mí, sin necesidad de editar el archivo de configuración. Puede usar CorFlags en el exe para determinar qué versión de .Net usa. O simplemente podría usar Corflags en su salida.