Assembly-GUID.cs

using System;
using System.Reflection;
using System.Runtime.InteropServices;

[assembly:Guid("11111111-2222-3333-4444-555555555555")]

namespace GUID_Test
{
    class Program
    {
        static void Main(string[] args)
        {
            var wrong = string.Format(@"Global\{0}", Assembly.GetExecutingAssembly().GetType().GUID);
            Console.WriteLine("Wrong: " + wrong);

            var right = string.Format(@"Global\{0}", Assembly.GetExecutingAssembly().GetCustomAttribute<GuidAttribute>().Value);
            Console.WriteLine("Right: " + right);
        }
    }
}

This gist is an attempt show that the bug highlighted in this Twitter thread about incorrectly retrieving the GUID for their application could have been found with a simple unit test as the GUID is controlled by the application team and therefore they can assert the generated mutex string because they control what should be produced if the code was correct.

The output from running this example code is:

Wrong: Global\02639d71-0935-35e8-9d1b-9dd1a2a34627
Right: Global\11111111-2222-3333-4444-555555555555

An alternate approach if the testing team can't write a unit test would be to write a simple console application like above and use a hard-coded mutex string based on what the GUID is by reflection on the assembly - to test the observable behaviour. The app should start by default and then when the test harness is run it should block the application start-up. If the app doesn't start by default or starts when it shouldn't the likelihood is a bug with the mutex name. A tool like Sysinternals' Handle or ProcessExplorer can show what mutex is created by an application and I think Process Monitor may show if an application attempts to create a global one.

Note: this is entirely predicated on the assumption that someone is interested in validating this feature.