MSBuild Extension Pack vs MSBuild Community Tasks

Question

I am just starting to make custom MSBuild scripts for the first time. I see that there are two standard options for extending the features: MSBuild Extension Pack and MSBuild Community Tasks.

I am looking for some guidance about what the differences are between these, and why I would use one over the other, or even both. I have Googled on Bing, but can't see the wood for the trees. Any guidance appreciated.

Answer 1

My 2 cents - I was in a situation where I had to quickly create a build script for a project that was to be run on a vanilla Windows machine (without TFS and VS.NET installed). The build script was supposed to do the following -

1. Get source from TFS
2. Build the projects
3. Execute Unit Tests
4. Run FxCop, StyleCop, CodeMetrics
5. Create Code Documentation
6. Finally, Email results

I had to look beyond MSBuild 4.0, since I wanted an easy way to run the tools mentioned above and also send email. I looked at both MSBuild Community Tasks and also MSBuild Extension pack. While I have read that the extensions pack is a sophisticated wholesome package, I still had a try but I ended up using Community pack as it was really easy to use and even extend the code as compared to the other, EVEN with less or no documentation. Extensions Pack, in my opinion is an option only if you have time to understand how to work with it.

Answer 2

I am currently using MSBuild Community Tasks in my work. I didn't have contact with other extensions, but I can tell few things on this library.
Pros:

• Easy to install (MSI Installer)
• Easy to modify. Source is available, and it has BSD License so it's free to modify. Basically, you just go to .cs file with the same name as the task, modify it, open up .sln file and build the solution. Then you just paste the output to C:\Program Files\MSBuild\MsbuildTasks\
• Some extensions are realy useful, if you don't wanna write to much non-msbuild code. Zipping is great, RegEx operations on files are also useful.
  
  • I didn't try other but I've seen there's few interesting tasks like gacutil (installing dll's to be seen globally), creating IIS directories, changing file attributes...
  • And yes, you can do all this tasks with MSBuild, but you will need to use lots of "Exec" commands, or using c# functions on your properties, and the code will be a real mess to read.

Cons:

• lack of useful documentation (maybe I wasn't searching well enough, but only help I found is downloading source, finding .cs file for your task and analyzing it)
  
  • The thing that annoyed me the most, is that there's no list of attributes for tasks on the project website. You need to google it on forums, or go to the code.
• the only problem I got is that RegexReplace saves files in UTF-8.
  My co-workers wrote like thousands of sql scripts, all encoded in ANSI. When i replaced stuff in them, and passed them to SQLCMD, then it wasn't able to parse the files, because of one sign added at the end of all UTF-8 files (some kind of encoding sign). I needed to go to RegexReplace.cs, change the encoding parameter in one of functions, and then compile it. So basically I needed to create my fork : )
  (Two minutes of work, one hour of explaining people how it works)
  But there was no problem with MSBuild parsing UTF-8 files, so I think you may encounter problems only when working with external tools to process files.

Summary:
This is an useful tool, easy to install and use, it can help to make your code a lot clearer, easier to understand, and it can save some time. I think the biggest problem is documentation, but you can just write name of task and library in google and find some code on forums, blogs and here.

Answer 3

I'll chime in, just 2 cents worth. Couple of things -- first of all I wouldn't exactly call them "standard" options. Both predate MSBuild 4.0 and the inline task and property function features and many of the tasks in them are pretty much obsolete. I've written thousands of lines of MSBuild and have only ever needed tasks from either of those libraries a couple times.

What is nice about them is that they are pretty modular. You can pick and choose only the assemblies and targets files you have need of and check them into your code base without getting "stuck" with the entire implementation. At times I've cherry-picked a task from one library and a task from the other, both in the same build. I always prefer using simple MSBuild 4.0 features over something in the library. I've had interest in some of the tasks in the library but the behavior wasn't at all what I needed so I whipped up my own (the zip tasks comes to mind for this one, since I wanted to control zipping in groups that didn't correlate to the source folders). Once you have to write a single custom task it becomes really easy to roll another and another, all in the same assembly.

In the end, I would say that it isn't really about the library so much as it is about the very specific need you have for particular tasks in the library, use what you need and don't tangle up your build with anything but that.