Brennan’s Blog

There has been some discussion on using third party assemblies after a post from Scott Hanselman called Some Guiding Principles for Software Development. One of the rules suggests that you should buy instead of build whenever you can while another rule suggests that you should limit the compile-time dependencies on code you do not own. In response to these guidelines the creator of BlogEngine.NET, Mads Kristensen, wrote Think twice before using any third-party assemblies that also encourages not using third party assemblies along with a list of sample scenarios. It appears that he avoids third party assemblies more aggressively than I do. I try to follow a few simple rules when considering a third party dependency.

• Can it be done easily with just the standard .NET Framework?
• Can I get the source code for the project?
• Does the project include sample projects as a reference?
• Is there sufficient documentation available to get started quickly?
• Is the project active with regularly planned releases?
• Is there any significant value in building it from scratch?

There are projects released by Microsoft that meet these requirements, such as the Enterprise Library and the ASP.NET AJAX Control Toolkit. What I like about these two projects is they are hosted on CodePlex and all of the source code is freely available. There is also plenty of documentation and working sample projects as a part of the installation that make it very easy to get started.

There are also other third party components I like to use because they provide functionality that is not in the .NET Framework: log4net and NUnit.

The log4net project has some great logging features that are easy to change with the configuration. It is true that you can get logging features from the System.Diagnostics namespace but it is not as flexible. With log4net I could have messages logged to a rolling text file with a limit of 5MB and later change that limit or completely reroute the messages to the Windows Event Log. It is just a matter of adjusting the configuration. It comes with the source code and a great deal of documentation with sample project.

NUnit is a unit testing framework. The .NET Framework does not yet provide free unit testing functionality. The xUnit framework that is a part of Team System which is still very costly. And even if you have Team System it requires you run Visual Studio to run the tests, which NUnit does not. So using this third party assembly gives me what I cannot get from Microsoft even if I pay for Team System. However this may all change when xUnit is updated for .NET 3.5. It may even become available freely with command-line functionality. I already know it is largely compatible with NUnit. Generally all you need to change is the using statement to adjust the imported namespace. It comes with the source code and a great deal of documentation with sample project.

But some third party components can be more trouble than they are worth. At work I am using a popular control suite that includes a large number of controls with a dizzying number of features. While I know the controls have been heavily tested and are widely used I have found it difficult to get my head around all of it. I can easily use the standard controls because they all work the same. These third party controls do not behave in same way so I cannot simply start using the controls without a good deal of trial and error. And since this control suite does not come with the source code I cannot find out why it does not work as expected or fix it.

There are motivations which will push you to use a third party component. For example, modern web development has forced matters to become much more complicated to the point that one developer or development team cannot handle all of the technologies without some help. Your concerns cannot simply be limited to coding in C#. A page is controlled by CSS and Javascript which is built on top of an HTML structure with carefully placed DIV tags with ID and CLASS attributes. And supporting these technologies across various browsers that do not perfectly interpret these standards-based technologies requires seasons skills in order to master them. Using third party components makes these technologies more approachable for the less experienced developer.

A few weeks back John Resig wrote about Advancing Javascript Libraries. His primary point was that the libraries can handle the cross-browser functionality while you get back to implementing the functionality you want to add to your application without being concerned with peculiar browser bugs.

John Resig created the jQuery library which is powerful in it's own regard, but there is now a whole respository of jQuery plugins built on top of the core library. Each plugin has to conform to the standards that are defined by the jQuery library, which essentially lines up with good object-oriented coding standards. These requirements help ensure these libraries are easily extensible. Building on top of third party libraries make some applications possible where it would otherwise be too time consuming or difficult to build.

What about BlogEngine.NET? Since a blog engine deals with commonly used technologies it should be easy enough to find components to handle most of the requirements. The RSS format and the MetaBlog API have been around long enough that a few projects should exist that could fill these needs. The ASP.NET RSS Toolkit hosted on CodePlex is one candidate project to handle these needs. (or RSS.NET) Since Kristensen has already built an elegant system that works there is now no need to consider third party components. But what if he wanted to give us choices?

For starters I would leverage the provider model. I can see from the code that he is already using it for the BlogProvider as a nice abstraction for the SQL Server and XML implementations. You could safely wrap functionality that is being provided by a third party component with such a provider abstraction so that you could provide multiple implementations along with the standard implementation. Generally the provider model is ideal for abstracting the data access layer so that you can have many implementation choices that are configurable.

But the provider model cannot do everything. One of the most complex interface elements of a web application is the editor. Offering comments or writing blog posts could be done with a regular TextBox with multiple rows just to get the job done, but you could also use a WYSIWYG editor to provide formatting features. BlogEngine.NET uses a Javascript solution called tinyMCE which could be swapped out with either FreeTextBox or FCKEditor. This does not appear to be something that is easily replaced, but if the editor was referenced in a User Control (~/Controls/Editor.ascx) it could be changed out pretty easily by exposing events and properties. I know that both of these WYSIWYG editors have been well tested so I could easily go with either of them. I could even choose to pay for the advanced functionality that a licensed installation offers on my website while the standard BlogEngine.NET can still remain a completely free project.

So I would not eliminate all third party components as a rule. I think they can often provide much needed functionality with little effort. But I agree with the sentiment of the rules that Hanselman and Kristensen follow. You should not start using third party components without sufficient planning. And while you are planning you should consider ways to extend or swap out your choices with easily available alternatives.