Question

I am currently “automating the build” of our .NET solution (which contains many projects, atleast 20. Some winForms, some web projects, all with different release configurations…ugh!). I am using CruiseControl.NET (or CC.NET, whatevs), and nANT. Plus, DOS and Powershell and a few other magic beans we do not need to go into 🙂

My goal is to produce a build label (which I already have semi-working btw). The build label consists of the Min/Maj number plus the SVN checkin number. This is fine for us and we are happy with it. I now need to get my .NET projects to reference the build number so that my QA team members know which build number they are testing against.

My version labelling nANT task looks like this:

<project name="updateassemblyversion" default="updateassemblyversion">
<target name="updateassemblyversion" description="generates the version number">
    <echo message="Setting the build version to ${CCNetLabel}..." />
    <attrib file="AssemblyInfo.cs" readonly="false" />
    <asminfo output="AssemblyInfo.cs" language="CSharp">
        <imports>
            <import namespace="System" />
            <import namespace="System.Reflection" />
        </imports>
        <attributes>
            <attribute type="AssemblyVersionAttribute" value="${CCNetLabel}" />
            <attribute type="AssemblyFileVersionAttribute" value="${CCNetLabel}" />
        </attributes>
    </asminfo>
    <attrib file="AssemblyInfo.cs" readonly="true" />
</target>

Anyways, I am attempting to set the assembly information on my build server. I have read that its not best practice to have 20+ AssemblyInfo.cs files to write to, so I have manually created a GlobalyAssemblyInfo.cs file, as a “Solution Item” which is linked to all my projects, via “Add…Existing Item…Add Link”. I do not think this is what I will need though since my versioning will occur on the build server…

It is fair to point out that my current working nANT task (exampled above) that I have been testing uses the correct versionstamp I need, but the task is incorrect for my scenario. It creates a NEW AssemblyInfo.cs file, and versionstamps it after the build is already compiled. I know that’s wrong, but It is essentially producing what I need, but I am unsure how to use it in my “build” script and in the order that I need. I know it should happen BEFORE the compile occurs, but how do I get the compile task to use the newly generated file? (see question #4).

Here is what I do not understand:

1. Do I keep my old 20+ AssemblyInfo.cs files? What is their
   purpose now? I wont need them, I do
   not believe. I probably shouldnt
   delete them from the Solution file,
   but they’re useless, right?
2. If I do use the generated GlobalAssemblyInfo.cs file, from my
   nANT task, how do I obtain a
   reference to it, and versionstamp it
   for my compile stuff?
3. Is creating the GlobalAssemblyInfo file manually (in
   my Solution), and referencing it
   from each project, invalid for my
   situation? I think I do not need
   these file references in my Solution
   and projects at all, I only need it
   on my build routine on my build
   server. I already produce an
   “AssemblyXYZ.cs” file (from nANT)
   with the correct version stamp.
   Shouldnt I just use that to compile
   all my projects with?
4. If #3 is true, how do I implement it in my CC.NET config
   file (or nANT goodness?). Basically,
   how do I tell the VS compiler to use
   my new GlobalAssemblyInfo.cs
   (generated by nANT) for all 20+ .NET
   projects in my solution?
5. How do I get my .NET projects to reference (internally) the newly
   generated, dynamic build
   number/versionstamp? I need QA to be
   able to see it in the application
   UI.

Once this is happening, I will be one happy auto builder 🙂
Cheers!

Answer 1

Here’s how I done it. It wasn’t easy but it wasn’t hard either. I think I had little faith in most of this, but luckily it was quite easy to implement.

Here is the final version of my nANT task, which I named “updateassemblyinfo.build”:

<?xml version="1.0"?>
<project name="updateassemblyversion" default="updateassemblyversion">
    <target name="updateassemblyversion" description="generates the version number">
        <echo message="Setting the build version to ${CCNetLabel}..." />
        <attrib file="AssemblyInfo.cs" readonly="false" />
        <asminfo output="C:\CruiseControl\ProjectFolders\MyBigBadSolution\GlobalAssemblyInfo.cs" language="CSharp">
            <imports>
                <import namespace="System" />
                <import namespace="System.Reflection" />
            </imports>
            <attributes>
                <attribute type="AssemblyVersionAttribute" value="${CCNetLabel}" />
                <attribute type="AssemblyFileVersionAttribute" value="${CCNetLabel}" />
            </attributes>
        </asminfo>
        <attrib file="GlobalAssemblyInfo.cs" readonly="true" />
    </target>
</project>

I ended up using the method illustrated by Yauheni Sivukha, here:
C# Project Global AssemblyInfo

^ One thing I should point out is that your project-level assembly attributes will conflict with your solution-level assembly attributes. Basically, you will have duplicate attributes and the compiler will throw an error. Simply remove the conflicting attributes from your project-level AssemblyInfo.cs file, and let the GlobalAssemblyInfo.cs file override them. Any project specifc attributes should be stored at the project level assembly info. Shared assembly info goes into the Global assembly file at the solution level. For someone completely new to this, it could be confusing.

In regards to my 5 bulleted “Here’s what I do not understand” questions, here are my answers:

1. Yes, you should keep all AssemblyInfo (project level) files. These store project-level assembly information. Some of these attributes may not be the same as other projects. It’s best to keep these with each specific project.
2. Using CruiseControl.NET and my nANT task, you simply use “asminfo” tag, and point the “output” element to the file-patth of the GlobalAssemblyInfo.cs file (the solution level assembly file).
3. No, it’s not invalid for this situation. Using a global assembly file (solution level) that is shared across multiple projects is very handy. Having successfully implemented this, I can see how it would be confusing to someone who has never dealt with it before.
4. I think it’s important to note the tag in ANT. It is for “Assembly Information”. Go figure.

5. Here is the one answer nobody else answered, which is pretty important:

   Assembly asm = Assembly.GetExecutingAssembly();
   this.Text = asm.GetName().Version.ToString();