Dividing work of MSBuild into projects

Question

I'm starting to create a MSBuild scripts for my products, and I've encounter a dilema.

The code is divided into around 25 projects, some wll require obfuscation, some will require strong-name signing; others will require linking into a single file.

All these projects should result in 3 products, with 3 setups.

The question at hand is as follow: How do I divide the MSBuild scripts to make most sense?

Do I create a script for each product? do I create a script for each project? Do I have one script for building, another for obfuscation and so on?

Answer 1

I think this is good idea to have script per product. To minimaze dublication create reusable "sub-scripts" and import them to main script (this could be done with Import directive).

<Import Project="..\Steps\Step1.proj" />

Answer 2

Script per product sounds like the way to go. You may want to consider having any number of shared or base scripts too, to import common build steps. Like Mike Chaliy already mentioned you can then use Import in your product's build script:

<Import Project="..\Shared\Base.proj" />

Another thing you might also want to take advantage of is target and property overriding. It's akin to overriding virtual methods in a .Net class. See the documentation and the MSBuild Team Blog for more details. I know I've taken advantage of this quite often by setting defaults in the included scripts then overriding them as necessary in the product build script in order to customize build behaviour. For instance I often have generated files that are required before the build so I hook those targets into the BuildDependsOn property group. This way my generated files are generated whenever I do an F5 from the IDE, call the build target from the command line or otherwise build the project or solution. Obviously if you have any build steps that run long or only need to be run in special circumstances (like building installers), you'll want to take care about exactly what gets hooked in.