Dependency Injection (DI) is a design pattern in Object Oriented Programming where the dependencies of a class are injected at runtime. These dependencies are mostly injected through a constructor (Constructor DI) or a property (Property DI). One of the main advantages of DI is it simplifies unit testing by allowing to inject mock dependencies in the place of real classes. In some cases we should have a default constructor in classes like in ASP.NET MVC controllers, WCF services etc. In WCF the service classes should have a default constructor else the framework will throw a runtime exception. To solve this problem developer ends up writing two constructors one is default and the other one is parameterized. The default constructor is used by the framework and the parameterized one is used by developers at the time of unit testing.

Although having two constructors suffice the job but we are violating the principles of dependency injection by instantiating the concrete classes in the default constructor. WCF is a highly extensible framework and fortunately it provides extension points even to customize the service instantiation. It looks like some of the DI containers simplify our job of customizing service instantiation by providing their own custom service host factories.

In this article we are going to see about the WCF extension point IInstanceProvider that allows us to customize the service instantiation and how the DI container Castle Windsor simplifies the task of creating services without default constructor through its new integration facilities.

Software development frequently involves doing a set of repeated actions in day-to-day life. If you take a web developer some of the activities he does frequently are building the web application and the referenced projects, running unit tests, generating documents, packaging the source files, copying the package to FTP server etc. Typically in big projects these activities occur numerous times. Many times developers end up doing these activities manually due to mostly lack of knowledge on automation and build tools. Build tools plays a crucial role in Continuous Integration where every time a developer checks-in his changes, a set of actions will take place automatically through build scripts to make sure the latest code won't create any build issues.

I recently started exploring NAnt when I was developing a couple of windows services for a client who asked me to write build scripts for those services. I was not much aware of automation and NAnt before so I thought these scripts are just going to help at the time of deployment to build the services without Visual Studio and to install them easily without much trouble. Soon I started to realise how much these scripts helps to save time and effort at the development phase. In this article I planned to explain how to take the advantages of build scripts while developing windows services.