Geeks With Blogs
Snowflake Design Because in Architecture the Answer is Usually "It Depends"

In my last post I either completely ommitted or glossed over some things. In this post, I'll cover the use of the versioning and resource attributes as well as how I layout my web application projects.

Versioning Attributes

You'll notice that I use three different attributes for denoting the version of an assembly: AssemblyVersion, AssemblyFileVersion, and AssemblyInformationalVersion. The first attribute, AssemblyVersion, should be very familiar to everyone as it is the one used to specify the version number that makes up part of the fully qualified assembly name. As you can see in the below screenshot of my GAC, System.Core's version is; however if you look at the properties of the System.Core.dll, you can see that there is an additional version #s listed.


These #s come from the AssemblyFileVersion and AssemblyInformationalVersion attributes and are a great way to keep track of which build assemblies came from.

You really want to avoid incrementing your AssemblyVersion attribute with every build, specially if you're strongly signing your assembly because if you did, that would force all of your clients to rebuild every time you do. Even MS will keep the version # of assemblies the same between .Net Framework service packs. Could you imagine having to redirect all of your applications every time a new service pack was released!

Combining the use of all three attributes lets you maintain your AssemblyVersion static while the AssemblyFileVersion and AssemblyInformationVersion attributes let you identify specifically which build a particular assembly came from.

Resource Attributes

The next thing I want to cover is the use of the NeutralResourcesLanguage attribute. This attribute is really about giving the .Net Framework a hint as to what your "Neutral" language is...You can read more about that in this article. To quote the article. "A direct consequence of the way the ResourceManager object looks for resources is that resources related to the default locale are located only after checking that no subdirectory for that culture exists. This means, for example, that all the resources for an application whose default culture is en-US are loaded only after checking that no en-US folder exists under the app's main directory. You can avoid this little overhead by applying the NeutralResourcesLanguage attribute to the main assembly to inform the resource manager about the language for the neutral resources that are embedded in the main assembly". 

Project Naming Convention

I touched on one naming convention in my last post, and that is to name the project the same as the assembly name. My other convention is to give unit test project the same name as the project it will be testing but just add the UnitTest suffix to it. You can see that in this screenshot:


In this same screenshot you can see that I name the Web Deployment project, the same as the Web Application project but just add the .Deployment suffix.

Web Project Code and UI Separation

You can also see above that I have both a BlackBeltSolutions.Sample.Web.UI project (A Web Application Project) as well as a BlackBeltSolutions.Sample.Web project (A Class Library Project). I prefer to separate the .aspx/.ascx, etc files that are the content to be deployed from the actual code. I do not go as far as putting the codebehind in the class lib project, just the presenter, view definitions (i.e. view interfaces), HttpModules, etc. Essentially anything that is not either a codebehind or content that is to be deployed is in the web app project and everything else in the class lib project. The reason for this is that I found if you mix the two, sometimes you want to create folders not because of content but to create a namespace. When you do this, mixing the content and code can be confusing. It also does force you to visibly see and think about the separation of the codebehind from the presenter/view definitions. Call me anal, but that's what I like...

Build Output

The next thing I want to cover is how I change the build output location. In a web application, I do two things. Have all the projects except for the Web.UI project build to the same directory. Really, the only reason I do this is to eliminate having multiple copies of each of the DLLs in each of the projects. For example, both the BLL and DAL project reference the BlackBeltSolutions.Sample project because that project would contain the model classes. If I leave the build output directory as the default, both the BLL and DAL projects would copy the BlackBeltSolutions.Sample DLL into their respective bin folders. This isn't so bad when it's a small solution but if you have a big one, you can end up with quite a bit of copies of DLLs all over the place. Below you can see that I change the output directory to

In the deployment project, I do something similar but instead of naming the folder SiteComponents, I name it after the name it after the website.

Then your BuildOutput directory will look like:

This also give you a well known place that you continuous integration build script can target when it needs to archive the build output.


I don't think I've left anything out...But if I did, there will be a part Trois (aka 3).

Hope this helps

Posted on Monday, March 1, 2010 6:56 PM | Back to top

Copyright © Carlos Santos | Powered by: