10

I am involved with maintaining a fairly large portfolio of .NET applications. Also in the portfolio are legacy applications built on top of other platforms - native C++, ECLIPS Forms, etc.

I have a complex build framework on top of NAnt right now that manages the builds for all of these applications. The build framework uses NAnt to do a number of different things:

  • Pull code out of Subversion, as well as create tags in Subversion
  • Build the code, using MSBuild for .NET or other compilers for other platforms
  • Peek inside AssemblyInfo files to increment version numbers
  • Do deletes of certain files that shouldn't be included in builds / releases
  • Releases code to deployment folders
  • Zips code up for backup purposes
  • Deploy Windows services; start and stop them
  • Etc.

Most of those things can be done with just NAnt by itself, but we did build a couple of extension tasks for NAnt to do some things that were specific to our environment. Also, most of those processes above are genericized and reused across a lot of our different application build scripts, so that we don't repeat logic. So it is not simple NAnt code, and not simple build scripts. There are dozens of NAnt files that come together to execute a build.

Lately I've been dissatisfied with NAnt for a couple reasons: (1) it's syntax is just awful - programming languages on top of XML are really horrific to maintain, (2) the project seems to have died on the vine; there haven't been a ton of updates lately and it seems like no one is really at the helm. Trying to get it working with .NET 4 has cause some pain points due to this lack of activity.

So, with all of that background out of the way, here's my question. Given some of the things that I want to accomplish based on that list above, and given that I am primarily in a .NET shop, but I also need to build non-.NET projects, is there an alternative to NAnt that I should consider switching to?

Things on my radar include Powershell (with or without psake), MSBuild by itself, and rake. These all have pros and cons. For example, is MSBuild powerful enough? I remember using it years ago and it didn't seem to have as much power as NAnt. Do I really want to have my team learn Ruby just to do builds using rake? Is psake really mature enough of a project to pin my portfolio to? Is Powershell "too close to the metal" and I'll end up having to write my own build library akin to psake to use it on its own?

Are there other tools that I should consider? If you were involved with maintaining a .NET portfolio of significant complexity, what build tool would you be looking at? What does your team currently use?

RationalGeek
  • 10,077
  • 7
  • 38
  • 56

9 Answers9

3

We approach things as three different activities, Build, Deploy and Install. We use TFS for the build server with a few callouts to Powershell. We then use Powershell to accomplish all of the Deploy and Install pieces which are fairly complex and across multiple servers both local and cloud. I have been very happy with learning Powershell over MSBuild or some other tool. I have also had good experience with Visual Build in the past.

Matt McQ
  • 136
  • 2
2

I use Automated Build Studio. I want to get rid of it.

The only reason why I don't switch to 100% MS Build or Team Foundation Build is the cost it will involve to rebuild the scripts that works perfectly today. The scripts don't change much...

However, for the next product, this will be Team Foundation Build without any hesitation for the main following reasons (they are many more):

  • It's easy to deploy (latest version: 2010)
  • It's fully integrated with Visual Studio and Team Foundation Server
  • It's becoming a standard like MS Build
  • It's free with Bizspark (for startups)

Since you are in .NET also, I warmly recommend you to use TFB.

If you can't apply for Bizspark or can't afford to purchase the license, you can go for CruiseControl.NET + MS Build and few support scripts. At a large utility company I worked for, we had used CruiseControl.NET to build, test, deploy and report all our projects. It included automatic web service deployment.

  • I had not considered this option, but I don't think it would be a realistic option for us since we are not using TFS at all, and have vetoed attempts to move to it in the past (for budget and other reasons). But thanks for the suggestion that is an interesting idea. – RationalGeek Jan 04 '11 at 15:16
  • It's not that expansive. If your management is price sensitive, MS Build will be a perfect match. I used to work with MS Build + CruiseControl.NET only and it worked great! Will add that in my answer. –  Jan 04 '11 at 15:18
  • @Pierre 303: For curiosities sake, why do you want to get rid of Automated Build Studio? – RationalGeek Jan 04 '11 at 15:24
  • @Pierre 303: The expense of TFS is not the only concern. My shop is part of a larger enterprise, and they have standardized on Subversion and other tools and being "non-standard" and going with TFS causes political issues. – RationalGeek Jan 04 '11 at 15:25
  • @jkohlhepp: it's not easy to use, it's not well integrated with Visual Studio (at least the version I have) and it's far from being a standard. –  Jan 04 '11 at 15:27
  • @jkohlhepp: you can use it with SubVersion. –  Jan 04 '11 at 15:28
  • @Pierre: The link you provided is for CruiseControl, not CruiseControl.NET. Personally, I hate ccnet, but to each their own. – Steven Evers Jan 04 '11 at 15:44
  • @SnOrfus: You are right, I copied the wrong link. Looks like the CruiseControl.NET website is infected by two viruses. I won't edit the link for now. –  Jan 04 '11 at 15:48
2

Take a look at hudson and MSBuild as a pair. The power comes with MSBuild's strong capabilities and hudson's plugins.

For instance, you could use hudson and run your NAnt scripts until you migrate to MSBuild and then it can run your MSBuild scripts as well.

Specifically addressing your points:

  • Subversion and Tagging
  • MSBuild
  • Peeking into AssemblyInfo was asked on SO, but the solution might not be to your liking
  • MSBuild can delete files with ease
  • "Release code to deployment folders" - you can have the build system skip that step and deploy it automatically using a number of methods. Or you can FTP if you like.
  • MSBuild can zip
  • Windows services, again MSBuild is your friend here.
