Search

MSBuild ignores ProjectSection(ProjectDependencies) in sln file and attempts to build projects in wrong order by ThomasIsr

Closed
as Fixed Help for as Fixed

20
0
Sign in
 to vote
Type: Bug
ID: 586358
Opened: 8/14/2010 2:47:03 PM
Access Restriction: Public
1
Workaround(s)
18
User(s) can reproduce this bug
In a 33-project solution file there is one ProjectDependency which is ignored. It is a C#-project which is dependent on a C++-project (using COM-interop), so we can't use a project reference in the csproj-file.

Note that we only see this problem when using /m:2 (or higher) on the msbuild command line. But I guess that it could just be a conincidence that msbuild decides to build the C++ project first in the non-parallel case rather than it reading and respecting the dependency. We can't tell.

The solution builds perfectly fine from Visual Studio - also with Visual Studio set to do parallel builds in options dialog.

We also see this on WinXp.

We also see this with Team Build. That was actually where it was discovered.
Details (expand)

Visual Studio/Silverlight/Tooling version

Visual Studio 2010

What category (if any) best represents this feedback?

 

Steps to reproduce

msbuild MySln.sln /p:Configuration=Release;Platform=x86 /t:rebuild /m:2 /p:TrackFileAccess=false /v:minimal

Product Language

English

Operating System

Windows 7

Operating System Language

English

Actual results

Wrong build order leader to failed build.

Expected results

correct build order and succeeeded build.
File Attachments
File Name Submitted By Submitted On File Size  
connect.zip (restricted) ThomasIsr 8/16/2010 -
Sign in to post a comment.
Posted by Microsoft on 3/12/2012 at 5:11 PM
This should be fixed in 4.5. Sorry about the bug. If you get a chance to try the Beta, and still have an issue please open another connect bug so we're sure to see it.
Thanks,
Dan
Posted by Matt Zinkevicius on 3/8/2012 at 3:54 PM
Dan,
No, that workaround doesn't help, at least in our case. We have all C# projects in our solution, but we are forced to use explicit dependencies for a couple references, since the projects are shared with other solutions and we can't update the shared projects without breaking those external solutions. Given just 2 C# projects A-> B you can hit the issue if an explicit dependency is used and the solution file happens to list the 2 projects in the wrong order. You workaround doesn't help this case if I understand it correctly.

There is another workaround floating about that works, but is untenable to maintain. You can manually edit the solution file to order the projects correctly. Sadly, adding/removing projects causes VS to overwrite those changes so it is a non-solution for teams that maintain large enterprise code bases.

Is this planned to be fixed in VS12/.NET 4.5? A build tool that doesn't handle dependencies properly isn't very useful :-). Thanks!
Posted by Microsoft on 1/27/2011 at 8:41 PM
I haven't heard back, so hopefully this workaround is acceptable. This is on the backlog to improve in a future version.
Dan
Posted by Microsoft on 1/19/2011 at 10:49 AM
re adding the reference when you don't want it to, you only want to order it--

did you try this - the subelement here?
<ItemGroup>
<ProjectReference Include=”…relativepathto\project.csproj”>
     < ReferenceOutputAssembly>false</ ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
Posted by Matt Ryan on 1/18/2011 at 3:21 AM
Hi Dan

We attempted to implement the workaround you described (for a solution with a dozen projects, all C#).

One drawback is that the solution having final say over the build order was handy when attempting to share a subset of the solution projects between other solutions via a branching strategy. (Which then leads to problems on merging if those shared projects reference other projects for build ordering when they are not present in other solutions.)

But the more annoying issue is that publishing of Web Projects picks up project references added this way during its Resolve References step, and so includes this unnecessary assembly - referenced only for the purposes of ordering the solution build - amongst the assemblies deployed to the website...

It would be nice to see this issue fixed, but unless its already in SP1, I'm guessing we'll be waiting for vNext and solutions-in-msbuild format...

Cheers

Matt
Posted by Microsoft on 12/25/2010 at 2:59 PM
John/Thomas --
I'm not sure that Chuck's post below was entirely to the point. I've attempted to explain the issue and the recommended fix/workaround on our blog here:
http://blogs.msdn.com/b/visualstudio/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx

>>if you have projects in the solution that are not referenced, (and I mean referenced, not set as dependencies), it does not build them either.
I can't reproduce this with MSBuild 4.0. I added a C# project A.csproj to a solution, and added a project reference to B.csproj from A. Only A was in the solution file. Then I built the solution file, and it built B.csproj. (In 3.5 it doesn't seem to do this though).

