VS11: Regression WDP4 -->Consumer Preview: MSBuild.exe apparently causes MT.exe to fail by holding a newly created dll open - by bugzapper

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


2
0
Sign in
to vote
ID 728912 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 3/5/2012 1:12:05 PM
Access Restriction Public
Moderator Decision Sent to Engineering Team for consideration

Description

I have never seen this problem with the version of VS 11 paired with WDP1 8102 or other pre-beta builds until the version of Visual Studio 11 released on 2/29/12 for Consumer Preview 8250. 

I now see the following error consistently on both of my PCs, and other devs here are reporting exactly the same. 

mt.exe : general error c101008d: Failed to write the updated manifest to the re
source of file "F:\AccuRev\Voyager_DevHead.pc2.1\Voyager\Build\Bin\x86\Checked\
xr-CoreInterop.dll". The process cannot access the file because it is being use
d by another process. [F:\AccuRev\Voyager_DevHead.pc2.1\Voyager\Src\Core\Intero
p\InteropCoreDll.vcxproj]


I found many bugs in Connect related to MT.EXE, but none seemed to reference MSBuild as the process holding a newly built dll open and causing MT.EXE to therefore fail. I also tried turning off AV (Microsoft Security Essentials) because many bugs in Connect referenced that as a potential conflict with MT.EXE, but that didn’t fix this. Therefore this appears to be a new and different bug.

Hardware info:

One of my PCs is an old dual core 4GB Dell Optiplex 780 with 8250 x86. The other is a fast new Dell Optiplex 990 with 16 GB and quad cores. So if it is a race condition, it happens across a broad spectrum of hardware. 

Our Projects/Solution:

We are developing V4 print drivers for Win8. Our solution contains a mixture of C++/Win32 dlls, C# assemblies, and C# applications. We created all the project files using VS 11 – In other words, they are new, not converted or upgraded. The dll for which MT.EXE fails is compiled with the /clr flag and contains both C++/CLI and native C++ code.

Impact:

This will cause all of our our automated builds, such as our nightly build to fail, so this is blocking our adoption of this release.

Thanks in advance for your time and help!

Best Regards,
Al Robertson
Xerox 
Sign in to post a comment.
Posted by Cameron Taggart on 4/13/2012 at 6:38 PM
I ran into the same problem and the workaround worked for me as well, thanks! Just make sure you kill the current MSBuild process first, then rebuild.
Posted by bugzapper on 3/10/2012 at 5:03 AM
Dear Amit,

THANK YOU so much for the workaround as well as the coming fix. This was our only blocking issue with VS 11 beta, and the workaround worked beautifully. We really appreciate your help.

We are charging ahead with V4 print driver and Metro development!

Best regards,
Al Robertson
Xerox
Posted by Microsoft on 3/8/2012 at 4:33 PM
Hi,

Thanks for reporting this issue. We have identfied the issue internally as well and as a workaround please disable Managed Incremental Build from the General property page of the projects. We are working on a fix and a fix will be available in the next public release of Visual Studio.

Thanks,
Amit Mohindra
Visual C++ Team
Posted by MS-Moderator08 [Feedback Moderator] on 3/5/2012 at 11:01 PM
Thank you for reporting this issue. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by MS-Moderator01 on 3/5/2012 at 7:14 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)