Visual Studio 2010, TlbImp generates .net 4.0 interops in 2.0 projects

Question

In a C# project we add a reference to a COM object via the Add References setup pointing to a COM object which results in the IDE auto-generating the interop assembly. So this is fine and good, but we are building based on .net 3.5 SP1 aka CLR 2.0, and the generated interops are using the 4.0 CLR making them incompatible. Is there a way to prevent this?

I assume the other option is configure our build script to try using tlbimp.exe with the /references parameter? to point to mscorlib v2.0?

Anyhow, I'm hoping there's a flag somewhere to allow this.

Retral

Answer 1

I encountered exactly this issue. The solution I found was to use version 3.5 of tlbimp from the .Net Framework SDK (or Windows Platform SDK?) located in %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\bin that used CLR 2.

I also found I needed this info to get the correct type library from the exe file i was importing, as VS would use only the first type library:

"A resource ID can optionally be appended to a type library file when importing a type library from a module containing multiple type libraries."

tlbimp MyModule.dll\1

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

Batavia

Answer 2

The solution to the problem is to configure tlbimp.exe to run under the 2.0 .NET runtime version.

1. Go to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin and open the tlbimp.exe.config file.

2. Add the following lines to the file in the configuration section:

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

3. Save the file, then run the tlbimp.exe executable as you would normally.

Ferdinand

This doesn't work w/ the Windows 10 version of the SDK/tlbimp, fwiw. It gives errors about invalid side-by-side configuration. Otherwise, nice answer! – Succory

Answer 3

If you are using Build Events, try this:

"$(SDK35ToolsPath)tlbimp" tlbimp arguments

$(SDK35ToolsPath) points to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin

And if you want to reference 4.0, $(SDK40ToolsPath) is the macro which points to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools.

In VS 2010 command line, "where tlbimp" will show tlbimp.exe in NETFX 4.0 Tools folder first. So we need $(SDK35ToolsPath) for 3.5 tlbimp.exe.

Tildatilde

Answer 4

I had the same exact problem, but even with v2.0 of tlbimp.exe, I still get a 4.0 dll, which won't work.
I ended up with a simpler solution, in case someone runs into this:
Register the dll with regsvr32 (make sure you run that as admin or you'll get an error) then when adding the reference in the project, you'll find your dll in the COM tab.
Worked like a charm!

Unless you want to create the interop dll to ship it with your application, then you'll need to figure out the tlbimp.exe route.

Coetaneous

Answer 5

For me (Visual Studio 2013) it was just a matter of using the right TlbImp executable.

Find out the one you're using by default:

where tlbimp

Which for me was

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

Instead use one from a lower version, for example

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

which produced a .Net 2 assembly for me, no need to edit the config file. You can use CorFlags on the exe to determine what .Net version it uses. Or you could just use Corflags on your output.

Nativeborn

Answer 6

Just run

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

To generate an interops library .Net version 2.0

Disposed