none
MSBuild vs NAnt

Answers

  • Before delving into the differences, I'd like to point out that NAnt is wonderful.  We love the fact that there is a lot of community involvement around NAnt and NAntContrib in enabling everyone to "build" .NET applications.  We certainly expect both  NAnt and MSBuild communities to interop nicely, and so you should expect to see MSBuild tasks that can build NAnt projects, and vice versa.  If I am not mistaken, NAnt tasks for building MSBuild projects exist today.

    It's easy to enumerate of the technical differences between NAnt and MSBuild.  However, I'd like to point out a fundamental philosophical aspect of MSBuild - i.e. MSBuild delivers a platform for build.  In that regard, we aim to solve some of the key issues at the platform level rather than pushing that responsibility down to the project author or task author.  This leads to technical differences in how dependencies are analyzed, for instance.  Some of the technical aspects are noted below:

    Build Input/Output Analysis:  We believe that dependency analysis of build inputs and build outputs should be something that the build engine understands inherently.  Project and task authors should not have to worry about analyzing dependencies.  To this end, dependency analysis is done at the target level and not at the task level.  You can specify build inputs and outputs at the target level.

    Project Items:  MSBuild supports the notion of "items" that participate as inputs into the build.  Tasks consume and emit Items.  Items are rich, and support metadata.  The concept of project items also enables MSBuild to be "Toolable".

    Toolability:  MSBuild was designed to be integrated with other hosts.  The best example of a host is Visual Studio 2005.  However, the MSBuild engine can be hosted by any application willing to do so.  Apart from being able to host the engine, you can also write tasks that are "host-aware", and can richly interact with the host to enable richer functionality.

    Build Engine for Visual Studio:  Visual Studio 2005 hosts MSBuild and uses MSBuild project files as the basis for all managed projects created within VS2005.  This essentially means that you can build your Visual studio 2005 projects from the command line even if you don't have Visual Studio 2005(for example, on a build machine).  Conversely, you can open up "hand-authored" MSBuild projects from within Visual Studio 2005, hit F5 and run your app within the debugger.

    Once again - the main (or only) difference lies in the fact that MSBuild attempts to define a platform that project authors and task authors can take advantage of.  Other differences are simply technical details that stem out of this important aspect.  In the future, we expect to extend the platform level features to provide even richer functionality to project and task authors.  Of course, this will be done in an incremental and compatible fashion so that existing tasks and projects continue to function as they should.

    Faisal Mohamood
    MSBuild Team

    Friday, April 15, 2005 9:04 AM
    Moderator

All replies

  • Before delving into the differences, I'd like to point out that NAnt is wonderful.  We love the fact that there is a lot of community involvement around NAnt and NAntContrib in enabling everyone to "build" .NET applications.  We certainly expect both  NAnt and MSBuild communities to interop nicely, and so you should expect to see MSBuild tasks that can build NAnt projects, and vice versa.  If I am not mistaken, NAnt tasks for building MSBuild projects exist today.

    It's easy to enumerate of the technical differences between NAnt and MSBuild.  However, I'd like to point out a fundamental philosophical aspect of MSBuild - i.e. MSBuild delivers a platform for build.  In that regard, we aim to solve some of the key issues at the platform level rather than pushing that responsibility down to the project author or task author.  This leads to technical differences in how dependencies are analyzed, for instance.  Some of the technical aspects are noted below:

    Build Input/Output Analysis:  We believe that dependency analysis of build inputs and build outputs should be something that the build engine understands inherently.  Project and task authors should not have to worry about analyzing dependencies.  To this end, dependency analysis is done at the target level and not at the task level.  You can specify build inputs and outputs at the target level.

    Project Items:  MSBuild supports the notion of "items" that participate as inputs into the build.  Tasks consume and emit Items.  Items are rich, and support metadata.  The concept of project items also enables MSBuild to be "Toolable".

    Toolability:  MSBuild was designed to be integrated with other hosts.  The best example of a host is Visual Studio 2005.  However, the MSBuild engine can be hosted by any application willing to do so.  Apart from being able to host the engine, you can also write tasks that are "host-aware", and can richly interact with the host to enable richer functionality.

    Build Engine for Visual Studio:  Visual Studio 2005 hosts MSBuild and uses MSBuild project files as the basis for all managed projects created within VS2005.  This essentially means that you can build your Visual studio 2005 projects from the command line even if you don't have Visual Studio 2005(for example, on a build machine).  Conversely, you can open up "hand-authored" MSBuild projects from within Visual Studio 2005, hit F5 and run your app within the debugger.

    Once again - the main (or only) difference lies in the fact that MSBuild attempts to define a platform that project authors and task authors can take advantage of.  Other differences are simply technical details that stem out of this important aspect.  In the future, we expect to extend the platform level features to provide even richer functionality to project and task authors.  Of course, this will be done in an incremental and compatible fashion so that existing tasks and projects continue to function as they should.

    Faisal Mohamood
    MSBuild Team

    Friday, April 15, 2005 9:04 AM
    Moderator
  • I like the idea of Build Input/Output analysis being done by the engine and not the tasks.  However, I find the logic in the MSBuild analyser to be limited and would like to replace the analysis engine with my own more advanced (but not necessarily general) one.  At present I do this in a specific task by simply not specifying the input and output constraints in the target and letting the task do the work.  However, I would like to do this more generically.  Is there any way I can replace the analysis engine?

    Scott
    Friday, November 04, 2005 12:21 PM
  • Scott,

    Not at the moment, but it's a pain we feel internally as well when we work on converting our internal build process over to MSBuild. We talk a lot internally about how we can make this more extensible in later releases!

    Neil
    Saturday, November 05, 2005 7:23 AM
    Moderator
  • I've used NAnt for a long time. In fact at a previous employer we got so good at using NAnt that the setup for each project was only a few minutes. After working with MSBuild for about ten days I don't think I'll ever get the same level of reuse and speed.

    My main complaints with MSBuild so far are:

    1. Rigidity
      MSBuild is overly formal in it's structure. NAnt is very focused on just getting things done while MSBuild seems very concerned with the how. The silliness a developer has to go through just to delete a bunch of files is a great example. In NAnt I provide a folder and just tell it to delete everything. Simple & Fast. In MSBuild I have to first create an Item collection and then provide the collection to the Delete Task. That's twice the work for the same result. Emailing is another great example. A build tool that can't easily generate an email from log output is a pretty useless build tool.

    2. "You can just write a custom build task"
      I'm REALLY tired of hearing this as an answer to nearly every request on this forum. Build scripts should be very easy to setup and maintain. Requiring developers to write a lot of managed code just to build their managed code is really frustrating. Yes it's powerful but it's not FAST. Every minute I spend debugging code for a build script is money lost. I recognize that some orgainzations can and will take the time to create and manage a large amount of custom build code but that is not normal.

    3. Wacky Flow Control Names
      What's wrong with the keywords If, Else, ElseIf? Why did the MSBuild team decide to spend time coming up with Choose, When, Otherwise? You wasted time and reinvented the wheel.

    4. $ or % or @
      Depending on the context or the Task there are three different ways to refer to Item or Property values. There needs to be just one way.

    A major point in MSBuild's favor is the documentation is in general of much higher quality than NAnt.

    Monday, March 13, 2006 10:53 PM
  • Thanks for the comments, it's always great to hear from someone who has spent time using other tools. For what it's worth, we pretty much share exactly your thoughts. As part of our on-going internal build conversion process we definitely hit many of the same issues. In particular, #2 can be quite a pain. We have ideas for how to fix this in future releases, though!

    Neil

    Tuesday, March 14, 2006 12:52 AM
    Moderator
  • Good to hear. I realize MSBuild is essentially 1.0 and will likely improve over time.
    Tuesday, March 14, 2006 3:00 AM
  • Hi monsoondawn,

    This is excellent feedback and we really appreciate you taking the time to provide it to us.  User feedback of all types (criticisms, feature requests, etc) is the driving force behind future development.

    I wanted to take a moment just to address some of your particular issues in hopes of reducing some of the frustration you've had with MSBuild.

    1. Rigidity

    In NAnt I provide a folder and just tell it to delete everything. Simple & Fast.

    [jeff] the RemoveDir task should support this - if you simply provide a folder for it to remove (as a string or item), it will remove that folder and everything beneath it.  (I saw your related post to this issue, and I'll post specific help over there too :)

    In MSBuild I have to first create an Item collection and then provide the collection to the Delete Task. That's twice the work for the same result.

    [jeff] you don't have to create an item unless you're using wildcards.  you're free to pass literals to tasks that don't expect metadata on items.  for example, you could just do this in a target:

      <RemoveDir Directories="$(SomeDir)\somefolder" />

    or alternatively:

      <RemoveDir Directories="c:\base\child\somefolder" />

    and the RemoveDir task will remove "somefolder" and everything beneath it.

    Emailing is another great example. A build tool that can't easily generate an email from log output is a pretty useless build tool.

    [jeff] we wanted to ship an email task but we just didn't have time for version 1 :)  additionally, there should be an easy way to access the log the default console logger generates.  as it happens, the ConsoleLogger implemented in Microsoft.Build.Engine.dll is public and extensible; by the end of this week i'll post to the msbuild team blog an example EmailLogger that emails a copy of the log the ConsoleLogger generates :)

    "You can just write a custom build task"
    I'm REALLY tired of hearing this as an answer to nearly every request on this forum. Build scripts should be very easy to setup and maintain. Requiring developers to write a lot of managed code just to build their managed code is really frustrating. Yes it's powerful but it's not FAST. Every minute I spend debugging code for a build script is money lost. I recognize that some orgainzations can and will take the time to create and manage a large amount of custom build code but that is not normal.

    [jeff] i totally hear you on this one.  for version one, we prioritized work on the file format and the core platform knowing our customers would have to live with that throughout the duration of msbuild's lifetime.  obviously this meant we had less time to develop a large set of generic custom tasks.  however, there are a couple of good resources on the net that may help you for now:

    http://www.gotdotnet.com/codegallery/codegallery.aspx?id=b4d6499f-0020-4771-a305-c156498db75e (from Microsoft Services UK)
    http://msbuildtasks.tigris.org/

    additionally, there are some scenarios where a custom task just shouldn't be required but it currently is.  sometimes this points to a flaw in our file format, and we hope to fix those.  creating items and properties dynamically (within a target), string manipulation, passing inputs to and gathering outputs from tasks are some of the places where we've experience pain from our file format, and we want to make it better.

    please keep us informed of any specific scenarios you have trouble with so we can make sure to incorporate that into future plans.

    Wacky Flow Control Names
    What's wrong with the keywords If, Else, ElseIf? Why did the MSBuild team decide to spend time coming up with Choose, When, Otherwise? You wasted time and reinvented the wheel.

    [jeff] we didn't completely make those names up, even if they're unfamiliar :)  we modelled them on constructs from XSLT because we thought they best represented what we were trying to accomplish.  you can read abou the XSLT versions here:  http://www.w3.org/TR/xslt#section-Conditional-Processing-with-xsl:choose  we thought perhaps some of our users would be familiar with those given the popularity of xslt these days, and i think for those who aren't familiar with them that once you discover them they make pretty good sense.

    $ or % or @
    Depending on the context or the Task there are three different ways to refer to Item or Property values. There needs to be just one way.

    [jeff] i agree this can be confusing, and we're trying to think about some of the ways to make it easier in the future - we've even been considering your suggestion of "just one way".

    Hopefully this explains some of our thinking and, even better, helps you become more productive with MSBuild.

    Thanks once again for providing such detailed feedback.

    jeff.

    Tuesday, March 14, 2006 11:59 PM
    Moderator
  • Jeff, thanks for taking the time to address each of my concerns. I do think MSBuild has a lot of potential and look forward to future improvements.
    Wednesday, March 15, 2006 10:44 PM
  • I guess this is a no-go question, but I would like to see it answered:

    The community already has a good tool, NAnt.  Microsoft has the resources.  Why not employ those resources to make NAnt better?  Why re-invent the wheel?  It sure smells to NIH...  The main difference from a my perspective (a developer's perspective) is that when I come across an issue with MSBuild (at the .dll level), I can't go in and fix it.

    Anyway, a tool is a tool is a tool.  Hopefully both of the tools mentioned keep on improving.
    Tuesday, June 20, 2006 7:36 PM
  • I agree!

    As a user who has spent a considerable amount of time working with NAnt and recently introduced to MSBuild it seems to me that Microsoft would have gained a significant amount of brand recognition and support from the development community for working with the existing tool to contrib functionality.  Is the MSBuild tool a critical piece of functionality that is a major revenue driving source? I suppose if it were, then Microsoft would want to protect that asset, but if not, then it makes perfect sense to contribute to the community and work to release a common build environment based on the existing architecture.  Software engineering should not be about reinventing the wheel!

    $0.02 from a real user...
    Tuesday, June 20, 2006 7:51 PM
  • I'm having a love-hate relationship with MSBuild under TFS Team Builds. 

    I've been trying to do what I believe is a simple task; performing a custom action (code generation) just before compilation of each solution.  The problem I am seeing is that MSBuild wants to use the SolutionToBuild list as raw data and do the custom task on all of the solutions and then compile all of the solutions.  So there really is no concept of "For Each Solution Do these Tasks" in the TFS Team Build without overriding the Microsoft provided targets (which I would think is a generally bad idea).  I also don't want to have to update each and every project file to add this customization and I don't want to modify the Microsoft standard targets.

    In NAnt, I can do this in a simple loop. 

    Get all source code
    For each solution
         Run custom task (code gen)
         Compile solution
    Next
    Run Tests
    Label source code

    In TFS Team Builds, Microsoft is recommending that I override a target called "CoreCompile".  Now I don't know about you, but when I'm told to override a core component of a system that is shipped as a unit, I get a little nervous.  I liken this to them telling me that if I want to hook into version control I should open up my hex editor and modify the Team Foundation Version Control dlls.

    This use case is not uncommon, but I wasted 3 weeks trying to get it to work in Team Build only to abandon that process and go back to NAnt.

    Yes I like TFS and MSBuild, but there is still a LOT of room for improvement.  Unfortunately that doesn't help me today, tomorrow or next week (unless you guys are planning to release a SP soon).

    What's the big difference I see between MSBuild and NAnt?
    NAnt is a more mature product with a large community of task builders behind it, MSBuild is in it's infancy and we are all groping around in the dark as to how to get our jobs done.

    Just my $0.02...thanks for the $0.01 change...

    -Steve

    Wednesday, June 21, 2006 1:43 AM
  • There are a lot people complaining about problems when targeting Solution files in MSBuild. I think the only way to solve the problem permanently is for MS to completely ditch the Solution file format . The tasks performed by the Solution file could easily be moved into the Project schema. In fact, MSBuild actually converts the Solution file into a Project format. If the darn thing only started out in the Project schema you'd be able to accomplish your task.

    From your brief description I'd have to say that overriding "CoreCompile" seems like the long way around. However I hesitate to propose any alternative without knowing what you've already tried.

    Wednesday, June 21, 2006 2:57 AM
  • There are a lot people complaining about problems when targeting Solution files in MSBuild. I think the only way to solve the problem permanently is for MS to completely ditch the Solution file format .

    I fully agree on you with this. We stopped using Solution files for production builds, just use them for convenience of local development.

    Sunday, June 25, 2006 5:00 PM
  • We also want to ditch the solution file format. It is a legacy format that we ideally would have converted to MSBuild format in Visual Studio -- this is obviously totally technically possible -- but we didn't have time in V1 to do this and do everything else. The quickest thing for us was to parse the solution file format when we run on the command line, and turn it into an in-memory MSBuild project that we can then build. (To see this project, set environment variable MSBuildEmitSolution=1. You can even keep it and modify it, but obviously it won't keep in sync if you change your .sln.)

    I hope in the next major version of VS the ugly .sln format is gone and replaced with a beautiful MSBuild file. The same applies to .vcproj.

    In fact, ideally we should have n-level traversal projects, not a 2-level .sln file concept. That would obviously be a more major change in VS. MSBuild is a platform - we have to persuade the Visual Studio team to do this work - but I think they are on board. It is a matter of when.

    Dan

    "This posting provided AS-IS, with no warranties"

    Saturday, July 08, 2006 7:25 PM
    Moderator
  • This is really great to hear. I hope you are successful at convincing the VS team the Solution format has to change.
    Saturday, July 08, 2006 8:08 PM
  • Jeff,

    Just read over your comments.  However, I am still not being convinced that.

    What heck MS wants to do things differently?  Why can your team adpots NAnt as the base first and enhances from it?

    "obviously this meant we had less time to develop a large set of generic custom tasks."
    "
    we wanted to ship an email task but we just didn't have time for version 1"

    So why reinvent the "bad and immature" wheel?  I guess we are paying MS for such useless effort.

    "
    we modelled them on constructs from XSLT because we thought they best represented what we were trying to accomplish."

    Oh, why not choose COBOL syntax?

    Sorry for my comment on this matter.
    Wednesday, August 23, 2006 2:05 PM
  • Quick question.

    Which build tool is easier to build ASP.NET 1.1 applications with?

     

    Monday, September 25, 2006 9:24 PM
  • Can anyone share with me thier experiences in creating a build solution for ASP.NET 1.1 web applications/services using either Nant or MSBuild?

    I'm trying to automate these things here at work and I've been trying to use MSBuild. I'm seriously considering a change of course to Nant.

    Any input on the subject would be extremely helpful.

    Thanks.

     

    Monday, September 25, 2006 9:49 PM
  • At my company, we have used NAnt in the past to build both web and desktop projects.  During our initial forays into Team Foundation Server, we tried building those v1.1 apps with MSBuild, but placed that part of the project on the back burner as we wrapped our heads around MSBuild for the new VS 2005 projects.  As of now, we are looking to keep our old build for the v1.1 stuff and build the new v2.0 stuffin MSBuild in parallel (until better support for v1.1 comes along).

    You should be fine using NAnt, I'm of the opinion that MSBuild isn't ready to play nice with the v1.1 projects yet.

    - Steve

    Tuesday, September 26, 2006 1:44 AM
  • Hello,

    I totally agree with n-level traversal projects. The 2-level .sln concept is not good.

    We have a lot of C# code. We started with one monolithic solution. That got painful as C# always wants to build before running. So we moved to multiple solutions. The solutions have implicit dependencies between them. Right now we either build in the correct order by hand or run a simple NAnt script (depending on the programmers workflow). While NAnt is great and all, having to leave the comfy VS environment is less than ideal. I would love to have a solution that can handle this level of complexity. It needs to be pretty smart too, with C# requiring a build before launching in the debugger the solution can not be monolithic or we are back to square one. There has got to be a better way!

    Thanks!

    Zak

    Tuesday, October 03, 2006 5:35 AM
  •  hshen20882 wrote:
    Jeff,

    Just read over your comments.  However, I am still not being convinced that.

    What heck MS wants to do things differently?  Why can your team adpots NAnt as the base first and enhances from it?

    "obviously this meant we had less time to develop a large set of generic custom tasks."
    "
    we wanted to ship an email task but we just didn't have time for version 1"

    So why reinvent the "bad and immature" wheel?  I guess we are paying MS for such useless effort.

    "
    we modelled them on constructs from XSLT because we thought they best represented what we were trying to accomplish."

    Oh, why not choose COBOL syntax?

    Sorry for my comment on this matter.

    Why does this post always show up as the last post???

     

    Tuesday, October 03, 2006 7:01 PM
  • Hey Dan,

    Quick question on Biztalk projects and MSBuild. In Biztalk 2004 on .NET 1.1 you cannot compile biztalk without having visual studio on the build machine. Has this been addressed with MSBuild? i guess its probably a biztalk team question, but im just wondering if there are any MSBuild tasks that allow easy build of BTS.

     

    Thanks,

    Benjy

     

    Sunday, November 12, 2006 11:00 PM
  • MS is very new into the open source community and aparently still has many lessons to learn about code reuse and sharing. I've raised the same question many times before about why MS insists on building a build engine while the rest of the community is targeting NAnt. No one would have had to relearn a new build tool but instead would have been able to focus on providing more input into what would make NAnt better. Instead MS decided to waist millions of developer hours by making everyone not only relearn a new  XML structure for a new build tool but go through the same headaches all over again to make MSBuild anywhere near as useful as NAnt. In its current form, MSBuild isn't anywhere near as useful as NAnt. MS would be wise to just dump the whole MSBuild tool and focus on helping NAnt to become a better tool.

    They didn't learn there lesson with NUnit either because instead of just connecting into the community, as any open source developer would do, to help NUnit better their product they decided to build their own. What a waist of time and money!

    Think of it this way folks, for every tool that MS builds to replace an already existing tool in the Open Source Community waists valuable time and effort that could have been spent making TFS better instead of the half baked tool that they finally released. MSBuild doesn't look anything like the tool(NAnt) that the "Community" has already not only blessed but has been using for sometime now. You guys really do need to learn to practice what you preach.

    REUSE, REUSE, REUSE

    Sunday, March 25, 2007 4:34 PM
  • Dan, I realize that this thought probably didn't even cross your minds but did you ever think of work "WITH" the NAnt guys to use that tool which most developers already know? You would have not only had time, since NAnt is already way more mature and is an excellent tool for builds, but you would have only had to build an interface into Visual Studio to handle NAnt builds. Oh, I'm sorry, theres already a couple of useful open source community tools for that too.

    I'm hoping that someone will soon realize the Community has already blessed NAnt and stop the insanity over at MS. You may have to tweak VS a little to use it but its no where near the work that you'll need to get MSBuild to the same maturity level that NAnt already has.

    Mike

    Sunday, March 25, 2007 5:01 PM
  • Lots of people are complaining about msft developing MSBuild when it [supposedly] could have contributed to the already popular nant. I'm surprised no one has considered what msft gains by creating msbuild. VS uses msbuild now. VS project files are basically msbuild project files. This allows VS projects to be buildable with msbuild without even having VS installed. Thus, developers using VS can work with developers who are not using VS. Imagine if VS used nant. Msft doesn't own nant. Once VS makes dependancies on nant, and nant discontinues, or is significantly changed, msft may have to turn around and stop improvements, or make signficant changes, to VS. Suppose msft felt new features were needed for a build tool (such as those added in msbuild that nant does not support), designed VS to take advantage of those features, then to find the 'community' disagree and remove those features from nant and VS now breaks. I'd be surprised if anyone cannot see the problem with this issue.
    Tuesday, May 01, 2007 10:34 PM
  • Ok Ryan, just from your statements alone I can tell you have no clue about open source and how extremely useful it is as a jump off point or its licensing. And if you do then you need to be reschooled. First off, lets tackle your many points:

    1. No, msft doesn't own nant and thats a GOOD THING, its owned by the community that uses it and helps to build it so you can already see the immediate value in it. Just because you don't have control over it doesn't mean you can't do with it what you like, thats faulty thinking of a dying age of development. This is one where we had thought MSFT was coming around since they have a brand new open source environment out at Code Plex but I guess some just have to learn their lessons over and over again.
    2. Nant will never go anywhere else due to its licensing and its designed to be used for .NET specifically. This means that not only does MS .NET get to reap the benefits but so do other .NET Framework sources such as go-mono.com which is owned now by Novell which also runs on linux, unix, solaris and mac os x. Its free and open for anyone to use as they so choose which means that even if the NAnt community stopped supporting NAnt, MSFT can easily just take themselves a copy in house and develop away. They could have even rebranded it to MSBuild and customized away and no one in the community would have thought a second thing about it. As a matter of fact, we'd have probably praised MS for being so forward thinking and taking us, the developer, into consideration while planning a new build tool.
    3. Well I think I've taken care of the whole dependency thing in #2 but just to make sure, let me interject one final piece. You don't pay for NAnt, ITS FREE!! So if you find that you need to take it in a different direction then you do so with the communities blessing and without fear the .NET Community is going to track you down and demand licensing fees from you because it has a BSD License.
    4. If Ms feels new features are needed then they should build out their own custom features to use in VS.NET, like an interface to go with that nice neat new little toy they didn't have to build in the first place.

    And to kill your final statement, "I'd be surprised if anyone cannot see the problem with this issue." That would be because its not an issue Ryan!! Many of us have been doing or dealing with open source for years!! How do you think that projects like DotNetNuke survive, huh? Do you think the rest of us haven't given this much thought over the many years we've been doing this?

    Mike

    Wednesday, May 02, 2007 12:39 AM
  • Jeff,

     

    The only real complaint I have is MSBuild needs better solution file support. I'm using the Web Deployment project template in VS 2005, and it nicely grabs the project references from the solution file and puts it into an ItemGroup for me. However, I'm trying to set up a complete shared build environment and I need to go to the solution file myself and get the project references.

     

    Sayed Hashimi has described how to get these from the project file (http://www.sedodream.com/CommentView,guid,9c235811-3078-45e7-b122-6a239fb33fc0.aspx), if they are in the project file. This is the case for a web application, but not a web site since the web site doesn't have a project file and the web deployment project doesn't get anything for a web application.

     

    Sayed has also described the method for building a solution via MSBuild (http://www.sedodream.com/CommentView,guid,95544bf1-f5b9-48c4-994b-8581389c4996.aspx). Once MSBuild generates the solution project, the project references are lost or are VERY difficult to decipher, especially trying to find this info the way web deploy wants it.

     

    This brings me to having to parse the solution file myself in a custom task just to find what web deploy sees. Not very fun, and not very efficient, especially when the solution file is rather undocumented, in particular, the VS 2005 solution file. This is the case, unless someone else has a better idea... Wink

     

    Hopefully, MSBuild 3.* will have MUCH better tasks and support for multiple issues already discovered. It would be nice if MSFT also took over the SDC tasks and plugged them into MSBuild 3.*... They are incredible! Almost makes me want to drop Community Tasks!

     

    Thanks for what we have, it's still pretty darn good! And good luck with future releases!

     

    -John

    Thursday, May 17, 2007 5:03 PM
  •  NETDEV68 wrote:

    MS is very new into the open source community and aparently still has many lessons to learn about code reuse and sharing. I've raised the same question many times before about why MS insists on building a build engine while the rest of the community is targeting NAnt. No one would have had to relearn a new build tool but instead would have been able to focus on providing more input into what would make NAnt better. Instead MS decided to waist millions of developer hours by making everyone not only relearn a new  XML structure for a new build tool but go through the same headaches all over again to make MSBuild anywhere near as useful as NAnt. In its current form, MSBuild isn't anywhere near as useful as NAnt. MS would be wise to just dump the whole MSBuild tool and focus on helping NAnt to become a better tool.

    They didn't learn there lesson with NUnit either because instead of just connecting into the community, as any open source developer would do, to help NUnit better their product they decided to build their own. What a waist of time and money!

    Think of it this way folks, for every tool that MS builds to replace an already existing tool in the Open Source Community waists valuable time and effort that could have been spent making TFS better instead of the half baked tool that they finally released. MSBuild doesn't look anything like the tool(NAnt) that the "Community" has already not only blessed but has been using for sometime now. You guys really do need to learn to practice what you preach.

    REUSE, REUSE, REUSE



    Totally agree with Mike!
    With the help of  several  NAnt IDEs(NAntpad, NAntBuilder, Editor4NAnt ) , NAnt is much easier to use. MS  should  make NAnt better but not insist on building a build engine!!
    Thursday, October 04, 2007 4:57 PM
  • Mike,

     

    Just some touches to your remarks.

    * MSBuild is a part of .NEt framework, distributed with it and thus can be used free (unlike VS). You dont pay for MSBuild.

    * VS one of the flagship MS products and to me it only natural that they did not want to base that (and their internal build process incl. Windows etc.) on open source tool. Sure, they could cooperate with the community - but how do you know that the needs of the community and the company are exactly the same?

    * No one should ignore the issue of the project being discontinued. While many open source projects are maintained by the team, many of them are maintained by the very small team (NDoc, NUnit etc.). And if project ceased to be open source, MS will take it in house and start maintainig it? Just as easy as that?

    * Existence of other tools should not hinder anyone of building their ones; the more diversity the better, isn't that the motto of the open source development?

     

    While I may like open source better, and believe in community collaboration, I do see how for-profit company with several thousands developers may choose to develop its own build platform more suited to its needs, with predictable release and maintenance cycle over using open source product. Moreover, it does not seem doing badly at all and compares to NAnt pretty well.

     

    Regards, Eugene

    Friday, October 05, 2007 12:28 AM
  • Hi Eugene,

    1, I know MSBuild is part of the framework, they could have done the same thing with NAnt!! Rename it to MSBuild, tweak it to make it more performant and do the extra stuff they wanted to do and release it into the framework.

     

    2. Well for one Eugene the software they are building, I'm having to use in my day to day life to do the same thing they are doing with it so I think I have a very good idea that it will work for them too. That is unless the universe and the laws of software development stop operating the same in MS land as they do in the rest of the world.

     

    3. Eugene, listen very carefully and try not to put words in my mouth. I'm not suggesting that Microsoft host NAnt as an open source project, althought that wouldn't be a completely bad idea, what I would suggest at minimum is that Microsoft take a copy of it internally and develop it along their own lines and rename it to MSBuild. Microsoft has taken several tools and started developing them as open source, so would it  be so unthinkable to do this with NAnt? Now they are releasing the .NET Framework source to the public which is unpresidented for MS.

     

    Finally Eugene, I dont' think you get the context at all sir. The tool they are building isn't just for MS internally, its for the rest of the world also sense they are forcing us to us it as a part of their tools. If it was just for MS's internal use then I'm sure we wouldn't be discussing it this way now would we?

     

    Mike

    Monday, October 08, 2007 2:10 AM
  • Mike,

     

    The discussion sounds suspiciously like a flame war Smile First of all the argument is completely theoretical, since MSBuild is integral part of .NET 2.0 released in 2004 (if I am not mistaken) and is already used extensively both at MS internally and everywhere in VS/TFS/.NET world. And frankly, it is doing pretty well - there is a whole lot of community tasks doing pretty much everything.

     

    As to your points - I do think that same laws apply to everyone; but size does matter and what might be easier for me/you/your company might be different for MS or Oracle for example. Regarding taking something opensource and rebranding it - why do you think that NAnt is so suitable for internal MS needs? I'd reckon MSBuild is better suited to MS specific tasks. And the effort spent on developing engine suitable for MS toolset vs. effort on making external engine suitable may be not that different after all.

     

    Regardless of the theory, the future is pretty much given - MSBuild is here to stay. And I do not feel like blaming anyone for anything - I think on the whole, MSBuld and NAnt are doing pretty much the same job in a similar way. And even less I like the concept of "they're forcing us" - there is always a choice for you personally/your company as an entity. And there is this forum/MS Connect site for the community to make sure that their voice is heard.

     

    But of course it is my personal opinion. And just for the record - I have been working with Java/C++ on Linux platform and with MS toolset so I can compare the alternatives.

     

    Cheers, Eugene

    Monday, October 08, 2007 2:38 AM
  • It is interesting to see everyones views on the subject.  Nant was the first build tool on the market and is nice as you can pretty much do everything with it including writing scripts in C# that Nant will compile and execute.  The downfall to Nant is that it is poorly supported.  It has been in a Beta/ pre 1.0 release status for ever.  It will work on your development x86 XP box but does not run on x64 Windows Server 2003/2008 machines which is where you will need to put your Continous Integration server.  For more info check out my blog article MsBuild vs Nant
    Tuesday, July 14, 2009 3:39 PM
  • Just to add something here that seems to have been missed in regards to NAnt or NUnit and MSBuild. NAnt and NUnit are Open Source and hence any software that is released with them included has to also be Open Source. Visual Studio is not Open Source and releasing it with NAnt or NUnit would force it to be Open Source under the licensing terms. This is a legal matter and one that Microsoft is very cautious around. The next time someone wonders why Microsoft or Apple or pretty much any company other than Google or Mozilla would not want to include an Open Source tool in their products is because they have no desire to make their product Open Source and lose the revenue; think of the market segment being catered to with VS... developers... completely capable of compiling a product for use.

    Microsoft doesn't take Open Source projects internally. It releases internal projects as Open Source under its licensing terms when it wants to. There is a huge difference there and this all circles around the legal consequences of using Open Source components in a product.
    Monday, October 26, 2009 2:31 AM
  • Nant was the first build tool on the market

    Are you sure? Its name (Not Ant) is proof that Ant existed first. And before Ant there was Make.

    Or do you mean the first build tool for .Net? I will assume that is true if you say so.

    I found this old thread as a result of researching use of Ant in VS. I will look at Nant too.

     

    Sam Hobbs
    SimpleSamples.Info
    Monday, January 02, 2012 4:14 AM