Visual Studio and .NET Framework Home
'The "ResolveVCProjectOutput" task failed unexpectedly' when building projects in parallel (MSBuild)
1/29/2008 10:56:16 AM
User(s) can reproduce this bug
In MSBuild 3.5, when we try to build any project that references a VC project using the "/maxcpucount:2" option and the BuildInParallel="true" property of the MSBuild task, that project fails to build with the error 'The "ResolveVCProjectOutput" task failed unexpectedly'.
All projects in our solution build successfully in Visual Studio 2008 and with MSBuild 3.5 w/out parallel building.
I am building on Windows Server 2003 R2 SP2 x64.
Here are what I believe to be the important parts of the error output:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(1212,9): error MSB4018: The "ResolveVCProjectOutput" task failed unexpectedly.
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(1212,9): error MSB4018: System.Reflection.TargetException: Non-static method requires a target.
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(1212,9): error MSB4018: at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object index)
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(1212,9): error MSB4018: at Microsoft.Build.Tasks.ResolveVCProjectOutput.ResolveUsingVCEngineObjectModel(ITaskItem projectRef, String configName, String& resolvedAssemblyPath, String& resolvedImportLibraryPath)
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(1212,9): error MSB4018: at Microsoft.Build.Tasks.ResolveVCProjectOutput.Execute()
.NET Framework 3.5
Windows Server 2003
Operating System Language
Steps to Reproduce
1. Reference a VC project from another project (in our case C# projects)
2. Call msbuild.exe on the solution and specify the /m:2 command line option. The build machine must have at least two processors/two cores.
When the build process tries to build the project that references the VC project, it fails with the error detailed above.
The build should succeed, just as it does when not building in parallel or when building in the Visual Studio IDE.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 6/5/2008 at 11:47 AM
I have similar issueand filed another bug: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=349531.
on 4/3/2008 at 12:56 PM
Thanks for the feedback. The workaround did get rid of the error, but based on some initial testing our build actually takes longer in parallel without node reuse than in serial with node reuse. It looks like only a fix to the underlying issue would allow us to use parallel builds with any benefit.
on 4/1/2008 at 9:57 AM
The workaround in the customer information is correct. You can either turn off BuildInParallel, not use multi-proc or use the /nr:false switch to disable node-reuse. This is a known issue with this task in multi-proc.
Jason Edward Davis
on 2/29/2008 at 9:23 AM
I was able to get rid of the warning:
"warning MSB3422: Failed to retrieve VC project information through the VC project engine object model. COM object that has been separated from its underlying RCW cannot be used."
by turning off node reuse (the /nr:false switch). We were still getting this warning with .NET 3.5 projects but turning off node reuse has seemed to "fix" it.
on 2/26/2008 at 11:30 AM
Has any more progress been made on this issue? Were you able to reproduce it?
on 2/6/2008 at 1:48 PM
After further testing I found the following new information:
1) There is no issue if the projects are targeting the .NET 3.5 framework. I see the issue when targeting the .NET 2.0 framework.
2) The error is sometimes a bit different if I specify different properties (/p option)
The other error I sometimes get is a "type or namespace name ... not found" error preceded by these warnings:
"C:\...\ParallelBuildTest\ParallelBuildTest.sln" (default target) (1) ->
"C:\...\ParallelBuildTest\ClassLibrary1\ClassLibrary1.csproj" (default target) (2) ->
(ResolveVCProjectReferences target) ->
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3422: Failed to retrieve VC project information through the VC project engine object model. COM object that has been separated from its underlying RCW cannot be used.
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3425: Could not resolve VC project reference "..\CppDependency\CppDependency.vcproj".
I will attach my test solution to this feedback.
on 2/6/2008 at 1:40 AM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.
It may help if you provide us with:
a) the C# and C++ project files involved (just the .proj files for each, not the source files) and the Solution file if possible
b) if you have deleted any configurations from VC project or added any configurations to C# project and if you are building one of those configurations (either explicitly or by default.)
If we do not receive a response from you after 7-days , we will automatically close your issue. There is no obligation to respond -- at any time you may edit your issue via Connect and change the status to “Active.”
Visual Studio Product Team
on 2/5/2008 at 3:42 PM
Well well well - I guess I'm not crazy after all. I'm getting exactly the same problem and would really appreciate to hear the outcome whenever you guys figure it out.
on 1/30/2008 at 1:52 AM
Thanks for your feedback. We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Visual Studio Product Team
to post a workaround.
Please enter a workaround.
Cliff Hudson - MSFT
on 4/1/2008 at 9:48 AM
This is a known issue. The workaround identified in the community comments is the correct one. You can either turn off BuildInParallel, not use multi-proc build, or use the /nr:false switch to disable node reuse.
© 2013 Microsoft