VS2010 COM互操作错误解决方法？ （INetFwMgr）
（ 编辑 ：解决了，解决方案很简单 – 在2008SP1中构建，使用生成的Interop.NetFwTypeLib.dll并将其用作第三方程序集。感谢Rick Sladkey。）
我已经升级了一些引用COM对象到VS 2010的代码（下面）。仍然在.Net 3.5上。
从那时起构建就被打破了:( The type or namespace name 'INetFwMgr' could not be found (are you missing a using directive or an assembly reference?) ）…
我发现了一个微软的bug ，有人说：
SDK 4.0 tlbimp.exe总是导入第一个，它不遵循正确的流。 即使您手动调用tlbimp.exe并给出正确的路径。 这是问题的根本原因。 驻留在非默认流中的任何COM dll将与4.0的tlbimp.exe具有相同的问题。
接下来是：
SDK 3.5 tlbimp.exe没有此问题。 解决方法是使用3.5 tlbimp.exe从完整路径手动导入Interop程序集，因为它存储在注册表中并在项目中引用此Interop程序集。
有人可以解释一下解决方法吗？ （我尝试了明显的tlbimp COM_DLL /out=OUT_DLL ，没有好处）。
有人遇到过另一个COM吗？
谢谢！
注意：XP ……
还有一点说明：尝试了VS2010 SP1，没有运气。
代码（部分……）：
using NetFwTypeLib; namespace Utils { public class MSFirewall { private const string CLSID_FIREWALL_MANAGER = "{304CE942-6E39-40D8-943A-B913C40C9CD4}"; private NetFwTypeLib.INetFwMgr GetFirewallManager() { Type objectType = Type.GetTypeFromCLSID(new Guid(CLSID_FIREWALL_MANAGER)); return Activator.CreateInstance(objectType) as NetFwTypeLib.INetFwMgr; } } }
您的VS2010解决方案可以成功利用互操作库，例如：
- Interop.NetFwTypeLib.dll
使用实用程序VS2008解决方案生成或使用较旧的SDK工具手动创建。
如果您正在使用源代码控制，那么只需使用VS2008生成一次interop库并将其签入，然后将VS2010解决方案中的引用添加到已签入的互操作库中，而不是导航到COM组件。
当我们尝试合并一个引用此COM对象的项目时，我们遇到了同样的问题。
在使用Windows 7 x64和VS 2010的机器上，它编译得很好。 在使用Win2003 x64和VS 2010（其中包含相同项目）的计算机上，我们遇到了编译错误“无法找到类型或命名空间名称’INetFwMgr’”。
我所做的最快 – 我将构建输出设置为“详细”。 我观察到这个命令：
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\TlbImp.exe" C:\WINDOWS\SysWOW64\hnetcfg.dll /namespace:NetFwTypeLib /out:"obj\Debug WF\Interop.NetFwTypeLib.dll" /sysarray /transform:DispRet /reference:D:\Projects\Framework\Projects\FrameworkBase\Dlls\KellermanSoftware.NET-Email-Validation.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /reference:"C:\Program Files (x86)\TestDriven.NET 2.0\NUnit\2.4\nunit.framework.dll" /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.configuration.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.DirectoryServices.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Management.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Runtime.Remoting.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Runtime.Serialization.Formatters.Soap.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.ServiceProcess.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Web.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Web.Services.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:D:\Projects\Framework\Projects\Common\ZipLib\bin\Debug\ZipLib.dll /reference:C:\WINDOWS\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll /keyfile:StrongKey.snk
并且此命令的结果很好 – 它会生成文件
"D:\Projects\Framework\Projects\FrameworkBase\obj\Debug WF\Interop.NetFwTypeLib.dll"
在Windows 7计算机上生成相同的文件。 但是，有一个区别： Interop.NetFwTypeLib.dll文件的大小非常不同。
在我看来，Windows 7机器和Windows 2003 x64机器上的文件hnetcfg.dll有太大的不同，不幸的是，Windows 2003文件中的导入表被破坏了。
我不知道微软是否已修复此问题，如果在某些Windows更新中，他们将使用正常的导入表提交正常的hnetcfg.dll。 我不在乎他们。
我接下来做了什么：我在Windows 7上得到了一个正常的Interop.NetFwTypeLib.dll，并将其包含在项目的单独文件夹中，并将其引入到该文件中（而不是引用COM）。 问题解决了。