Make VS.NET step fails often

[jason_looney]

Within the past week or two, our "Make VS.NET" steps have suddenly started failing about 75% of the time. The error message (see attached) says that two copies of mscoree.dll are in use. I have searched MSDN and Google and haven't found any useful info.

We can build the projects manually using Visual Studio. We have tried removing all older versions of the .NET Framework and explicitly declaring the path to devenv.exe on the Options tab of the make properties.

We are running Visual Build Professional 5.4.

Thanks!
--Jason Looney

[kinook]

Does the problem persist if you replace VisBuildDotNET.dll in your install path with this one: http://www.kinook.com/Download/VisBuildDotNET.zip?

[jason_looney]

Yes, unfortunately, the problem still occurs after copying the DLL into Program Files and rebooting the machine.

[kinook]

I assume you meant that you copied it to C:\Program Files\VisBuildPro? Does the problem exist using version 5.3?

[jason_looney]

Correct -- we overlaid the existing version.

I know the problem occurred with 5.0, but have not tried 5.3.

[kinook]

Ok. I thought maybe the problem had something to do with 5.4, since it was released recently. If 5.0 fails as well, there's no need to try 5.3. This is not something we've seen or had reported before. What else changed on the box recently? It sounds like something is awry with your .NET configuration.

[jason_looney]

It happens on multiple boxes. We haven't changed anything with .NET in a long time, but there's a good chance that all the machines have had various Microsoft (and Norton, etc.) patches pushed out to them. If you guys haven't seen this, then it probably is some sort of conflict with a third-party patch.

Are there alternate ways of making VS.NET binaries that you can recommend? Since we can build the projects via the Visual Studio IDE, maybe there's an easy workaround...

Thanks for your quick responses!!!

--Jason

[kinook]

It certainly sounds like some sort of update is playing into this. But I wouldn't excuse an MS patch or security update just yet -- some of theirs have been known to have unintended side effects as well (having been bitten by one of these myself, I'm quite leary of installing their patches).

As a workaround, if you don't need the extra capabilities that the Make VS.NET action provides, you could just invoke devenv directly from a Run Program action [1] to build VS.NET projects/solutions from your build. (The Make VS.NET and VS.NET Get Version actions are the only parts of VBP that use .NET.)

But it would be nice to get to the bottom of this. We probably won't be able to do much unless we can reproduce the problem here, and to do that we'll need to know what caused it. The only way to determine that would likely be for you to start with a clean machine and systematically apply all the updates pushed onto these boxes since the problem first manifested, building enough times after each update to tell if the problem occurs.

[1] http://msdn.microsoft.com/library/de...neSwitches.asp

[RTS]

Hi,

I realise this is an old post but I'm beginning to see this problem too on our build system when building .net projects. Was there any resolution in the end?

Thanks

[kinook]

Not yet. Which version(s) + SP of the .NET Framework do you have installed? This article [1] suggests installing .NET 1.1 SP1 for resolving such an error.

[1] http://blogs.msdn.com/robgruen/archi...14/408209.aspx

[RTS]

We're running .net 1.1 sp1 (I have just checked by attempting to install sp1 again - it said it was already installed).

We are running Visual Build 5.7 also.

I will re-install the service pack to see if the problem clears.

[RTS]

Unfortunately a re-install of the service pack has not helped and we're still seeign this problem. It happens regularly.

The odd thing is, if a build fails with the error, you can close the script (and Visual Build), re-open it, build and everything works. However just trying to re-start the script fails.

[kinook]

Are there any other versions of the Framework installed on the box (what are the subfolders under %WINDIR%\Microsoft.NET\Framework)? Which version/SP of Windows are you running on? Were there any software applications/updates installed or changes to the build project that seem to have triggered this behavior? Is the problem specific to one machine or does it occur on multiple machines? Can you narrow the problem down to a reproducible case that we could build here? Thanks.

[RTS]

Hi

It's our build machine which is a very clean environment with no beta versions of the framework etc.

The versions are 1.0.3705 and 1.1.4322. As I explained I've also put SP1 on for 1.1.

Windows is XP Pro with all updates to date.

Other than that nothing has changed as far as I know. We've traditionally used VBP to build VB6 applications and have had a few .net projects. We have recently however introduced more so perhaps that's it?

It's entirely reproducible here. The weird thing is if it happens and the buidl fails, trying to start the build again causes a file in use failure in the .net compiler. Then if you exit and open the build again then run it all is fine.

Is there anything I can sent you to help diagnose the problem?

[kinook]

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.