So, I am a big fan of putting build numbers or SVN revisions into the AssemblyFileVersion of my assemblies. I can then use a little bit of the System.Reflection API to get the AssemblyFileVersion, and display it to the user, write it to logs, etc..
However, I ran into a hitch when working with Office 365. Although reflection worked fine on my local machine’s sandbox, I got an error when I tried to run the same code on Office 365’s SharePoint system. It was pretty obviously and emphatically using System.Reflection that was the problem.
This was a shame, as my build process is (as usual) putting the AssemblyFileVersion in. Sadly, I don’t see any easy way to get the AssemblyFileVersion value from within Office 365 code. So, alternatives?
Well, my answer was a little … primitive. I added a CONST to my code:
const string SOLUTION_VERSION = "Development";
And I modified my build process to do a regex replace of that line in my code file during the build. I’d already written a build activity that would do a “regex find and replace in files”, so this was pretty simple to do.
The hard part, however, was deciding what the replacement pattern should be. The build process doesn’t seem to have any easy to use variables (our build processes are largely based on TFS Versioning on CodePlex).
(Note – from here on things get a little specific to what we use)
So, I chosed to the replacement pattern:
[vbnet]String.Format("string SOLUTION_VERSION = ""{0}.{1}"";",
Regex.Replace(AssemblyFileVersionPattern, ".[^.]+.[^.]+$", ""),
Regex.Replace(LabelName, "^.*_", ""))[/vbnet]
The first regex cuts the tail two elements off the AssemblyFileVersionPattern for our build, which is a variable we do have. By convention, in our build process, the front two elements are always numbers, and are manually altered when we move between versions.
The second regex cuts off the start of the build name. Our build name ends with the year and day of year, and the build revision for that day, just like our AssemblyFileVersion. Thus, the result of that regex is the tail two elements of our AssemblyFileVersion.
This results in a number of the form 1.2.12345.6 which is then inserted into our constant during the build process.
(Told you that the solution was a little bit specific to our process)