Share "source" files between projects.

Posted: Monday, November 17, 2003 3:14 PM by Barry Gervin
Filed under: , , ,

By default, each project in your solution has an AssemblyInfo.??. Amongst other things, it contains an AssemblyInfo attribute that will end up stamping the dll or exe with it's version number. This is the version number used by the CLR to make sure that when you reference a dll - it finds the correct version.

In a solution comprised of many projects, you may want them all to share the same build number. By default, VS.NET sets this version to 1.0.* -- * meaning that it will increment the number. Sometimes you build just one project, sometimes all of the projects in a solution. Some developers may even have their own solution files to just work on a subset of the projects in the master solution.

What I'm saying here is that you really ought to take better care (and control) of this version number. It would be nice to have all of your dll's in the solution share the same assembly version. Sure you can hard code it, but manually incrementing it then becomes tedious. The secret to this tip is that the AssemblyVersion attribute doesn't have to be in the AssemblyInfo.?? file. It can be in it's own file. In fact, that file doesn't have to even physically exist in the same subdirectory as the project thanks to “Linked“ files.

So follow these steps.

  1. Remove the “AssemblyVersion“ attributes from the AssemblyInfo in each of your projects.
  2. Create a “VersionInfo.cs“ (or .vb) in the root of your solution - probably one level up from your projects. It should include an AssemblyVersion attribute like the one you took out of each of your AssemblyInfo files. It should also include a using System.Reflection since that is the required namespace.
  3. In each of your projects make a shortcut or link reference to this new file. To do this, right click on each project and select “Add Existing Item“. Browse to the VersionInfo.cs (or .vb) file and instead of clicking “Open“ select “Link“ from the drop down on the open button in the File Open Dialog.

Now you have only one place to increment the version for your entire solution. If you are using NAnt, you can have it do this for you with this simple task:

 

<version path="VersionInfo.txt" startDate="2003-10-1" buildType="monthday" prefix="assembly." />

<asminfo output="VersionInfo.cs" language="CSharp">

<imports>

<import name="System" />

<import name="System.Reflection"/>

</imports>

<attributes>

<attribute type="AssemblyVersionAttribute" value="${assembly.version}" />

</attributes>

</asminfo>

The first version task increments the build number and stores it in both the assembly.version variable and also the VersionInfo.txt file. The second task recreates a new AssemblyInfo file and uses the assembly.version variable.

Comments

Barry Gervin

November 20, 2003 2:09 PM
Of course you can't link a file into a web project. Argh.

Barry Gervin

December 30, 2003 10:09 AM
I share your frustration on the web project issue. But, for regular projects in the same solution I also use the same strong name key file, what do you suggest for this ?

Barry Gervin

February 10, 2004 1:45 PM
Hopefully I'm understanding your question. There is no need for the snk file to be part of the solution or project. So the file can be sitting on a local path (or better yet on a secured lan drive) and referenced by the full path in your AssemblyInfo file on the KeyFilename attribute as you would normally.

Barry Gervin

April 2, 2004 9:23 AM
Do you have a solution for the web project?

Barry Gervin

April 5, 2004 1:32 AM
I typically do have a solution for a web project. I would typically have my data access classes in a separate binary - hence separate class library project. Possibly the same for business components. So kind of makes sense you have a "Solution" file for a entire "Solution" - for just the web project? That's just part of the solution in my book.

Barry Gervin

September 26, 2005 7:23 PM
Can you complete the answer?

How do you make a different binary for web projects

New Comments to this post are disabled

Search

Syndication

Barry Gervin