I recently answered a question on stackoverflow.com Replace .sln with MSBuild and wrap contained projects into targets and wanted to share that content here as well. I’ll expand a bit more on it here.
A couple common questions that I’m frequently asked include
- Should I use solution files for public builds
- How can I replace a solution file with an MSBuild file
My answer for 1 is that I never use .sln files for any public build. I always create my own build file and use that. My take on solution files is that they are for developer convince for use in Visual Studio only. If you disagree, you are not alone.
Replacing a solution file with an MSBuild file is pretty easy, you just create an MSBuild file to build your projects. You will do that by using the MSBuild task. Now if you want to create a reusable .targets file (or set of .targets files) then this is a bit more involved, but makes it easier on you in the long haul.
I wrote about 20 pages on creating reusable .targets files in my book, but I'll get you started here with the basics here. I believe that the key to creating reusable build scripts (i.e. .targets files) is three elements:
- Place behavior (i.e. targets) into separate files
- Place data (i.e. properties and items, these are called .proj files) into their own files
- Extensibility
- .targets files should validate assumptions
The idea is that you want to place all of your targets into separate files and then these files will be imported by the files which will be driving the build process. These are the files which contain the data. Since you import the .targets files you get all the targets as if they had been defined inline. There will be a silent contract between the .proj and .targets files. This contract is defined in properties and items which both use. This is what needs to be validated.
The idea here is not new. This pattern is followed by .csproj (and other projects generated by Visual Studio). If you take a look your .csproj file you will not find a single target, just properties and items. Then towards the bottom of the file it imports Microsoft.csharp.targets (may differ depending on project type). This project file (along with others that it imports) contains all the targets which actually perform the build.
So it's layed out like this:
- SharedBuild.targets
- MyProduct.proj
Where MyProdcut.proj might look like:
Release $(MSBuildProjectDirectory)\BuildArtifacts\bin\
And SharedBuild.targets might look like:
<_RequiredProperties Include ="Configuration"> $(Configuration) <_RequiredProperties Include ="OutputPath">$(OutputPath) <_RequiredItems Include="Projects">%(Projects.Identity) %(Projects.Identity) SharedBuild_Validate; BeforeBuild; CoreBuild; AfterBuild; <_FullOutputPath>$(OutputPath)$(Configuration)\
Don't look too much at the SharedBuild_Validate
target yet. I put that there for completeness but don't focus on it. You can find more info on that at my blog at http://sedodream.com/2009/06/30/ElementsOfReusableMSBuildScriptsValidation.aspx.
The important parts to notice are the extensibility points. Even though this is a very basic file, it has all the components of a reusable .targets file. You can customize it's behavior by passing in different properties and items to build. You can extend it's behavior by overriding a target (BeforeBuild
, AfterBuild
or even CoreBuild
) and you can inject your own targets into the build with:
... $(BuildDependsOn); CustomAfterBuild
So this is the basics on how to create reusable build scripts which can help you easily create .proj files to replace your .sln files. I also recently answered. a related question Make a target run once at the Solution level in MSBuild.
This samples for this are using Visual Studio 2010 RC You can download the samples for this at http://sedotech.com/Content/files/ReplaceSlnFile.zip
Sayed Ibrahim Hashimi
Comments are closed.