Search

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

Resolved
as Fixed Help for as Fixed

4
Sign in to vote
0
Sign in to vote
Sign in
to vote
Type: Bug
ID: 324846
Opened: 1/29/2008 10:56:16 AM
Access Restriction: Public
1
Workaround(s)
7
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()
Details (expand)
Product Language
English

Version

.NET Framework 3.5
Operating System
Windows Server 2003
Operating System Language
English
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.
Actual Results
When the build process tries to build the project that references the VC project, it fails with the error detailed above.
Expected Results
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. [Details]

 

File Attachments
1 attachments
ParallelBuildTest.zip
Sign in to post a comment.
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
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 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 David Straw 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 David Straw 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 racinstellar 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 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 David Straw 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 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.