Search

MSBuild builds the clean target of VS solution files in the wrong order by Martin Moe

Closed
as Fixed Help for as Fixed

1
Sign in to vote
0
Sign in to vote
Sign in
 to vote
Type: Bug
ID: 390914
Opened: 1/5/2009 4:53:29 AM
Access Restriction: Public
0
Workaround(s)
1
User(s) can reproduce this bug
I have described the problem in detail in these blog posts:

http://brumlemann.blogspot.com/2008/12/msbuild-of-vs-solution-under-target.html
http://brumlemann.blogspot.com/2008/12/why-it-is-error-for-msbuild-to-build.html

A demo solution is described along with the necessary and sufficient conditions. The demo solution is attached.

In short, the problem is that, under simple circumstances, the running of the UnregisterAssembly task on an assembly fails because one or more assemblies needed by the assembly loader (used during UnregisterAssembly) has already been cleaned away.

As I have demonstrated in the attached solution and blogged about this will be triggered for example when a type in the depending assembly inherits from a type in the assembly it depends upon (even though the inheriting type is not exposed to COM)

Calling devenv.exe is a sort of workaround that might work in many cases but this is not a good solution. One example is with TFSBuild where the promoted way is to list the solutions to build inside the TFSBuild.proj. Enabling cleaning of the build will then fail.
Details (expand)
Product Language
English

Version

Visual Studio 2008 SP1
Operating System
Windows Server 2008
Operating System Language
English
Steps to Reproduce
- Build the attached VS solution (either using VS or MSBuild from a command prompt)

- Build the clean target (/t:clean) of the attached VS solution file using MSBuild from the command line.
Actual Results
The projects contained in the solution file are cleaned in the same order as during regular build (/t:build) and thus fails on a missing dependency.
Expected Results
The projects in the solution should be cleaned with a dependency order opposite from that of a regular build, thus cleaning the dependant project before the project that it depends on.
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
BuildDependencies.zip
Sign in to post a comment.
Posted by Microsoft on 1/5/2009 at 11:07 PM
Thanks for your feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Posted by Microsoft on 5/27/2009 at 9:27 AM
Thank you for your feedback.

This is the first time we have seen this issue as a problem.

We have logged this as a bug in MSBuild v4.0. Our developers will take a look at it to see what we can do to resolve the issue.

Thanks,

Chuck England
Visual Studio Platform
Program Manager - Project and Build
Posted by Microsoft on 8/18/2009 at 9:37 AM
This has now been fixed in Visual Studio 2010 and should be available in the next release.

Interestingly enough, the solution build has traditionally been a little different than building projects directly. This is because Visual Studio actually calls out to MSBuild to build what it thinks is appropriate. We have added code to support this behavior such that these two should now be in sync. We still have work to do in the solution space, which will need to occur in another release.

Thanks for taking the time to report the bug to us.

Chuck England
Visual Studio Platform
Program Manager - MSBuild
© 2010 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement