(or "MSBuild sucks at solutions - one simple proposal you can try")MSbuild is a product with some great advantages, the foremost being the flawless IDE integration. However, it does have some
weaknesses - one being the weak solution story.
Sample of stuff you cannot do with MSBuild without resorting to hacks:
- Theres no story for executing something just before a compile actually happens
- You cannot set up anything to happen at the
end of a solution build- The API (object model) is weak, you
cannot even get a hold of the currently executing project (!).
From there on it just gets worse.
This is by design - you are not supposed to operate on the context and there seems to be no way to set up any state for the currently executing solution build.
The solution story is very weak, it generates a project in memory from the old syntax, and
you cannot really access it -
to set up solutionwide properties, imports,
hook into the process, etc.
The general idea of having a very clear and limited interface towards tasks is naturally good, and would work if the solution story was stronger - and in line with the rest of the design. Since it is this way however, many things prove difficult to accomplish.
Ugly hack it! There have been
proposed solutions using wrappers, but those are unusable in the IDE, which again really is the forté of msbuild. If we don't get IDE integration there are other solutions (SCONS, rake) that beat msbuild with one hand behind their backs. So one option is to put state into environment vars (pretty, aint it - gets that 80's smell back into the room). If you want static properties you can meddle with the files in the framework (system) directory, but in many companies that is not a tolerated option.
When confronted by a problem such as this, I usually have faith in the designers and start researching - banging my head against the wall trying to find an appropriate solution. This time was no different. Then comes the realization phase that there is actually no way forward by means of the intended uses. You step back...
My proposed solution is simple; for me the problem was essentially twofold - I wanted to be able to keep state that all projects could share over the course of a solution build, and I wanted to hook into the start and end of the solution build process. My idea: Create a singleton that stores state over the life of the appdomain and a set of tasks that allow the projects to interact with it.
1. For state there are tasks that allow you to get and set data
2. For hooks there is an initialized flag and a task to set it as you set data, and then there is a task by which you may retrieve the value of the flag.
In order to use this alternative, you are only required to put an import into each project file - which seems to be the standard and least obtrusive way of mopdifying the build process (analoguous to MSBee).
Note that this is still a hack! Why? First, it doesnt adhere to the design of MSBuild, with very clearcut interfaces between tasks, targets, etc (although, that is the problem since MSBuild is half baked, see above). Second, the end-of-solution targets are called from a destructor - which is bad (read up on who executes the destructor and how to find out why it is bad, save for the fact that it is conceptually bad). So this is at best an interim way to get things done - the first thing I could think of.
The best way to see how this works is to download the src zip, and open it up in visual studio (or just review the example test solution). It has a test solution that you can run (F5) and examine it to see how to use this little piece of code.
Please get back to me if there are bugs, improvements or maybe better/cleaner ways of accomplishing what I want.
Known issues: No logging when "end of solution" target runs.
SolutionUtilTasksSrc.zip (128.36 KB)SolutionUtilsBin.zip (11.23 KB)