在C＃项目中，我们通过添加引用设置指向一个COM对象来添加对COM对象的引用，这会导致IDE自动生成互操作程序集。所以这很好，但是我们正在基于.net 3.5 SP1（又名CLR 2.0）构建，生成的interop使用4.0 CLR，因此它们不兼容。有没有办法来防止这种情况？Visual Studio 2010，TlbImp在2.0项目中生成.net 4.0 interops
我假设另一个选项是配置我们的构建脚本尝试使用tlbimp.exe和/ references参数？指向mscorlib v2.0？
无论如何，我希望有一个标志某处允许这个。
我遇到了这个问题。我发现的解决方案是使用位于使用CLR 2的％ProgramFiles％\ Microsoft SDKs \ Windows \ v6.0A \ bin中的.Net Framework SDK（或Windows Platform SDK？）中的tlbimp 3.5版。
I也发现我需要这个信息从我导入的exe文件中获取正确的类型库，因为VS只使用第一个类型库：
“资源ID可以选择在导入从包含多个类型库的模块中键入库“。
TLBIMP MyModule.dll \ 1
从http://msdn.microsoft.com/en-us/library/tt0cf3sx%28VS.80%29.aspx
我有同样的确切问题，但即使tlbimp.exe是V2.0版，我仍然获得了4.0的dll，这是行不通的。
我最终得到了一个更简单的解决方案，以防有人遇到这个问题：
注册与regsvr32 DLL（确保你运行管理员，否则你会得到一个错误），然后当在项目中添加引用，你会在COM选项卡中找到你的dll。
工作就像一个魅力！
除非您想创建interop dll以将其与您的应用程序一起发货，那么您需要找出tlbimp.exe路径。
问题的解决方案是将tlbimp.exe配置为在2.0 .NET运行时版本下运行。
添加以下行文件中的配置部分：
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
保存文件，然后运行tlbimp.exe是可执行文件，你通常会。
如果您使用生成事件，试试这个：
"$(SDK35ToolsPath)tlbimp" tlbimp arguments
$（SDK35ToolsPath）指向C：\ Program Files文件（x86）的\微软的SDK \的Windows \ v7.0A \ BIN
如果您想引用4.0，则$（SDK40ToolsPath）是指向C：\ Program Files（x86）\ Microsoft SDK \ Windows \ v7.0A \ Bin \ NETFX 4.0工具的宏。
在VS 2010的命令行 “其中TLBIMP” 在NETFX 4.0工具将显示tlbimp.exe是第一个文件夹中。因此，我们需要$（SDK35ToolsPath）3.5 tlbimp.exe是。
只要运行
C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\TlbImp.exe
要生成一个互操作性展示库.NET版本2.0
对我（的Visual Studio 2013），它只是一个使用权TLBIMP可执行文件的问题。
找出你默认情况下使用一个：这对我来说是
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\TlbImp.exe
而是使用一个从低版本
where tlbimp
，例如
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\tlbimp
这就产生了净2组件对我来说，没有必要编辑配置文件。您可以在exe上使用CorFlags来确定它使用的.Net版本。或者你可以在你的输出中使用Corflags。
救了我一天！谢谢！ – EdsonF 2013-09-17 14:51:27
这不适用于Windows 10版本的SDK/tlbimp，fwiw。它给出了关于无效并排配置的错误。否则，很好的答案！ – 2017-02-05 01:28:22