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