+972 52-548-6969
MsBuild vs. NAnt
A long while ago I moved the Rhino Tools repository to using MSBuild. I am not quite sure what the reason for that was. I think it was related to the ability to build it without any external dependencies. That is not a real consideration anymore, but I kept that up because it didn't cause any pain.
Now, it does.
More specifically, I can't build the rhino tools project on a machine that only have 3.5 on it. The reason is that I have a hard coded path with 2.0, which worked well enough, until I tried to work on 3.5 machine. In which case all hell broke loose.
Well, that is an easy fix, right? Just go and change the hard coded 2.0 to the current framework version, right?
Except that the msbuild doesn't have any way to do that.
I am surprised, to say the least. And yes, I know that I can extend it to support this. I am not particularly sure that I want to, however. At this point, it would be easier to just move it to NAnt, I think. It would also align rhino tools with the tooling all its dependencies are using.
Comments
Is it possible to have only 3.5 ? I always thought 3.5 = 2.0 + 3.0 + System.Core, etc.
GetFrameworkPath (http://msdn2.microsoft.com/en-us/library/ms164297.aspx) ?
Andrey,
No, I need the framework version. In other words, "2.0", "3.5", etc.
I can probably do string manipulation to get the correct version from the framework path, but I am not going to even try to do that, frankly. Too much work for such a simple thing.
Do you need the latest version installed or what the C# project is compiling against? If it is a csproj building against MSBuild 3.5, it has $(TargetFrameworkVersion) ("v3.5", etc).
If you need some specific path, it may be easier to get it from the registry $(Registry:...).
Do you need the latest version installed or what the C# project is compiling against? If it is a csproj building against MSBuild 3.5, it has $(TargetFrameworkVersion) ("v3.5", etc).
If you need some specific path, it may be easier to get it from the registry $(Registry:...).
I have a 2005 project that I am building on 3.5 machine.
Out of curiosity, what's the path with the "2.0" in it?
f:\oss\castle\build\net-2.0 <-- this is the part that tripped me.
Isn't this what you are looking for?
http://msdn2.microsoft.com/en-us/library/microsoft.build.tasks.msbuild.toolsversion.aspx
Are there any other reasons you are considering moving to nant? I'm just evaluating whether to use msbuild or nant to build the stuff (maybe I'll still use nant for the rest of the stuff) for my company. I have some strong advocates of "going the MS-way" and after some research I didn't find any compelling reason not to do so.
alberto,
That would have been great... except that it is not accessible from the script.
You can only set this, not read this.
Prefer NAnt, it is signficantly simpler from my perspective.
It also let you have two ways to build the project, so you know that you are good in this regard.
if you move to NAnt, i won't hate you any more for using MSBuild in the first place. ;)
+25 reputation points
I'm currently working on (or at least trying to) package RhinoMocks (and Castle) for Mono on Debian/Ubuntu. MSBuild can really be a pain in the ass here. Chances are better to get a NAnt build running on Mono. But in most cases it's even preferred to create a custom Makefile (MonoDevelop can convert solutions to a Makefile).
So +1 for using NAnt with Rhino Tools.
I've been doing a lot of build work in both MSBuild and NAnt lately and I totally favor NAnt. Simple things in NAnt are, for one reason or another, generally hard in MSBuild... but the converse isn't true.
http://www.paraesthesia.com/archive/2008/01/08/why-nant-is-better-than-msbuild.aspx
Isn't the $(FrameworkVersion) property what you're looking for?
1) I'm curious - what is the reason against installing also 2.0 on the 3.5 machine?
2) Are you referring to Team System, or MSBuild as a stand-alone?
Well, I've been using NAnt for a couple of years - mostly for building .Net 1.1 projects.
With the move to .Net 2.0 I started having trouble with NAnt. For one some of my developers started using those non-sense web-projects that where introduced with VS 2005 - and those could not be build using NAnt, since there is no csproj-file any more. OK, so I did some NAnt-ing and wrote a build-script that would take care of that.
But then a while ago I had some trouble compiling VS 2005 csproj-files using NAnt 0.86 :( so that made me consider MSBuild.
Nice thing about MSBuild: it also supports wix-projects :)
My issue with NAnt is just that it hasn't kept up with the times, as far as I can tell - at least not in released versions.
As a bare minimum, I need the build system to be able to take a .sln file from the latest version of VS and build it for the specified configuration. For small projects that's often most of what I want to be able to do, and then do stuff with the output.
Sure, it's a pain to work with stuff in MSBuild - but it can be done. (I haven't worked out how to redirect the output of a task though, which really is an issue for me.)
I really don't want to have to work with a mixture of NAnt and MSBuild, but in some cases I think it would be the most practical solution at the moment. I don't know what the long term solution is going to be, but it's not a pretty situation right now.
Jon,
Why haven't it kept up with times?
<msbuild> task does just that.
But at that point you've really got two build systems involved, which is somewhat inelegant. In particular, I suspect it's not terribly easy to communicate bidirectionally with MSBuild, collecting warnings etc from it, passing in properties, perhaps retrieving properties too.
I'm sure it's all possible, but it means knowing two build systems instead of one.
I would expect the <solution> task to be capable of building VS2005/2008 projects - even if that means an MSBuild call under the hood. But the <solution> task only supports 2002/2003.
Would you say that using the <msbuild> task is now the idiomatic way of actually doing the compilation part of a whole build?
Jon,
What <solution> is for 2002 / 2003, <msbuild> is for 2005 / 2008.
I don't see the difference between the two.
And yes, if you want to build using the VS stuff, you do it with <msbuild>
Personally, I go directly to csc, I find that having a separate build process incredibly helpful
If you go directly to csc, don't you have to have all your references in both the NAnt build file and your csproj file? Or do you extract them out somehow? I can see situations in which it's a nice way to go, but usually I'd want the build that runs on the CI server to be at least reasonably close to what the dev gets in VS - which is where MSBuild has an advantage.
I suppose if you purely regard <msbuild> as a way of building the solution without using it as a general build system in any other way, and never look at the MSBuild files themselves it's okay - it just feels odd to use two different build systems in one.
If you need to poke around in the MSBuild file at all, I think it's simpler to just learn one system well.
Personally I'm a lot more comfortable in the Java world with Ant than with either NAnt or MSBuild in the .NET world, mostly through having rather more experience in that arena.
Jon,
Yes, you need to keep both set of references.
That is very rarely an issue, I have found. You don't often need to add a reference, and the extra step means that you have more control over what is allowed in the build
I suspect if I tried to institute a rule of "to add or change a reference, you need to do it in two places" here, I'd get lynched :)
If it works in your environments though, more power to you! I'm sure it depends on how many projects are around, how fluid they are, and how large they are. (Yes, this touches on a previous post. I usually find people have too many projects for my liking.)
I can see the advantage of the "MSBuild as a black box" approach too, btw - I'm not trying to be difficult for the sake of it :)
Comment preview