It’s been almost a year since I got involved in a big .Net enterprise project. My first choice would be to do it mostly in Java, but due to politics, or lack of better judgement, .Net was a given constraint. We pushed the technology to it’s limits and found out that some popular tools were just not cut out for that job. However, I’ve also learned that if you dig deep enough, there are some very promising tools for .Net on the Net.
Looking back, the .Net developement landscape is far from ideal – our choices left us with a working environment, and enabled us to get the job done, but with a lot of bumps on the road. From my perspective, .Net is still three or four years behind Java in terms of platform maturity and available tools for enterprise application development. The core development concepts are there, but .Net lacks the support which Java has with a vast number of independent enterprise frameworks, servers and libraries. A lot of popular Java libraries and tools have been ported to .Net, but are often much less stable, or complete, than the originals. But, even though they do not shine brightly yet, there are some rising stars.
Development tools
The standard development IDE for .Net seems to be Visual Studio. I became test-infected about five years ago, and would not give that up for anything, but Visual Studio offers integrated unit testing only in the Team Suite version (the company had only a Professional VS license, so the IDE had no unit-test support). NUnit performed quite well for our unit testing requirements, but it had to be run externally, and there was no click-on-exceptions-inspect-code support, which I got used to in Eclipse. Also, VS can perform only basic refactorings, and for me good refactoring support is one of the fundamental features for a modern IDE. So we tried to find a replacement.
Improve C# plugin for Eclipse offered content-assistance only for C# keywords, without even trying to fetch method names or parameters with reflection, so we quickly discarded it. We then tested Sharp-Develop, an open-source IDE for C# – which offers NUnit and NAnt integration and VS project-file compatibility. However, it is still in an infant stage – it simply had too many bugs and did not offer enough customization to be useful on this project. I see big potential in Sharp Develop, and really think that it can become the Eclipse of .Net if more effort is put into it, but it was not for us at this time. As bad as Visual Studio is as and IDE, it is still the best there is for .Net.
As we could not find a replacement for VS, we looked for a way to improve it. It seems that we were not the only ones with the same problem, and JetBrains tried to cash in on the ‘unhappy eclipse developer in .net world‘ market. They offer a plug-in for Visual Studio which makes it more Eclipse-user friendly, called Resharper – it’s not free, but not too expensive either (200 USD). It offers NUnit and NAnt integration, a decent set of refactorings, search and navigation improvements, and after testing the free version we decided to buy about twenty licenses. On the end, it turned out to be a sweet and sour mix – it significantly slows down Visual Studio, leaves crap files in the project source (even if you tell it five times to save it’s cache in system temporary folders), and reports false compile errors when a DLL project reference is removed. Some refactorings don’t work correctly, especially looking for interface references. Several of our developers have uninstalled it, since it has too many bugs. I still use it, because the basic Visual Studio refactoring set is just not enough for me to do my work, and I live with the false compile errors and take care when checking-in files into CVS, but I am far from happy.
For the build scripts, we decided to use both MSBuild and NAnt on the end. NAnt scripts are much more readable and maintainable, which is important for packaging, so we decided to keep using MSBuild for development, but use NAnt for packaging. Although that means doubling the effort to write build scripts, we have both the benefits of IDE-integrated build and flexible packaging.
For integration and acceptance testing, we use FitNesse. FitNesse .Net integration was a bit tricky to set up, and we had to hack the code to get it working with nullable types and correct a few other minor bugs, but it is now an indispensable tool for our project. It can test both Java and .Net code and cut through technological boundaries. Together with Selenium it can even test the system end-to-end – populating Web fields and submitting forms, then checking the results in the database.
Version control
The standard version control system in a .Net environment is Visual Source Safe. But that crap was never, as far as I am concerned, a proper version control system. It cannot recognise a modified file unless it was checked out, and works properly only on a LAN. Visual Studio 2005 has a new source control system, but that’s supported only in the Team Suite version, which the company did not have. Source off site solves the remote access problem for VSS, but this project has a mix of technologies and it was really important for us to have the version control working properly, and not get in the way, even without Visual Studio. Good-old CVS was installed on a Linux machine, but Visual Studio (of course), did not support that out of the box. We tried the Igloo Visual Studio plugin for CVS, but it simply did not live up to our expectations – it lacks support for some basics like visual notifications of changed files, and requires too much manual work. Tortoise CVS is an interesting solution for the problem – it is a free CVS plugin for Windows Explorer, which enables you to check files in and out of a CVS repository from the folder window. It has a few quirks, especially disconnecting and re-connecting to CVS for every folder, but it works good enough. Some developers actually use Eclipse even for the .Net source-code control. So, we still lack version control-IDE integration, but it’s the lesser of two evils.
Application framework
Comming from a Java-centric environment, my first stop were ports of ‘standard’ Java frameworks and libraries – Spring.Net and Log4Net. Spring.Net turned out to be, at least six months ago, just a glorified configuration engine. It lacked any notion of a proper MVC web framework, which was crucial to the project, and with all it’s dependencies, it was a bit too heavy for just an IoC configuration loader. We decided to use Spring.Net for dependency injection, and write our own MVC, but then it all fell apart under heavy load. Spring.Net depends on Log4Net, and Log4Net turned out to be a big risk – under initial stress testing, when the services crashed, we lost the last few log entries (which were, considering the situation, the only ones important). We spent some time trying to make it flush logs after each entry, without success, and just gave up. So using Log4Net, and with it Spring.Net, was out of the question – there was no point in having two log engines in the same project, and Spring.Net could not use anything else.
My next stop was Microsoft Enterprise Library, a collection of free add-ons to the .Net framework intended to provide standard services. Among the ‘application blocks’, which is Microsoft’s name for components, we found a proper logging engine. It performed OK under heavy load, and had an API similar to Log4J, so it was a serious candidate. Digging through the code we found that the Enterprise Library actually had an inversion of control engine (called Object Builder, later released on CodePlex), but it still left us without a good Web MVC system. We had some doubts about Object Builder license, but if the Enterprise Library had a good lightweight MVC, we would have probably used it.
Meanwhile, we experimented with some other logging frameworks, and NLog passed all our tests – in addition to performing well under heavy load, Log4J-like configuration and API, it also had a fairly flexible appender support (NLog calls them targets), and can add contextual information to log entries.
Then we found Castle Project, a lightweight application container intended to be a mix between Ruby’s flagship application Rails and Spring Framework. It has a good inversion of control engine, and a proper lightweight Web MVC. Castle is very open to integrations, so it can use NLog in addition to Log4Net out of the box. Although the framework is still a ‘release candidate’, it works stable and did not give us any problems. The configuration files are very similar to Spring, and Castle tries to resemble Spring in other areas, so the learning curve was quite short for us.
Castle’s Web MVC is configured partly in code and partly in external files – things like aspect-like filters and web folders, which Castle calls ‘areas’, are configured as class attributes rather than in configuration files – which significantly limits re-use of MVC controller code. I would really like to see this moved to external files, but other that that, Castle MVC works quite fine. It can use several rendering engines, including NVelocity, Web Forms and Brail (templates in Boo). It does not currently support XSLT, but has a pluggable rendering architecture, so I am still thinking about whether we should write that plug-in ourselves. Meanwhile, we use NVelocity with great success.
Rising stars
Many Java-to-.Net ports are still unstable or several years behind their older cousins in features. But, I am very happy with NAnt, NUnit, NLog and NVelocity, they seem to have reached the point of production quality. Better VS integration would benefit NAnt and NUnit very much, and I’d like to say that Resharper is the solution for that, but it simply introduces too much problems as it is. I hope that it will get cleaned up soon.
Sharp-Develop is on a good way to become a serious competitor, especially if Microsoft keeps unit testing and code coverage as exclusive features of the most expensive Visual Studio version. I would like to see better customisation, less formatting bugs, more refactorings and CVS integration in Sharp-Develop.
Castle Project is very interesting – and I expect to see it gaining more and more support. Some parts of it need to get cleaned up, and it needs better documentation, but it is quite usable even now.
FitNesse is also a rising star of .Net space – it is a bit tricky to set up for .Net testing and lacks good .Net-oriented documentation, but once it’s running and you get a feeling what it can do, it works like magic. (I wrote a short introduction to using FitNesse with .Net which might help if you decide to use that tool.)
My conclusion is that it’s often necessary to dig deeper in order to get the right .Net tools – and not just use the port of a popular Java tool. On the end, here are two good places to start digging: csharp-source.net and www.codeplex.com.
Image credits: Vierdrie/SXC, Jessics/SXC.
|
|
Do any specific requirements of your project affect your decision on library and tool selection?
Do you have concerns about Castle’s not ‘official supported’ by Microsoft?
What would happen if Castle becomes obsolete in 5 years, and you find yourself need to modify Castle to maintain your application?
I really like the tools and libraries you picked. I just cannot help but worry about these ‘enterprise-level’ questions. I guess it’s Microsoft that puts us in this difficult position when picking libraries other than those endorsed by Microsoft.
re specific requirements – we are building a server intended to support really heavy load, so having log4net fail under stress-testing affected the decision not to use that library for logging. As for castle, I’m used to utilising opensource tools, so official microsoft support does not mean anything to me – realistically, our application will also be obsolete in 5 years, and will be replaced with better technology by then. java is not endorsed by microsoft, like most enterprise libraries for java, and it still works quite fine.
Harry, what will happen if Apache Software Foundation loses interest in Open source? What will happen if Spring becomes obsolete due to lightweight nature of EJB 3.0? Those are all risks that one might face. For some reason the java camp is more willing to take these risks by selecting the best tools for the job. The MS camp just say amen to whatever MS makes available. This is starting to change, thanks goodness.
Castle has a company now that sponsors it, and due to its open source nature, everyone has its source code, so a modification is doable. Now what happens if you need to fix a bug on Microsoft WebForms infrastructure?
http://www.testdriven.net has an addin for visual studio that integrates nunit and ncover.
I also would give heavy consideration to CodeRush and Refactor Pro from DevExpress(they can be purchased as a set) which are much more robust and provide a great framework for continuing to extend Visual Studio.
What I wonder about more than what tools you are using is why is someone from the Java camp working on a .Net project? It would seem to me that you should try to use developers who are familiar with the tools and platform they will be developing on.
Thanks for very good insight!
However, i found your interest in CVS rather strange.
Given that SVN is built as a replacement for CVS.
From SVN site : The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community.
What’s more, SharpDevelop has an integrated SVN via Tortoise-SVN, which is very nice.
Darius
Hi Joe, thanks for the tip on CodeRuh and Refactor Pro, I will definitely look into that.
Well, sometimes experience with tools matters less than some other experiences.
Hi Darius,
thanks for the comment – I must admit that (wrongly) I have completely missed that one. CVS was always good enough for me. I know that subversion handles file moves better, and has other advantages, but somehow I never got to try it out. I plan to do that in the near future (but then again, I’ve been planning that for quite some time
)
Have you ever tried the CruiseControl.net? http://confluence.public.thoughtworks.org/display/CCNET
I think this works very well with .net tools ( nunit, ncover, fxcop etc ).
Subversion is a very good source code repository mechanism, and if you do decide to use it (you should at least give it a try!), you might also want to try VisualSVN which integrates into VisualStudio and utilizes Subversion repositories without having to switch out to Windows Explorer to use TortoiseSVN.
I also see that JGarza has already recommended http://www.testdriven.net, which not only integrates NUnit, but also NCover into your Visual Studio environment.
Third, Mini suggests CruiseControl.Net and CruiseControlTray, which can help you with Continuous Integration.
Finally, also look into WiX for packaging and deploying your application.
Another place to look at for tools is http://SharpToolbox.com
It should have all the tools you wish!
This is a fantastic post – good overviews of all the frameworks out there at the moment.
My 2 cents – Whenever I use TortoiseCVS or TortoiseSVN, Explorer tends to hang for a few seconds longer when I click on folders. I prefer separate clients for this reason (currently checking out SmartSVN).
I find DevExpress Refactor fairly useful, but CodeRush seems to be more of a pain than it’s really worth.
Chris
Don’t take this as a slam (I prefer Java as well) but it seems like you are acting like a tourist going to a foreign country and expecting it to work the same way as your own. That just aggravates everyone including yourself. Sometimes you have to do as the Romans do other times you don’t. Going MVC with .net totally throws away nearly all of the web development features in asp.net. That is one of the reasons Spring.net doesn’t have an mvc framework.
P.S. Sharpdevelop recently release 2.1 and it is getting to be a pretty good IDE. It is still rough around the edges in some places but it has come a long way since the 1.x days. Yes I know that by using it I’m giving up a lot of the VS2005 features but I still have to buck the MS trend here and there.
This is a excellent post, I ever read before. Very depth comparison has been given. almost every aspects have been covered. I like this too much.
One thing i want to mention here is that the comparison is good in ever aspect, but is should not go beyond the concept of origin of both .NET and Java. Both have their own specialty’s. e.g Java can be more productive for Enterprise development it is having plethora of tools and most of them belong to Open Source. .NET is still evolving in this arena, but need some more time come up with. They are in progress of developing Entity framework and Work flow foundation, moreover they have released Express edition of their every tool for beginners and learner at free of cost.
.NET excel in area of system integration. no other technology can provide that much robustness and flexibility if want to develop for MS platform. Even Java is not able to contact any hardware specific functionality, if someone don’t have knowledge of “C” and JNI. But in .NET you can program all MS API without any hassle.
So my perspective is that both technologies are having their one scope