Introduction
Remember when I said I love me some automation? Well, versioning is a prerequisite to pull off more automation. I want to show you how truly simple it is to set up when working with Brainjocks SCORE. If you’re not using SCORE, the ideas behind this post are still the same, but you’ll have to implement it a bit differently. Let’s get started!
Versioning in .NET
Versioning of a .dll in .NET is done through the AssemblyInfo.cs file, which is a part of the project’s properties. There’s a ton of documentation on the web about how this file works, so I don’t want to get too “in the weeds” of it.
What you need to know is that there are a few lines within this file that contain your assembly version:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
Versioning in SCORE
When you’re working in the SCORE paradigm, the SCORE runtime version is output from these controllers:
- /score/about/version
- /scoreui/about/version
- /scorebootstrapui/about/version
You can see an example of this on brainjocks.com right now: https://www.brainjocks.com/score/about/version
SCORE outputs this as JSON. We do that because JSON is easy to consume programmatically … which will feed further into our automation strategies.
Versioning in your Enterprise Accelerator
As it turns out, you can output version information similar to SCORE by simply inheriting from its controller and changing a few properties around. Here’s how!
First, create a controller that looks like this:
namespace Enterprise.Configuration.Areas.Enterprise.Controllers
{
public class AboutController : Score.Web.Areas.Score.Controllers.AboutController
{
public AboutController()
{
}
public override string TargetSitecoreVersion
{
get
{
// replace with your specific version, or a token that is replaced by DevOps processes
return return "8.2.171121";
}
}
public override List<string> Assemblies
{
get
{
return FindEnterpriseAssemblies().ToList();
}
}
// returns all .dll files that begin with 'Acme' in the current executing application
private IEnumerable<string> FindEnterpriseAssemblies()
{
var binDirectory = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin");
// Find all DLLs that are Acme.*.dll
var dlls = Directory.GetFiles(binDirectory)
.Where(x =>
!string.IsNullOrEmpty(x)
&& Path.GetFileName(x).EndsWith(".dll")
&& Path.GetFileName(x).StartsWith("Acme"))
.Select(Path.GetFileNameWithoutExtension);
return dlls;
}
}
}
Where would you put this in your helix layer? In my opinion, this is part of that Configuration project that we introduced when talking about the Helix Solution Structure, but it could arguably live in a few places.
Also, you must map this controller route accordingly:
public class EnterpriseAreaRegistration : AreaRegistration
{
context.MapRoute(
"Acme_about",
"acme/about/version",
new { controller = "About", action = "Version" },
new[] { "Enterprise.Configuration.Areas.Enterprise.Controllers" }
);
}
This controller is quite simple. Basically, the SCORE controller assumes that it can get a list of all DLLs which need their assembly info inspected via a call to the List<string> Assemblies property. If we inherit from this controller and overwrite that property, then the /about/version method that is inherited will find the version for your assemblies as defined by the Assemblies list. In this case, I threw some extra sugar on top to have the list of Assemblies be any assembly found within the bin folder that begins with my enterprise’s name (e.g., Acme). In following this pattern, I can adjust my custom scaffolding to inject the word Acme for each tenant’s DLLs. Then, a call to this controller endpoint (e.g., www.mysite.com/acme/about/version) would spit out the version of all DLLs from my organization in one swoop.
Now that we’ve got versioning established, let’s move on to some DevOps!