Glorfindel
  • 3,137
  • 6
  • 25
  • 33
Steven Evers
  • 28,200
  • 10
  • 75
  • 159
  • Thanks for the info on MSBuild. It seems there is more power there than the last time I tried to use it. Regarding Hudson, does this provide benefit beyond what other CI servers provide, such as TeamCity, which we currently use? I'm trying to avoid upsetting too much of the status quo here, and replacing our CI server at the same time we replace our build scripts seems more painful. – RationalGeek Jan 04 '11 at 15:29
  • In my humble opinion, I think that TeamCity is fantastic... and hudson is better. They can be seen to perform the same functions, until you want to do something awesome - then hudson wins. Honestly, hudson can analyze(stylecop/fxcop)->build->test->tag->local and offsite backup->deploy while keeping you up to date via RSS, SMS, XFD's. – Steven Evers Jan 04 '11 at 15:39
  • Hmm...nothing in that list is impossible with TeamCity, but perhaps it is easier with Hudson. Either way, unless we hit some pain points with TC I don't think we'll switch anytime soon. – RationalGeek Jan 04 '11 at 18:52
  • @jkohlhepp: The difficulty is that there are many many solutions in the same space. At the end of the day, hudson _is_ easy and is _100%_ free. IIRC, one thing that TC might have on hudson is multi-agent building. – Steven Evers Jan 04 '11 at 21:15
2

If you're already using TeamCity, you should be able to use its existing features for most of what you need. It natively supports building Visual Studio .sln files and if you need extra stuff done to all of your projects, you can modify the .NET Framework's .targets files on your build machines, so you don't have to alter individual csproj files.

It will automatically check out from Subversion, zip artifacts, allow you to control which files are considered deployable artifacts. The new version (6.0) also allows multiple build steps, so there's opportunity for xcopy deployment of artifacts to a share.

You can also write your own apps/tasks that can run as part of a build (via the command-line runner) and do anything you want (such as start/stop Windows processes).

Adam Lear
  • 31,939
  • 8
  • 101
  • 125
2

FinalBuilder can do all of your requested items, with a nice GUI and a builder server application thrown in for free.

Matt
  • 1,057
  • 7
  • 14
2

I am currently doing what you are doing (i.e from build to packaging to deployment) using MSBuild (>3000 lines of scripts). The CI is using CruiseControl.Net and hopefully I can move to TeamBuild in future. MSBuild is cumbersome (programming in XML) but it is quite powerful specially the batch processing and dependency tracking. It is actively maintained and improved in new .Net versions and is the basis of build system in Visual Studio and TFS. Also visual studio project files are actually MSBuild projects and I can hook into various extension points. The MSBuild extension pack has many additional tasks and it is trivially easy to create your own tasks programatically. I suggest give MSBuild a serious thought. Lately I am also learning powershell and finding it easy for certain tasks specially in the deployment phase, like installing and configuring certificates, IIS etc.

Edit MSBuild project in VisualStudio as it understands the syntax and gives you intellisense.Here are some other good utilities that will help with MSBuild.
MSBuild Launch Pad - For shell extensions
MSBuild SideKicks - Graphically edit, execute and debug scripts.

softveda
  • 2,679
  • 1
  • 21
  • 21
1

Perhaps you are asking too much of your build script and not enough of your build server -- with team city, you could easily have simple scripts which accomplish each of your bullets, in whatever language or stack that makes sense and use TeamCity build tasks to chain things together as appropriate.

Wyatt Barnett
  • 20,685
  • 50
  • 69
  • It seems that most of these answers are equating CI with build scripts. I had always considered build scripts to be the smarts, and the CI server to be the thing that just kicks off builds based on triggers. But maybe you are right and I do need to rethink this. – RationalGeek Jan 04 '11 at 15:40
1

I strongly recommend TeamCity, it is easy to configure and setup. MSBuild is preferable over NAnt for simple reason that all the project/solution files in the vs2008/2010 are MSBuild files technically, but you can configure TeamCity with MSBuild or NAnt.

OfCourse, TeamCity will cost you. I personally given a choice would prefer rake, simply because the friction with Ruby tools compared to other even though psake is also a good candidate.

Srikanth Remani
  • 166
  • 4
  • 1
    FYI TeamCity is free if you have less than 20 build configurations and less than 20 users. Also, if you are an open source project you can apply to them for a free unlimited license. – RationalGeek Jan 04 '11 at 17:58
0

Did you consider Hudson? It might be abit of a hassle, since it requires Java app server to run, but I think it could let you use your current NAnt script and build on top of that using other tools.

Mchl
  • 4,103
  • 1
  • 22
  • 23
  • Hudson is more of a continuous integration platform, and not really a build platform. We do have a CI server in place - TeamCity, which works fine with NAnt. However, the reasons I want to replace NAnt are because maintaining the NAnt scripts is painful. Using the current scripts through Hudson doesn't solve this problem. Thanks for the suggestion, though. – RationalGeek Jan 04 '11 at 15:18
  • IMHO Hudson is very limited in what it does correctly with VS projects. The checkouts are not tied to changesets the way you expect and behind the scenes it is doing nothing other than running a batch file you create through a web interface and a lot of plug-ins. The reporting it kind of nice if you can get it to work well though. – Bill Jan 04 '11 at 15:21