Kinook Software Forums

Go Back   Kinook Software Forums > Visual Build Professional > [VBP] Third Party Tools

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 06-04-2004, 11:51 AM
jason_looney jason_looney is online now
Registered User
 
Join Date: 06-04-2004
Location: Denver, CO
Posts: 4
Send a message via Yahoo to jason_looney
Exclamation Make VS.NET step fails often

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
Attached Images
 
Reply With Quote
  #2  
Old 06-04-2004, 12:15 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,752
Does the problem persist if you replace VisBuildDotNET.dll in your install path with this one: http://www.kinook.com/Download/VisBuildDotNET.zip?
Reply With Quote
  #3  
Old 06-04-2004, 01:41 PM
jason_looney jason_looney is online now
Registered User
 
Join Date: 06-04-2004
Location: Denver, CO
Posts: 4
Send a message via Yahoo to jason_looney
Yes, unfortunately, the problem still occurs after copying the DLL into Program Files and rebooting the machine.
Reply With Quote
  #4  
Old 06-04-2004, 01:48 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,752
I assume you meant that you copied it to C:\Program Files\VisBuildPro? Does the problem exist using version 5.3?
Reply With Quote
  #5  
Old 06-04-2004, 01:49 PM
jason_looney jason_looney is online now
Registered User
 
Join Date: 06-04-2004
Location: Denver, CO
Posts: 4
Send a message via Yahoo to jason_looney
Correct -- we overlaid the existing version.

I know the problem occurred with 5.0, but have not tried 5.3.
Reply With Quote
  #6  
Old 06-04-2004, 01:54 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,752
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.
Reply With Quote
  #7  
Old 06-04-2004, 02:00 PM
jason_looney jason_looney is online now
Registered User
 
Join Date: 06-04-2004
Location: Denver, CO
Posts: 4
Send a message via Yahoo to 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
Reply With Quote
  #8  
Old 06-04-2004, 02:48 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,752
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
Reply With Quote
  #9  
Old 07-07-2005, 02:30 AM
RTS RTS is online now
Registered User
 
Join Date: 07-07-2005
Posts: 6
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
Reply With Quote
  #10  
Old 07-07-2005, 07:51 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,752
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
Reply With Quote
  #11  
Old 07-07-2005, 08:03 AM
RTS RTS is online now
Registered User
 
Join Date: 07-07-2005
Posts: 6
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.
Reply With Quote
  #12  
Old 07-18-2005, 05:56 AM
RTS RTS is online now
Registered User
 
Join Date: 07-07-2005
Posts: 6
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.
Reply With Quote
  #13  
Old 07-18-2005, 07:17 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,752
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.
Reply With Quote
  #14  
Old 07-22-2005, 04:20 AM
RTS RTS is online now
Registered User
 
Join Date: 07-07-2005
Posts: 6
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?
Reply With Quote
  #15  
Old 07-22-2005, 11:31 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,752
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
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 10:10 PM.


Copyright 1999-2019 Kinook Software, Inc.