Dan
Posted by John_Bergman on 12/21/2010 at 5:30 PM
More Information... Not only does MSBuild 4.0 not build the dependencies correctly, if you have projects in the solution that are not referenced, (and I mean referenced, not set as dependencies), it does not build them either.

Currently, I have a solution that has all of our common library assembles, not all of the assemblies are build, in particular the Visual Studio Designer assemblies are not built... along with about 30 others. I added a WPF App and added all the projects as dependencies... it builds the application, but it does not build, or it builds and deletes all the dependent assemblies that are not referenced elsewhere.
Posted by John_Bergman on 12/21/2010 at 11:59 AM
I have this same bug with a solution that contains nothing by C# prjects (about 90 of them). All of the projects use Project-to-Project references.

This solution was building properly in VS2008, and using the accompanying build. I upgraded to VS2010 (not to .NET 4.0), and it does not build now, there were 4-5 of these dependency issues.

I was able to solve all but one of the issues by adding explict project references, but I have been unable to correct the final issue where a dependent assembly is not build first, regardless of the dependencies being explictly set in the solution file. I was hoping this would have been fixed in SP1 (Beta), but it is still an issue.,

Is there any hope for a hotfix? I am unable to upgrade our project to use Visual Studio 2010 /.NET 4.0 untill I get this resolved.
Posted by Microsoft on 12/7/2010 at 4:12 PM
The error you are seeing is a bug we already know about. :) Make sure you clean your C++ project prior to adding the reference. If the DLL exists, we try to help you out, and figure out what the DLL is. In this case, we actually break because we think it is a .NET DLL, and we fail.

By cleaning prior to adding the reference, you are removing the DLL, and since all we have to go on is the Project itself, we assume you know what you are doing, and all is well.

So, use the technique you described, but clean the C++ project prior to doing so.

Note that when you build in Visual Studio, you will most likely see a warning (complaining that the DLL is not a managed assembly). And, you will see a yellow bang on the icon in the References folder for the project. They are just warnings and can be ignored.

Chuck England
Visual Studio Pro
Program Manager
Posted by ThomasIsr on 11/18/2010 at 1:26 PM
Chuck,

Thanks for looking into this.

Simple question: How do I add a P2P dependency from a C# project to a C++ project??

This is what I've tried:
Right click the C# project in solution explorer and select "Add Reference", go to the Projects tab and select the C++ project in the list, click OK.

When I do that I get a warning dialog, which tells me that "the target framework for the project [name of c++ project] is higher than the current project target framework version. Would you like to add this reference to your project anyway?". This is nonsense since the c++ project is native (ATL COM), but I click "yes" anyway. And then I get an error dialog saying "A reference to [name of C++ project] could not be added".

The C# project is a .net framework 3.0 project, but I am quite sure that when I tried all this out originally I tried to change to see if it would help. No such luck.
Posted by Microsoft on 11/18/2010 at 10:37 AM
Note that if you need customer support, you need to contact our customer support group. The connect site is for the filing of issues so that we can improve the product.

After looking into the issue, it appears that the solution is to remove the Solution Dependency and add a P2P (Project to Project) reference instead. Using the project that was provided, we were able to reproduce the issue. We then did the above, and resolved the issue.

The Solution Dependency dialogs can be confusing. They are supported as legacy. It is recommened that you use P2P's instead. There are a couple of project types that are still not MSBuild, and may require Solution Dependencies. Since MSBuild does not understand solution files, you can instead try using DevEnv.exe with the /build switch to build the project. This invokes the Solution Build Manager, which in turn invokes MSBuild where needed.

