The Tyranny of .NET Namespaces

This is not a rant about the .NET framework, in fact for the most part I think the .NE framework is a very well structured set of libraries for building a variety of different solutions. This is a rant about how namespaces have been inappropriately applied to other project types (projects that don’t contain .NET code) within Visual Studio.


I’ve always been a little bit obsessive compulsive about naming conventions myself. In fact over the years I’ve adopted, junked and re-adopted a number of different conventions for naming the projects within a Visual Studio solution. I’m not 100% sure why, but I think that it may be down to the number of times I’ve played the build master role on a team and had to get other peoples code building and understand what they are actually expecting as outputs.

A Scenario

Given the following problem, how would you lay out your solution structure? A web-based application, a common library that it uses containing injected dependencies, a silverlight component, embedded within the web-site, a set of PowerShell automation libraries for system administrators managing the site, a setup package to deploy the site onto a customer server, and a desktop client, probably using Windows Presentation Foundation.

If I asked ten different people to describe their solution in terms of project names I’d probably get ten different answers, a lot would be similar, but none would be exactly the same.

My Approach (before today)

As I said earlier, in the past I’ve adopted, junked and re-adopted various conventions. The one that I’ve been using for the last year or so is as follows:

  • Product (solution)
    • Company.Product (common library)
    • Company.Product.Management.Automation (PowerShell snap-in)
    • ProductWeb (ASP.NET web-project)
    • ProductClient (WPF application)
    • ProductWebMedia (example of a Silverlight component)
    • ProductClientSetup (WiX setup project)
    • ProductWebSetup (WiX setup project)

That is pretty much it, a very minimal structure. But why did I switch from a namespace type notation for projects and then to a non namespace type notation (e.g. ProductWeb vs. Company.Product).

I’ve never had a really good answer but my general response was that the non-namespaced projects really represented discrete entry points for a user experience for the software (as if that was a good enough justification).

My Approach (post today)

I’m on the cusp of changing my approach, but not massively, it is a subtle refinement. This is probably how I’d do that same project today.

  • Product (solution)
    • Company.Product (common library)
    • Company.Product.Management.Automation (PowerShell snap-in)
    • Company.Product.Web (ASP.NET web-project)
    • Company.Product.DesktopClient (WPF application)
    • Company.Product.MediaComponent (example of a Silverlight component)
    • ProductClientSetup (WiX setup project)
    • ProductWebSetup(WiX setup project)

All I’ve done is made sure anytime my project contains predominantly .NET code then I’m going to use a namespaced approach. This falls into line with what a lot of people do already (yay) but I’ve stopped short of renaming the setup packages. And this is where I get onto the topic of the post – The Tyranny of .NET Namespaces.

What should you namespace?

Well in .NET terms naming the project inside Visual Studio doesn’t necessarily mean that the output of that project aligns with the project name, it just does by convention – that’s all!

You should consider using a namespace-style project name when your project really does produce an assembly as output. For example an ASP.NET project does ultimately produce an assembly (and a bunch of loose files). A WiX setup does not produce a .NET assembly – it produces an MSI and in general there is no convention around naming setup projects (with perhaps the exception of appending the word Setup to the end of the name).

So my convention is that if the project really contains .NET code then use the namespacing convention for projects – if not, use whatever convention makes sense for that particular project time.

My 2c Smile


2 thoughts on “The Tyranny of .NET Namespaces

  1. Pingback: The Tyranny of .NET Namespaces (cont’d) « notgartner

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s