View Single Post
Old 07-22-2005, 11:31 AM
kinook kinook is online now
Join Date: 03-06-2001
Location: Colorado
Posts: 5,723
With a sample provided by RTS, we were able to reproduce this behavior. It is caused by an apparent bug in the .NET Framework (all 1.0 and 1.1 versions; it's fixed in .NET 2.0 beta 2) when calling LoadLibrary on a .NET COM interop DLL. When the COM Register action is used to load and register or unregister a .NET COM interop DLL (even though it has no DllUnregisterServer entry point), this interferes with the Make VS.NET action (which is itself a .NET/COM component) getting loaded later on.

The workaround is to either exclude COM Interop DLLs from being registered or unregistered by the COM Register action (since they don't expose a register/unregister entry point anyway) or instead use a Run Program step (marked to ignore failure) with a command of

regsvr32 /s "c:\path\to\file.dll"

to register or

regsvr32 /s /u "c:\path\to\file.dll"

to unregister

Since a Run Program call to regsvr32 occurs in a separate process space, the bug does not affect the VBP process where the build is executing.

If you're not using the COM Register action in your build and this doesn't resolve the problem for you, please provide a reproducible test case for us to investigate. Thanks.
Reply With Quote