When MSBuild is told to build a solution file, we see it is not a project file, and if it ends with .sln, we attempt to convert it to a project file. We have an existing bug where this breaks which we do not intend to fix, and another case that is not possible to fix.

To add a P2P, just right click on the references in your project, and choose the projects tab and add a reference to the dependent project. (The above assumes the C# project system. There are slightly different experiences depending on the project type.)

We are resolving this issue as Won't Fix, since you should use P2P's going forward.

Chuck England
Visual Studio Pro
Program Manager
Posted by Peter Palotas on 10/21/2010 at 4:57 AM
We've been struggeling with this problem for quite a while now for our Team Build process, and it is extremely frustrating. Reordering the projects in the .sln doesn't work for us either. Sure, reordering them changes the build order, but not neccessarily to the correct one, it just seems kind of random.
It's been two months since this was reported, and it is undoubtedly kind of a critical bug. Any chance of a hotfix for this any time soon?
Posted by Nick Nightingale on 9/30/2010 at 3:32 AM
I have two .vxproj files which must be built before a .csproj file. There are ProjectDependencies in the .sln file for this, but they are ignored by msbuild 4.0. My build is started from Team Build 2010 (RTM) and has /m:1 on the command line. The only workarounds I can find are:
1) Alter the order of projects manually in the .sln file
2) Split the solution into two solutions
Posted by ThomasIsr on 9/15/2010 at 7:04 PM
It's been a month now...

What is the status on this?
Posted by ThomasIsr on 8/16/2010 at 4:42 PM
Dan: Thanks. That's more manageable.

I've attached the sln-file and the project files. Please keep it confidential.

I'll try to work on creating a small repro solution too.

I could also attach an msbuild log-file. Would that be of use?
Posted by Microsoft on 8/16/2010 at 3:41 PM
Thomas could you provide minimally, the .sln file, and ideally the project files it refers to (feel free to obfuscate or remove file names etc). Of course if that reproes as is even better.

In particular pls confirm you are using msbuild.exe 4.0 and this solution has version 9 or 10 at the top of it

Thanks, Dan
Posted by Microsoft on 8/15/2010 at 8:22 PM
Thanks for reporting this 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.

Please give us a demo project to demonstrate this issue so that we can conduct further research.

It would be greatly appreciated if you could provide us with that information as quickly as possible. If we do not hear back from you within 7 days, we will close this issue.

Thanks again for your efforts and we look forward to hearing from you.

Microsoft Visual Studio Connect Support Team
Posted by Microsoft on 8/15/2010 at 6:13 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)
Sign in to post a workaround.
Posted by Martin Liversage on 10/28/2010 at 4:45 AM
I have encountered the problem in what I think can be simplified to the following situation.

In a Visual Studio 2010 solution projects A, B etc. depends on each other:

A -> B -> C -> K -> X -> Y

A, B and C are C# projects and dependencies are handled by adding references from one project to the next.

Project K is a managed C++ project (CLI). Project C has a reference to project K.

Project X is a C++ library and Y a code generation project. An explicit project dependency is set from project K to X and X to Y.

The solution builds without problems in Visual Studio 2010 but there are problems building the solution when MSBuild 4.0.30319.1 is used.

If MSBuild is used to build project K it will first build Y and then X resulting in a successful build. This is the expected behavior but may simply be a result of the sequence of projects in our solution file. I have tried to manually edit the solution file and it seems that MSBuild will do the correct thing no matter how things are organized inside the solution file.

However, if MSBuild is used to build any of A, B or C it will not build X and Y first leading to the build of K to fail. Apparently the project dependency inference breaks down when the dependency chain is C# -> CLI -> C++. The indirect dependency from C# to C++ is not infered.

Our workaround is to manually add dependencies from project A, B and C to X and Y. It is not enough to add dependencies from C to just X or X and Y. Instead any C# project that indirectly depends on X requires a dependency to both X and Y to build succesfully.

There has been some guesswork and black-box testing involved in arriving at my workaround so my analysis may not be entirely correct. Nevertheless I hope it will help you get around failing builds.
© 2013 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement