SharpDevelop Community

I just read through the roadmap for #Develop 3.0. I noticed that NAnt support will be dropped, and I am curious as to why that is.  Is NAnt no longer keeping pace with .NET Framework development? What build system will #Develop integrate with instead? MSBuild?

 Thanks,

 Greg

You can build any SharpDevelop 2.x (and 3.0) solution or project directly using MSBuild.

There is no need to keep a separate NAnt file. You can still port the NAnt AddIn from SharpDevelop 2.0 and continue developing it as 3rd-party AddIn if you want.

Thanks.  I'm developing a roadmap for migration of my company's product to .NET 2.0/3.0.  Given how pricey VS.NET is, I'm considering dropping it altogether and using #Develop instead.  Our current build system uses CC.Net in combination with NAnt and other tools, so that's why I was asking about NAnt support in #Develop 3.0.

 

NAnt is still supported and will remain supported for 2.1.

The reason we dropped it for version 3.0 is that we no longer use NAnt for our build process - even our CC.NET-based build server has been transitioned to use MSBuild instead of NAnt.

Chris 

Isn't the reason for using NAnt because it's a cross-platform build tool that's more easily scriptable than MSBuild? I know #Develop currently only runs on Windows, but aren't there any aspirations to change this? Removing NAnt support is only going to make the project more Windows dependent, which is a step backwards in my opinion.

There are no aspirations to be x-platform. We are no longer using NAnt in our build process, we switched entirely to MSBuild / CruiseControl.NET.

And we don't view the ability to depend on the dominant operating system as a step back: it helps reduce the number of moving parts, the different configurations, different user setups. Whenever I read the MonoDevelop discussions, I am glad that we do not have to support the myriad of different distributions / configurations.

Chris 

It's also worth noting that the latest NAnt builds support building MSBuild files. Once mono gets their MSBuild implementation further along, MSBuild files *will* hypothetically be cross-platform.

 

That being said, I would personally like to see #develop's components have less coupling to the underlying platform so they could be re-used more easily outside of #develop. It's really just a matter of better encapsulation of platform-dependent behaviour, which would be helpful to the overall design in general, by my estimation. :) While I understand not wanting to increase the workload by 'aspiring' to be more cross-platform, I also see no reason not to make things worse on this front by depending on platform-specific tools or technologies.

We did factor out a lot of components to be reuseable outside of SharpDevelop. But quite frankly: who is the target audience of cross platform components? Most definitely not the MonoDevelop guys. So who is the audience? I am not going to waste my team's time on something next to no one needs.

Chris 

To put it in different words:

When MonoDevelop forked off in the far distant past - far before #D 1.0 - a number of key features was completely different from what they are now: the core was different, the AddIn loading mechanism was different etc. besides this, Namespaces in MonoDevelop have drastically evolved away from #D. This alone would make porting parts of #D to a platform independent format difficult, not to mention the p/invokes which would require creating a HAL.

And our small team really does not have the resources to pull this off, especially with all the current work on key features that are of immediate importance to you, our users.

Should any of you be interested in working on this endeavour, you have our blessings and we cordially invite you to join our team. However, up to now, I personally have the feeling that there is no more than vague interest in this proting project out in the great wide open. If you prove me (and Chris) wrong, I'm happy to be wrong (yet again).

About the original post and the title of this thread:

I use #Develop at home and MonoDevelop at work. I never needed NAnt at home, as I always build from inside #Develop. At work we used NAnt for a while, but as I made the switch to MonoDevelop I also switched to build using mdtool and the MonoDevelop solution and project files, in a manner similar as possible to building with MSBuild (perhaps if and when MonoDevelop will completely switch to the VS2005 format solution and project files, the same as #D did, I will switch from mdtool to XBuild).

I found NAnt to be not friendly enough, and was just a bit nicer than simple makefiles. The same goes to almost any other build system (SConstruct, for instance). The good thing about solution/project files is that they put order into things. The library structure will most likely be the same as the solution/project files structure, and the same as the version control structure. Plus, it saves duplication and management of build instructions, file lists, etc.

 

About the rest of the posts, which probably should have been posted in the thread about making #D cross platform:

With all the progress of the mono project, and with other talks about implementing cross platform libraries of the most common PInvoked methods, I think #D will eventually be able to run on Mono (and therefore on almost any OS).

But perhaps there should be some common work on the two projects; after all, in the MonoDevelop SoC ideas you can find "porting new features from #D". Plus, they have made the addin architecture open (Mono.Addins) (although it had been forked out already, as I saw in some older post). Maybe it's a good idea to take the advantage of Google's SoC and MonoDevelop suggested back-porting project to make some of the code shared by the two projects, so both sides could benefit from the progress.

Itai.