Skip to content

Temporary workaround for AssemblyKeyName and Visual Studio 15.6

Visual Studio 2017 version 15.6 currently has a problem if a project signs an assembly with the AssemblyKeyNameAttribute:

One suggested workaround is to add this line in the project file:

If you have many projects and don't want to include this in every project file, you can create a system-wide configuration for all projects. Create the file %LOCALAPPDATA%\Microsoft\MSBuild\15.0\Imports\Microsoft.Common.props\ImportAfter\Sign.props (the file name can be different, but it must be at that location) with this content:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="">

The workaround will be included in every build on that machine (for the current user account). Since I don't work on .NET Core projects, I don't know whether this breaks signed .NET Core builds.

Sharing a strong name key in a key container between multiple users on the same system

Today I imported a snk file to a key container as an Administrator and wanted to give another (non-admin) user access to that key container, so that he can sign assemblies with it.

I couldn’t find an easy solution. But I couldn’t believe that Microsoft doesn’t have a native tool for this and so I tried a solution, which is meant for ASP.NET: In a console I typed

aspnet_regiis.exe -pa <Key container name> <Username>

And it worked Smiley

.NET compatibility between .NET 4 and 4.5 with referenced assemblies

There aren't many breaking changes between .NET 4 and .NET 4.5, but after reading I was interested how the compatibility layer would react if the main assembly is compiled for .NET 4.5 and a referenced assembly for .NET 4.

I tested it with the List<T>.ForEach method in the blog post, and it acted like I thought it would: The main assembly specifies the compatibility level. If the main assembly is compiled for .NET 4.5, all referenced assemblies are also executed using .NET 4.5, even if they are compiled for .NET 4.

Disposable wrapper for WCF clients

When a WCF client calls a service and the call throws an exception (no FaultException, that's fine), then calling Close() or Dispose() on that client will throw another Exception because the client is in the faulted state. The correct way to "dispose" or cleanup a faulted client is to call Abort(). This means that we can't embed the WCF client in a using-statement because that will always dispose the client.

The correct way would be

ServiceClient myClient = new ServiceClient();
// error handling or throw;

Because some of my projects use a lot of WCF calls, this pattern is too tedious for me. Instead I wrote a simple wrapper:

using System;
using System.ServiceModel;

public class GenericProxy<T> : ClientBase<T>, IDisposable
where T : class
public GenericProxy()
: base()

void IDisposable.Dispose()
if (State == CommunicationState.Faulted)

public T Service
return Channel;

The only drawback is that instead of writing myClient.DoSomething() now I have to write myClient.Channel.DoSomething():

using (GenericProxy<IService> myClient = new GenericProxy<IService>())

Signing assemblies with a key container

This article is a reference for me since I have to look it up all the time.

Since .NET 1.0 I prefer to sign my assemblies and to use a key container with a AssemblyKeyNameAttribute instead of having to define the path of a key file in each assembly:

[assembly: AssemblyKeyName("myKeyName")]

Starting with .NET 2.0/Visual Studio 2005 this generates the compiler warning CS1699 (or an unnumbered warning for VB.NET). For my projects I always enable "Treat warnings as errors". For C# I can add 1699 to the suppressed warnings in the project settings, but I can't find a way to suppress the warning in the VB.NET project settings.

Instead I have to edit the .vbproj-file with a text editor and add somewhere in the first PropertyGroup element the line


Unfortunately Microsoft didn't add a project setting to use assembly key containers.

Getting Serendipity to work with Windows Live Writer

After installing the XML-RPC plug-in, I couldn't get Windows Live Writer to insert or update blog entries. After a week of trying and debugging I found out that the plug-in uses a boolean where serendipity expects a string.

In the file /plugins/serendipity_event_xmlrpc/ I just had to change line 1600 from

$entry['moderate_comments'] = serendipity_db_bool($serendipity['moderateCommentsDefault']);

$entry['moderate_comments'] = serendipity_db_bool($serendipity['moderateCommentsDefault']) ? 'true' : 'false';

Additionally I had to create the media directory "Windows-Live-Writer" in the Administration panel.

Funny, that my .NET blog starts with a PHP-related post Zwinkerndes Smiley