Enterprise Accelerator: Versioning

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")]
Every time you generate a new release of your application, you’re going to want to increase these values.  We’ll set that up in a later post when we talk about Release Automation.

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!

To check out the other parts in this series:

  1. Enterprise Accelerator: What and Why?
  2. Enterprise Accelerator: Helix Solution Structure
  3. Enterprise Accelerator: Scaffolding Automation Strategies
Dylan McCurry

I am a certified Sitecore developer with a passion for the web. I hopped into the .NET space 5 years ago to work on enterprise-class applications and never looked back. I love building things—everything from from Legos to software that solves real problems. I have a strong foundation of backend skills, with sweet spots like security, portal solutions and APIs. Early on, before I had the benefit of SCORE, I made a lot of mistakes with Sitecore but learned a lot in the course of the struggle. I would like to support other developers by contributing my perspective on doing things “the Sitecore way,” rather than fighting the framework. Did I mention I love video games? More posts from Dylan McCurry.

Add a Comment

Your email address will not be published. Required fields are marked *

Or request call back