visual-studio-2010 interop tlbimp

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



visual-studio-2010 (6)

En un proyecto de C #, agregamos una referencia a un objeto COM a través de la configuración de Agregar Referencias que apunta a un objeto COM, lo que resulta en que el IDE genere automáticamente el ensamblaje de interoperabilidad. Así que esto es bueno y bueno, pero estamos construyendo en base a .net 3.5 SP1 aka CLR 2.0, y los interops generados están usando el CLR 4.0 haciéndolos incompatibles. ¿Hay alguna manera de prevenir esto?

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

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


Encontré exactamente este problema. La solución que encontré fue usar la versión 3.5 de tlbimp desde el.

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 se puede adjuntar opcionalmente a un archivo de biblioteca de tipos al importar una biblioteca de tipos desde 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


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

  1. Vaya a C: / Archivos de programa (x86) / Microsoft SDKs / Windows / v7.0A / Bin y abra el archivo tlbimp.exe.config.
  2. Agregue las siguientes líneas al archivo en la sección de configuración:

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

  3. Guarde el archivo, luego ejecute el ejecutable tlbimp.exe como lo haría normalmente.


Para mí (Visual Studio 2013) era solo una cuestión de usar el ejecutable TlbImp correcto.

Encuentra el que estás usando por defecto:

where tlbimp

Que para mi era

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

En su lugar, utilice uno de una versión inferior, por ejemplo

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

que produjo un ensamblaje .Net 2 para mí, no es necesario editar el archivo de configuración. Puede usar CorFlags en el exe para determinar qué versión .Net utiliza. O simplemente puedes usar Corflags en tu salida.


Si está utilizando eventos de compilación, intente esto:

"$(SDK35ToolsPath)tlbimp" tlbimp arguments

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

Y si desea 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 comando de VS 2010, "donde tlbimp" mostrará tlbimp.exe en la carpeta de herramientas de NETFX 4.0 primero. Entonces necesitamos $ (SDK35ToolsPath) para 3.5 tlbimp.exe.


Solo corre

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

Para generar una biblioteca de interops .Net versión 2.0


Tuve el mismo problema exacto, pero incluso con v2.0 de tlbimp.exe, todavía obtengo un 4.0 dll, que no funcionará.
Terminé con una solución más simple, en caso de que alguien se tope con esto:
Registre la dll con regsvr32 (asegúrese de ejecutarlo como administrador o obtendrá un error) y luego, al agregar la referencia en el proyecto, encontrará su dll en la pestaña COM.
¡Trabajado como un encanto!

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