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

Now that I've covered one way to structure your repo within and across systems, I'll cover what I usually do when first starting a solution. This includes project naming convention, build output directory, project properties and deployment project setup.

Lets first walk though where I place solution and project files. the below picture denotes where I place solution files (In the Source folder). The Source folder is the place where I put all of my solutions files. Depending on the system being written, it may make sense to have multiple solutions files, each grouping different projects uniquely. The folder structure matches my previous post on repo structure.

Project Layout

The next thing to note is that each of the project names match the assembly name as well as the default namespace. I like this convention because it lets you know which output comes from which project.

Another thing that I like to do is to treat warnings as errors. Usually if the compiler is warning you about something is with good reason...If there are warnings that I want ignored, then I usually use a pragma to turn specific warnings on/off.

The next thing I do is setup my assembly for signing. I no longer use the AssemblyKeyFile attribute because it has been deprecated and generates a warning. See this MS article for the details as to why this was deprecated; however, I think VS 2005/2008 does a horrible job of supporting this in the project properties tab. Every time you browse to the key file, it copies it locally! It does not support relative paths. So what I typically do is setup the key file reference through VS as shown below.

Then I unload the project and edit the project file's XML directly, and put the relative path, which point to the Builds\Certificates folder. Then when you reload the project you will see that the path is relative and you can delete the copy of the snk file that VS copied to the project folder.

Notice the AssemblyOriginatorKeyFile has been changed to the relative path...When you Reload the project, you can see that the relative path is now visible in the project properties window.

The last thing I do to get the projects ready to start work on is to get all the attributes setup. These are typically stored in the AssemblyInfo file which by default looks like the below screenshot.

There are quite of bit of attributes that are common throughout all of the projects in the solution, so I usually create a SolutionInfo.cs file to host these shared attributes. I also create a VersionInfo.cs file which is where the versioning information is stored. I separate the version information into a separate file because this is the file that my continuous integration environment will overwrite as it versions the builds. Of course things can't be too easy! To share those files across multiple projects, you have to make sure that you add them as a link; otherwise, VS will again make copies for you in each project. The below sequence of screenshots walks you through the process.

First create the two files and add them to the solution.

Once you've got the files in the solution, you can also add them to the project. This is where the tricky part come in because you have to make sure you add the files as Links (Drop down the Add button and you will see the option) otherwise VS will make copies instead of just reference the existing files...

Once you've done this, you will see the files added to the project. You can tell they were added as link since they will have the shortcut icon on the bottom left hand corder.

I then just move this files into the Properties folder so that they're alongside with the AssemblyInfo.cs file.

Once you've got the files in the right place, you can edit them. For example, the AssemblyInfo.cs file in the Bll project will look like:

The VersionInfo.cs fill will contain:

And finally, the SolutionInfo.cs file will contain:

This lets you share all of the common assembly attributes, get the version info ready for you continuous integration build to modify and keep the assembly specific attributes isolated.

Whew! Now will all that work done, you can start writing code! On the next post I'll talk about why I have both a .Web and .Web.UI project which you may have noticed in the above screenshots...

Hope this helps

Posted on Sunday, February 28, 2010 8:54 PM Solution Architecture | Back to top

Copyright © Carlos Santos | Powered by: