4

(EDIT: solved , solution was simple - build in 2008SP1, take the generated Interop.NetFwTypeLib.dll and simply use it as a 3rd Party assembly. Thanks Rick Sladkey.)

I've upgraded some code (down below) referencing a COM object to VS 2010. Still on .Net 3.5.
The build is broken since then: (The type or namespace name 'INetFwMgr' could not be found (are you missing a using directive or an assembly reference?))...

I found a Microsoft bug, where someone stated:

SDK 4.0 tlbimp.exe always imports the first one, it doesn't follow the correct stream. Even if you manually call tlbimp.exe and give the correct path. This is the root cause of the problem. Any COM dll that resides in a non-default stream will have same problem with tlbimp.exe of 4.0.

And followed by:

SDK 3.5 tlbimp.exe doesn't have this problem. A work around is to use 3.5 tlbimp.exe to manually import the Interop assembly from the full path as it is stored in registry and the reference this Interop assembly in your projects.

Can someone explain the workaround ? (i tried the obvious tlbimp COM_DLL /out=OUT_DLL, no good).

Did someone encounter this with another COM ?

Thanks!

Note: XP...
Yet another note: Tried the VS2010 SP1 as well, no luck.

The code (partial...):

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;
        }


    }
}
Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Hertzel Guinness
  • 5,912
  • 3
  • 38
  • 43

2 Answers2

4

Your VS2010 solution can successfully utilize an interop library such as:

  • Interop.NetFwTypeLib.dll

generated either with a utility VS2008 solution or created by hand using older SDK tools.

If you are using source control then just generate the interop library with VS2008 once and check it in and then add a reference from the VS2010 solution to the checked in interop library instead of navigating to the the COM component.

Rick Sladkey
  • 33,988
  • 6
  • 71
  • 95
  • Like i mentioned, i tried the `tlbimp COM_DLL /out=OUT_DLL` with 2008 command prompt, referenced that dll- no good. Am i doing something wrong? – Hertzel Guinness Apr 14 '11 at 08:35
  • 1
    You are creating work for yourself! Before porting your project to VS2010 you had a perfectly good Interop.NetFwTypeLib.dll in the obj folder. Just use that one. – Rick Sladkey Apr 15 '11 at 05:23
2

We faced with the same problem when we tried to complite a project that had a reference to this COM object.

On machine with Windows 7 x64 and VS 2010 it compiled fine. On machine with Win2003 x64 and VS 2010 (the same project in it) we got compilation error "The type or namespace name 'INetFwMgr' could not be found".

Firtst what I did - I set build output to "detailed". I observed that it rus this command:

"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 

and result of this command is fine - it produces the file

"D:\Projects\Framework\Projects\FrameworkBase\obj\Debug WF\Interop.NetFwTypeLib.dll" 

The same file is produced on Windows 7 machine. However, there is one difference: the sizes of the files Interop.NetFwTypeLib.dll are very different.

It seems to me that files hnetcfg.dll on Windows 7 machine and on Windows 2003 x64 machine are too much different, and, unfortunately, the import table in Windows 2003 file is broken.

I have no idea if Microsoft has fixed this and if in some Windows update they will submit a normal hnetcfg.dll with normal import table. I don't care about them.

What I did is next: I got a normal Interop.NetFwTypeLib.dll on Windows 7 and included it in separate folder of a project into source control, and put my reference to this file (instead of having reference to COM). And the problem is solved.

antyrat
  • 27,479
  • 9
  • 75
  • 76
Ihor B.
  • 1,275
  • 14
  • 17