Udostępnij za pośrednictwem

Visual Studio Team System Chat

  • Artykuł

Well, I was supposed to blog about this before the actual event, but I haven't been feeling well and didn't have a chance...  I just finished up representing Team Build in the Visual Studio Team System Chat (info at https://msdn.microsoft.com/chats for future reference - I believe the next one is October 4th), where hopefully I managed to answer a few questions and help some people out.

I promised to follow up here on one question that I was unable to answer during the actual chat - here's the transcript (note that my answers are not direct quotes, since they disappeared from my chat GUI too quickly to cut and paste - I'll update them later for historical accuracy):

Q: Visual Studio projects contain a platform of "AnyCPU" (no space) but the TFS targets have "Any CPU" (with a space), is this a bug?

A: Good question. This is an MSBuild issue... Within Team Build it should not be a problem, since when MSBuild creates in-memory MSBuild projects from solutions it does the mapping appropriately. Is it causing you problems, or were you just curious?

Q: The TeamBuild targets file has a number of conditions that look for the space, however, if we include the space the project doesn't build because there is no configuration with that name.  Also, if the space isn't included, each project appears in the build steps list twice (although it is only built once).

A: In general, Team Build is designed to build solutions, rather than projects. The conditions you mention are typically designed to be paying attention to solution-level configurations, rather than project-level configurations. If you put your solutions into the SolutionToBuild collection rather than your projects, everything should work as expected.

Q: The problem is we don't have solutions, we have a number of very large applications (245 projects) and VS just doesn't like solutions that size... So we have a custom MSBuild task that returns a list of projects to build in the order they need to be built and we put that into the SolutionToBuild item.

The nice thing about building solutions in Team Build rather than projects is that it allows us to piggyback on the Configuration Manager functionality in Visual Studio.  This functionality basically maps a single solution-level configuration (Platform / Configuration combination, actually) to multiple, potentially different, project-level configurations.  For example, if you have a solution with one web application and one C# project, you will typically use the Mixed Platforms platform, which will map to .Net for the web application and Any CPU for the C# project. 

This is nice in Team Build because it allows users to specify Platforms and Flavors/Configurations across all of the items in the SolutionToBuild item group without having to worry about how these map to individual project level configurations.

So - if you want to specify projects in SolutionToBuild rather than solutions, you will need to make sure that they can all build with the same Platform and Flavor values.  For example, if all your projects are C# projects, you should be OK.  Otherwise you will be in a bit of trouble.

Assuming that this is not an issue for the Questioner above, how should he/she proceed?  Two issues were mentioned:

  1. The conditions in Microsoft.TeamFoundation.Build.targets look for "Any CPU", but the projects require "AnyCPU".  This shouldn't really be a big deal - just use "AnyCPU" and don't worry about the conditions in the targets file.  For some reason, there is a convention that output directories should be of the form <configuration>\<platform> when the platform is anything but "AnyCPU", and just <configuration> otherwise.  So - if you specify "AnyCPU" as your platform, you will get your binaries placed into Debug\AnyCPU rather than just Debug.  This doesn't strike me as a particularly big issue...
  2. Each project appears in the build steps list twice (although it is only built once).  This actually has nothing to do with the "Any CPU" / "AnyCPU" issue, but instead is a result of specifying projects directly in the SolutionToBuild item group.  In Team Build 1.0, build steps are added for solutions based on their presence in the SolutionToBuild list, and then added for projects when their CoreCompile targets are reached.  When the SolutionToBuild items are themselves projects, they show up once as solutions and once as projects.  While this is annoying, it shouldn't cause any major problems.

To fix issue #2, I would recommend that rather than having a custom task return a list of the projects to be built, you have a custom task generate an MSBuild project file which builds each of the projects (using MSBuild tasks), and specify just this one file in your SolutionToBuild item group.  This generated file would then serve as the proxy solution, while your projects would be treated just as projects (and thus would get only a single build step added).

Hope this helps for now, and hopefully we can improve this aspect of Team Build in the next version.

FYI - the source code and explanation for the ItemGroupCrossProduct task will have to wait for another day, even though my loyal reader(s) is (are) clamoring for it...

Comments

  • Anonymous
    September 08, 2006
    Aaron Hallberg on Visual Studio Team System Chat and MSBuild Batching - Generate a Cross-Product (continued)....