在 C# 项目中，我们通过指向 COM 对象的添加引用设置添加对 COM 对象的引用，这会导致 IDE 自动生成互操作程序集。所以这很好，但我们是基于 .net 3.5 SP1 aka CLR 2.0 构建的，并且生成的互操作使用 4.0 CLR，这使得它们不兼容。有没有办法防止这种情况？
我假设另一个选项是配置我们的构建脚本以尝试使用带有 /references 参数的 tlbimp.exe？指向mscorlib v2.0？
无论如何，我希望某处有一个标志允许这样做。
【问题讨论】：
标签： visual-studio-2010 interop tlbimp
我正好遇到了这个问题。我找到的解决方案是使用 .Net Framework SDK（或 Windows 平台 SDK？）中的 tlbimp 3.5 版，它位于使用 CLR 2 的 %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\bin 中。
我还发现我需要这些信息才能从我正在导入的 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。
像魅力一样工作！
除非您想创建互操作 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)\Microsoft SDKs\Windows\v7.0A\Bin
如果你想引用 4.0，$(SDK40ToolsPath) 是指向 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools 的宏。
在 VS 2010 命令行中，“where tlbimp”将首先显示 NETFX 4.0 Tools 文件夹中的 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 可执行文件的问题。
找出你默认使用的那个：
where tlbimp
对我来说是
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\TlbImp.exe
改为使用较低版本的，例如
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\tlbimp
它为我生成了一个 .Net 2 程序集，无需编辑配置文件。您可以在 exe 上使用 CorFlags 来确定它使用的 .Net 版本。或者你可以在你的输出中使用 Corflags。
【讨论】：