In my experience, build output that's ready to be deployed is rarely flat. Meaning that there are many components and layers in a system and having the binaries all be in one directory is pretty useless. In my situation, I had a custom MSBuild script that took the outputs from many different solutions and projects and organized them into a final output folder. I did this so that local builds outside of Team Build would benefit from the same folder structure. The problem is that Team Build 2010 was not playing nice when it came to my custom build script doing all of the output folder structuring. Organizing the output in prior versions of Team Build could be done by overriding the
[TargetName] target in your
TFSBuild.proj file. In Team Build 2010 however, things are different. 2010 uses Windows Workflow 4.0 for build orchestrating and MSBuild for the actual build, therefore there's not a target to override.
The solution is to clear the
OutDir property so that projects built will use their default output location. You can then pass in the "would be" output location as another property and use that in your build script.
Find the MSBuild activity in the workflow and select it.
Clear the value in the OutDir property and update the CommandLineArguments property.
When setting the CommandLineArguments, you can pass in the value that used to be passed into the OutDir property.
String.Format("/p:SkipInvalidConfigurations=true;MyOutputDir=""{0}"" {1}", outputDirectory, MSBuildArguments)
The fact that the OutDir property is now empty keeps the default output directories for your projects in tact. You can then use your custom
MyOutputDir to manually structure your output. The final drop site is created from a full copy of the output directory, so as long as your output directory looks right, the drop site will as well!
This will come in handy when we move to 2010 sometime in the next 5 years :]
ReplyDeleteThis doesn't work with a solution that has multiple projects. All it does is move all of the output from the default output directory to some custom output directory, but you still wind up with all .exe and .dll type project outputs being blobbed together in one spot.
ReplyDeleteGood point. My situation actually does involve multiple projects and solutions, I just didn't make it clear in the post that my MSBuild script and post build events were structuring the output. The problem was that once I got it working with desktop builds, Team Build was behaving differently which caused the structuring to fail when running the CI build.
ReplyDeleteI've updated the post. Thanks for pointing this out.