Could not load type ‘System.Runtime.CompilerServices. ExtensionAttribute’ from assembly mscorlib when using ILMerge

Works On My Machine
Works On My Machine

I ran into a pretty horrible problem with ILMerge this week when attempting to build and deploy a windows service I’d been working on. While the merged executable & subsequently created MSI worked fine on my own machine, it gave the following rather nasty problem when run on a colleagues machine.


Could not load type ‘System.Runtime.CompilerServices.ExtensionAttribute’ from assembly mscorlib


It turns out that between .NET 4.0 & .NET 4.5; this attribute was moved from System.Core.dll to mscorlib.dll. While that sounds like a rather nasty breaking change in a framework version that is supposed to be 100% compatible, a [TypeForwardedTo] attribute is supposed to make this difference unobservable.

Unfortunately things breakwhen ILMerge is used to merge several assemblies into one. When I merge my .NET 4.0 app, with some other assemblies on the machine with .NET 4.5 installed, it sets the targetplatform for ILMerge to .NET 4.0. This in turn looks into C:\windows\Microsoft.NET\Framework\v4.0.30319 to find the relevant DLLs. But since .NET 4.5 is an in place upgrade, these have all been updated with their .NET 4.5 counter parts.

Breaking Changes
“Every well intended change has at least one failure mode that nobody thought of”

You need to specific that ILMerge should use the older .NET 4.0 reference assemblies which are still available in C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0. (or program files x86) if your on a 64-bit box). There’s more info on the stackoverflow question where I finally found a solution and in a linked blog post by Matt Wrock.


To override this behavior you need to specify this target platform directory as part of your ILMerge command. e.g.

    /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
I had previously been using the ILMerge.MSBuild.Tasks tool from nuget but unfortunately, this library doesn’t currently support specifying the TargetPlatform. There’s an unactioned open item on their issue tracker in google code.

Automatically update the AssemblyFileVersion attribute of a .NET Assembly

Automatic AssemblyFileVersion Updates
Automatic AssemblyFileVersion Updates

There is support in .NET for automatically incrementing the AssemblyVersion of a project by using the “.*” notation. e.g.
[assembly: AssemblyVersion("0.1.*")]

Unfortunately the same functionality isn’t available for the AssemblyFileVersion. Often times, I don’t want to bump the AssemblyVersion of an assembly as it will effect the strong name signature of the assembly, and perhaps the changes (a bug fix) isn’t significant enough to warrant it. However I do want to automatically increment the file version, so that in a deployed environment, I can right click the file and establish when the file was built & released.

[important]Enter the Update-AssemblyFileVersion.ps1 file.[/important]

This powershell script, (heavily borrowed from David J Wise’s article), runs as a pre-build command on a .NET Project. Simply point the command at an assembly info file, (or GlobalAssemblyInfo.cs if you’re following my suggested versioning tactics)  and ta-da, automatically updating AssemblyFileVersions.

The Build component of the version number will be set using the following formula based on a daycount since the year 2000.

# Build = (201X-2000)*366 + (1==>366)
    $build = [int32](((get-date).Year-2000)*366)+(Get-Date).DayOfYear

The Revision component of the version number will be using the following formula based on seconds in the current day.

# Revision = (1==>86400)/2 # .net standard
    $revision = [int32](((get-date)-(Get-Date).Date).TotalSeconds / 2)

The Major & Minor components are not set to update although they could be. Simply add the following command to your Pre-Build event and you’re all set.

    -File "C:\Path\To\Update-AssemblyFileVersion.ps1"  
    -assemblyInfoFilePath "$(SolutionDir)\Project\Properties\AssemblyInfo.cs"

~Eoin C

Combinatorics in .NET – Part II – Creating a Nuget Package
[important] This is part 2 of a 2 part post on Combinatorics in .Net

The solution is publicly available on github;

The library can be added to any .NET Soution via Nuget;

In the last post we looked at the Combinatorics Library, a .NET Assembly which provides Combinatoric generation capabilities to your .NET Applications. Now lets look at bundling up that solution & deploying the package to Nuget. Nuget is an online .NET Package Repository & associated Visual Studio extension that makes it easy to manage external assemblies in your projects. Developers who build 3rd party libraries or tools can create a NuGet package and store the package in a NuGet repository. Other developers can then browse the repository (online or with Visual Studio) and add references to those 3rd party tools & libraries.

You can read more about Nuget here.

Read More “Combinatorics in .NET – Part II – Creating a Nuget Package”

Version 1.0

Global Assembly Versioning Strategy & Development Workflows for .NET Assemblies

Version 1.0Over the past few weeks I’ve been working on a new project in our company which involved building a number of inter-dependent assemblies, “strongly naming” them and installing them into the Global Assembly Cache. Over the course of the project, I was forced to look at a number of issues related to assembly versions, solution organisation and the deployment of assesmblies in a developer environment.

So given that it’s been a while since I wrote anything vaguely technical, I thought I’d document some of these issues down.

  • What version numbering strategy should we use?
  • How will we organise our Solution to make this easily manageable?
  • How will we manage these libraries during the deployment phase?
  • How will we circulate stable versions to developers during on-going development of other projects?
  • How will we release these libraries to customers?
[notice]TL;DR – Take a look at the VersioningDemo Solution on GitHub[/notice]

Read More “Global Assembly Versioning Strategy & Development Workflows for .NET Assemblies”