Skip to main content

Back-End Development

Enterprise Accelerator: Versioning

Two Runners@1x.jpg

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

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Dylan McCurry, Solutions Architect

I am a certified Sitecore developer, code monkey, and general nerd. I hopped into the .NET space 10 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. Did I mention I love video games?

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram