How do I get CC.NET automated build versionstamp written into Global Assembly Info file & referenced by several .NET apps?

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开发者_JAVA百科 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!

---

I was struggling with the same problem with CC.NET... I ended up ditching NANT and writing a custom CC.NET plugin that updates AssemblyInfo.cs for each project programatically. Implementing a CC.NET plugin is very simple.

using System.Collections.Generic; 
using System.IO; 
using Exortech.NetReflector; 
using ThoughtWorks.CruiseControl.Core;

namespace ccnet.AssemblyVersionUpdater.plugin {
[ReflectorType("assemblyRevisioner")]
  public class AssemblyRevisioner : ITask {
    public AssemblyRevisioner() {
    }

    [ReflectorProperty("rootFolder", Required = true)]
    public string RootFolder { get; set; }

    public void Run(IIntegrationResult result) {
        foreach (var file in GetAssemblyInfoFiles(RootFolder)) {
            var tmp = file + ".tmp";
            using (var sr = new StreamReader(file)) {
                using (var st = new StreamWriter(tmp)) {
                    string line;
                    var versionSet = false;
                    var fileVersionSet = false;
                    while ((line = sr.ReadLine()) != null) {
                        if (!versionSet && line.StartsWith("[assembly: AssemblyVersion(")) {
                            st.WriteLine("[assembly: AssemblyVersion(\"{0}\")]", result.Label);
                            versionSet = true;
                        } else {
                            if (!fileVersionSet && line.StartsWith("[assembly: AssemblyFileVersion(")) {
                                st.WriteLine("[assembly: AssemblyFileVersion(\"{0}\")]", result.Label);
                                fileVersionSet = true;
                            } else {
                                st.WriteLine(line);
                            }
                        }
                        st.Flush();
                    }
                    st.Close();
                }
                sr.Close();
            }
            File.SetAttributes(file, FileAttributes.Normal);
            File.Copy(tmp, file, true);
            File.Delete(tmp);
        }

    }

    private static IEnumerable<string> GetAssemblyInfoFiles(string b) {
        var result = new List<string>();
        var stack = new Stack<string>();
        stack.Push(b);
        while (stack.Count > 0) {
            var dir = stack.Pop();
            try {
                result.AddRange(Directory.GetFiles(dir, "AssemblyInfo.cs"));
                foreach (var dn in Directory.GetDirectories(dir)) {
                    stack.Push(dn);
                }
            } catch {
            }
        }
        return result;
    }

  } 
}

Compile the DLL and place it in the CruiseControl.NET\server folder. CC.NET needs to be restarted for the plugin to install. Then in the appropriate CC.NET config file:

<tasks>
   <assemblyRevisioner>
      <rootFolder>E:\Build\Source\Project1</rootFolder>
    </assemblyRevisioner>
     ...
</tasks>

This code edits AssemblyInfo.cs "in place" and replaces the version number with one from CC.NET before the project is built. I'm sure there are more elegant ways to increment the version number but this has been working fine for me.

---

1 - I would keep your local AssemblyInfo.cs files. Some of the attributes are (or may be) specific to each assembly, such as the Description and the COM Guid.

2 - Reference the GlobalAssemblyInfo.cs (in the root or wherever) from each project as you already described. Put the common attributes here such as the Product and Copyright. The build should pick up bits from both and will warn you if it found duplicates. If you use the asminfo task to generae GlobalAssemblyInfo.cs ant it writes a common AssemblyVersion value in here then all your projects will get that version number.

3 - Personally I like the build process to run regardless of whether its on the build server or just on a dev box. One reason being that it's nice to be able to test the build without kicking off an official build. Another being you might want to upgrade a major dependency (SQL Server version or whatever) and see if everything builds, again without actually upgrading the real build server.

4 - See answer 2

---

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();