VS2010 COM互操作错误解决方法？ （INetFwMgr）

Question

（编辑：。解决了，解决办法很简单 - 打造2008SP1，以产生Interop.NetFwTypeLib.dll，只是把它作为一个第三方组件，感谢里克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?)）...

我发现了一个Microsoft bug，如果有人说：

SDK 4.0 tlbimp.exe是始终进口 第一个，它不请按照 正确的流。即使你手动 调用tlbimp.exe并给出正确的 路径。这是 问题的根本原因。任何驻留在 非默认流中的COM dll与4.0的tlbimp.exe将有相同的 问题。

而且依次为：

SDK 3.5 tlbimp.exe是没有这个 问题。一个解决方法是使用3.5 tlbimp.exe是从作为 它存储在注册表中的完整路径和 参考此互操作程序集在 您的项目手动导入 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; 
     } 


    } 
} 

Answer 1

你VS2010溶液可以成功地利用互操作程序库如：

• Interop.NetFwTypeLib.dll

产生可以使用VS2008实用程序解决方案，也可以使用旧版SDK工具手动创建。

如果您使用的是源代码管理，那么只需使用VS2008生成一个互操作库并将其签入，然后将VS2010解决方案的引用添加到签入的互操作库中，而不是导航到COM组件。

Answer 2

当我们试图编译一个引用这个COM对象的项目时，我们遇到了同样的问题。

在装有Windows 7 x64和VS 2010的机器上，它编译得很好。 在使用Win2003 x64和VS 2010（其中的同一项目）的计算机上，出现编译错误“无法找到类型或名称空间名称INetFwMgr”。

Firtst我做了什么 - 我将构建输出设置为“详细”。我观察到它RUS此命令：

"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） 。问题就解决了。