A lot of people have asked me why we don't use third-party assemblies in BlogEngine.NET, so I thought it was about time to explain why. 

One of the most important rules that I laid down before starting on the BlogEngine.NET project, was that no third-party assemblies were allowed. This rule was forged out of the assumption that most of these assemblies did a whole lot when only a little bit was needed for BlogEngine.NET, and that little bit was easy to write our selves.

It’s obvious that it would take longer to write the code instead of just referencing the assemblies, but it was worth the extra effort. BlogEngine.NET is build for .NET developers so my initial thought was that they wanted to be able to change every little thing they wanted to suit their needs. Third-party, precompiled assemblies doesn’t allow for easy customization so that would counter the .NET developers needs. That has a big part in why BlogEngine.NET is so open and simple to customize

If you look at most other .NET blog and CMS platforms in existence today, you’ll see that they make heavy use of various third-party assemblies. All of the assemblies and libraries are open source or at least free of charge and they are all very powerful and easy to use. However, the decision has been made so we had to come up with alternatives to the libraries and that proved surprisingly effortless for our simple needs.

What we didn’t use

Web control libraries
There are many web control libraries that offer date-time pickers, special grids etc. that we could have used, but let’s face it. A date-time picker is just a JavaScript representation of the already existing ASP.NET Calendar control with some AJAX functionality. Other controls can be much harder to write yourself but we didn’t need them.

It’s a very cool library for handling trackbacks and pingbacks and pinging Technorati, Feedburner etc. when new posts are created. It does much more than that, but these features were the ones we needed. XML-RPC is standard XML that can be parsed and XPath’ed so why did we need a third-party library for handling XML?

Rich text editor
I’m a big fan of both FreeTextBox and FCKeditor which I’ve used in many projects over the years. They each have their advantages and can be extended and modified fairly easy. So can tinyMCE and it is purely JavaScript, so that’s what we decided to use. There were other reasons as well, such as almost perfect XHTML generation and other minor factors. Well, and of course the fact that it’s JavaScript so we can change whatever we want.

HTTP compression
There are quite a few compression libraries that can gzip or deflate the HTTP response stream. Instead we used the build in compression classes in the CLR and wrote a single HttpModule to do the job.

CAPTCHA controls
There exists hundreds of CAPTCHA control libraries for ASP.NET both visible and invisible ones. However, a CAPTCHA is one of the simplest things to write – it takes only 20 lines of code to create a rock solid invisible one – so that’s what we did.

As you can see, we did a lot of reinventing for BlogEngine.NET, but it actually wasn’t that big a deal.

In the enterprise

For enterprise projects where third-party dependencies can be costly, it would be beneficial to be sure what the needs are and if they can be built instead of bought. You should also weigh the value of owning the code instead of using third-parties. It various from project to project and from library to library, but one thing remain the same: third-party dependencies is not as flexible as building your own implementations.

The hobby project

Most hobby projects start when you get an idea and want to realize it real quick. Then you don’t want to do much reinventing because that would just slow you down and your code is probably not essential either. In those cases I would use as many third-party libraries as possible to get the code running and my project realized.

Think twice

There are many factors to consider before using third-party libraries and some demands real thought. You have to be real careful about using third-party libraries for essential components, because then you loose control of the most important parts of your application. For BlogEngine.NET we also had to consider our target group - the developers.

If you base your business/application on a component provided by third-party, you might want to think twice.