Bugs item #1314179, was opened at 2005-10-05 13:00
Message generated for change (Comment added) made by daniel_bowen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1314179&group_id=31650
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tasks
Group: 0.85
Status: Open
Resolution: None
Priority: 6
Submitted By: Daniel Bowen (daniel_bowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect reference to non-default type library in DLL
Initial Comment:
It appears that if you add a reference in a .NET project
to a COM type library that is not the first or default type
library for a DLL that the incorrect type library is
referenced when generating an interop assembly.
For an example, create a new c# project in Visual
Studio .NET 2003. Right click on "References" under
the project node in the solution explorer. Select "Add
Reference". From the COM tab,
choose "NetFwTypeLib", which is the type library 3 in
hnetcfg.dll. Add the following code to a class:
using NetFwTypeLib;
...
Type fwType = Type.GetTypeFromProgID
("HNetCfg.FwMgr", false);
INetFwMgr fwMgr = (INetFwMgr)Activator.CreateInstance
(fwType);
This will build fine if you build the solution through
Visual Studio .NET 2003. However, if you run it through
Nant, it fails with the error:
"error CS0246: The type or namespace
name 'INetFwMgr' could not be found (are you missing a
using directive or an assembly reference?)"
If you use ildasm to view the interop assembly
generated by Visual Studio.NET 2003 and the one
generated by Nant, you can see that Nant generated an
interop assembly for the first type library in hnetcfg.dll,
not type library 3. You can see that NetFwTypeLib has
the GUID {58FBCF7C-E7A9-467C-80B3-
FC65E8FCCA08}. In HKCR\TypeLib\{58FBCF7C-E7A9-
467C-80B3-FC65E8FCCA08}\1.0\0\win32 you can see
the default value (with the location of the DLL) is
C:\WINDOWS\system32\hnetcfg.dll\3 (or slightly
different, based on the location of your Windows
directory).
Thanks,
-Daniel
----------------------------------------------------------------------
>Comment By: Daniel Bowen (daniel_bowen)
Date: 2005-10-05 14:20
Message:
Logged In: YES
user_id=619351
I looked through the code just now, and I see where the bug
is. In src/NAnt.VSNet/WrapperReference.cs, there's a call
off to "ExtractTypeLibPath", which intentionally strips off the
resource identifier if there is one. Then in
src/NAnt.Win32/Tasks/TlbImpTask.cs, the resource ID is not
put back in when building the command line for tlbimp. It'd
be better off not having or calling "ExtractTypeLibPath" at all,
because having the trailing resource ID is supported. If you
run tlbimp /?, there's this comment at the end:
A resource ID can optionally be appended to the
TypeLibName when importing a type library from a module
containing multiple type libraries.
For example: TlbImp MyModule.dll\1
Thanks,
-Daniel
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1314179&group_id=31650
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
