We all not and understand the notion of a Visual Studio Project and a Visual Studio Solution.
The point is that a solution has many projects and a project can belong to many solutions.
Solution & Project format
The format of a Visual Studio Project is MSBuild. The format of a Visual Studio Solution is something proprietary. It’s not even xml, it reminds me a basic(ish) look
By the way I never understood the reason that they didn’t use MsBuild also for solutions. The following is simply a random solution file.
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MVVM", "MVVM\MVVM.csproj", "{5071C191-7663-422C-AE32-4B638F6C12FA}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MVVM.Test", "MVVM.Test\MVVM.Test.csproj", "{2399D68D-7791-4979-B1F7-FD17A6399E2B}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Any CPU = Debug|Any CPU
Release|Any CPU = Release|Any CPU
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{5071C191-7663-422C-AE32-4B638F6C12FA}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{5071C191-7663-422C-AE32-4B638F6C12FA}.Debug|Any CPU.Build.0 = Debug|Any CPU
{5071C191-7663-422C-AE32-4B638F6C12FA}.Release|Any CPU.ActiveCfg = Release|Any CPU
{5071C191-7663-422C-AE32-4B638F6C12FA}.Release|Any CPU.Build.0 = Release|Any CPU
{2399D68D-7791-4979-B1F7-FD17A6399E2B}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{2399D68D-7791-4979-B1F7-FD17A6399E2B}.Debug|Any CPU.Build.0 = Debug|Any CPU
{2399D68D-7791-4979-B1F7-FD17A6399E2B}.Release|Any CPU.ActiveCfg = Release|Any CPU
{2399D68D-7791-4979-B1F7-FD17A6399E2B}.Release|Any CPU.Build.0 = Release|Any CPU
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
Build Events
What is a build event? Well by default every project gets to override two build events: Pre-Build and Post-Build. You can attach your own batch functionality here. Personally if you understand MsBuild well enough then there are better and more MsBuild friendly ways to do this. I consider this the poor mans approach to hook before and after the build. Stay tuned I will soon right a post on this…
Visual Studio provides also some help for you. If you click the “edit” buttons then you will get a simple editor with a list of “Macros”.
These macros are nothing more than PropertyGroups inside the hierarchy of MsBuild files that define the project. No wonder the convention for referening to any of these is $(macro_name).
Don’t abuse the build events
Wow, some very hard words. Abuse the build events? Well it can happen! Let’s take an example of a known open source project: Prism. You can download the sources at http://compositewpf.codeplex.com/
Prism offers some nicely written AcceptanceTests. I strongly recommend it for better understanding of UI Test Automation. Now the problem they try to address for the AcceptanceTest developer is solution decoupling. The AcceptanceTest Project being a black box, has no dependencies on any of the sources. On the other side the AcceptanceTest developer needs the possibility to make sure that the sources are build before executing the tests. In order to address this the Prism team has use a post-build event on the AcceptanceTest project.
$(MSBuildBinPath)\msbuild.exe "$(SolutionDir)..\MVVM.sln" /p:configuration=$(ConfigurationName)
The problems with this approach are the following:
- You are obliged to build your app every single time you build your tests. In a larger system you partition solutions in order to avoid having to load (or build) too many projects. The cycle of change-build-run needs to be as fast as possible.
- Making use of the $(SolutionDir) macro is not wise. Why? Well as I mention in the beginning of my post there can be a many-to-many relation between solutions and projects. As it’s easy to understand using the $(SolutionDir) macro forces you to be able to build the project ONLY within the context of the solution. Otherwise the relative path has a high risk to be wrong.
- A better approach is you really like to use build events would be to use the $(ProjectPath) macro.
In a bigger system you will NEVER build solutions. Typically you build groups of projects in a well defined sequence. I include a sample of how to do this. My recommendation: don’t build solutions, build projects.
0 comments:
Post a Comment
Post a comment