A colleague of me pointed out that there are several stages of emotion when developing SharePoint. Ignorance, Anger, and finally Acceptance. This makes you wonder… Why the anger?
So after experience them all, I found out that the default SharePoint Development workstation provided by Microsoft (Visual Studio in combination with MOSS) was lacking, how should I bring this… Completeness! Every developer in town will automatically say, is there any software that truly complete, well have to acknowledge that I haven’t found any in my lifetime, but the search continues. What I want to point out is that there is a LOT of room in SharePoint Development for tooling. A great resource for all sorts of tooling that will make life easier you can find at http://www.sharepointblogs.com/ But we are drifting a bit off topic here. One of the main thing’s that made me angry was the seemingly endless repeating of steps needed while developing in SharePoint. Creating a simple WebPart will take a lot of steps I can tell you (all those xml files, you know what I mean).
A little less angry…
First thing a developer will say when they are confronted with repeating steps, lets automate the process as much as possible.
Here is where I met the powerful build system Microsoft provides called: MSBuild.
For example, lets look at the developing process of a WebPart.
- You will startup Visual Studio and begin to write your code and create an .webpart file (or previously an .dwp file)
- You will then create the necessary feature structure required for creating an WSP file.
- You will create the WSP file using the command MakeCab.exe
- You will deploy and publish this feature to your website using the command STSADM.exe
- You will activate and try the newly installed feature.
This process (or something similar, like (un)registering your DLL in the GAC for instance) will be used a lot of times during development. Previously we were using batch files for automating our solutions as much as possible.
But now that we have discovered MSBuild targets we are in the process of getting rid of these batch files and replace them with .target files.
There are a couple of reasons why I think you should consider using this feature:
- More control, There is a tight integration between Visual Studio and MSBuild providing us with more control over what when happens based on al sort’s of states of your project.
- Reusability, given the fact that MSBuild has tight integration it will give you the power of create more flexible scripts, thereby giving you a more reusable solution.
- Cleaner, A lot of “plumbing” is done behind the scene therefore making your solution cleaner. output of the scripts will be displayed in the output window within Visual Studio instead of separate log files for example (although that’s definitely still one of the possibility’s)
- Intellisense, I will not go into this deeper than necessary, Most likely you know what Intellisense can do for you, less code errors due to human type errors ect. ect.
Drawback’s:
So, is this MSBuild your answer to all your developing questions?
Definitely not! On the contrarily, there are some little “problems” with using this.
- Changing any target files (read: script files) require you to reload your solution. This is because the imported target files will only be evaluated during loading of the projectfile.
This is mainly a problem when you are creating new template’s and need to change the target files a lot. - Although using MSBuild instead of Batch Files is more clean, this “behind the scene’s plumbing” can make the whole process less transparent. So here come in the reason that you always need to communicate (read: create documentation) about what’s is happening during the process. I myself find it very useful to use the output windows for showing what is happening in the MSBuild process.
How to use it:
So, now that you have read the benefit’s and drawback’s you may find yourself questioning, can this MSBuild target thing do something for me, and where do i start exploring?
Well, just Google "MSBuild Target" you will find a lot of in depth information about how to do the magic. In this post I will explain my conceptual point of view which I used for my recently created template. The template will consist of a couple of xml based files, all sharing the extension .target
Here’s my concept:
\SolutionDir\MSBuild\
Imtech.Common.Import.targets
Imtech.Common.Properties.targets
Imtech.Common.Targets.targets
Imtech.Common.Tasks.targets
\SolutionDir\ProjectDir\MSBuild\
Imtech.Project.Properties.targets
Imtech.Project.Targets.targets
Imtech.Project.Tasks.targets
I will break these file’s up into pieces for you
As you can see in the used naming convention there are really only 4 thinks to explain here namely: Import, Properties, Targets and Tasks (except from the fact that I used 2 different folders to put these files in, but more about that later on).
- *.Import.targets
This is the file that will connect all the other file’s in the right order and an reference to this file will be placed in your .proj file. - *.Properties.targets
In these file’s you will define you "dynamic" properties.
for example, the path of your local IIS folder or the location of your STSADM.EXE tool. - *.Targets.targets
These file’s will be your "coordinator", and will provide you with the possibility to enforce logic based on the selected "Solution Configuration" and properties you defined in the Properties.targets. It will call tasks defined in your Task.target files based upon the implemented logic.
In other words: this will be your router (I used to be a network engineer, and sometimes still think in terms of networks) - *.Tasks.target
In these file’s you will find separate pieces of functionality that will be referenced in your Targets.target file.
Here you will define the actual commands that will be executed and name/group them using some sort of logical convention.
So now that we have covered the difference’s between the file’s I will explain the 2 folders I used. Earlier I explain that one of the benefits of using MSBuild targets is that it’s reusable. This means that in a new project, I can use the same template as I used before. In order to do this, you have to separate any execution logic from your project dependency’s. This is where the properties target file kick’s into place. In the properties you will define all your project dependant things. And because you probably have more than one project in your solution you have to deal with some "global" and some "local" dependencies. That’s why I used 2 folder’s, one where you can declare your globally used targets, task and properties an one folder where you can (re)define these properties, or even extend your targets and tasks.
If needed I will post some sample’s of the target files we use.
As always, if you have some comment, don’t hesitate to… comment!
