Home Dashboard Directory Help

'The "ResolveVCProjectOutput" task failed unexpectedly' when building projects in parallel (MSBuild) by dcstraw


Status: 

Resolved
 as Fixed Help for as Fixed


5
0
Sign in
to vote
Type: Bug
ID: 324846
Opened: 1/29/2008 10:56:16 AM
Access Restriction: Public
1
Workaround(s)
view
8
User(s) can reproduce this bug

Description

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()
Details
Sign in to post a comment.
Posted by Alex Ivanoff 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.
Posted by dcstraw 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.
Posted by Microsoft 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.
Posted by 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.
Posted by dcstraw on 2/26/2008 at 11:30 AM
Has any more progress been made on this issue? Were you able to reproduce it?
Posted by dcstraw 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.
Posted by Microsoft 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.”

Thank you,
Visual Studio Product Team
Posted by mikejdavison 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.
Posted by Microsoft 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.

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by 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.