Gojko Adzic

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.

Add to Del.Icio.Us bookmarks

Trackback URI | Comments RSS