How does CompilationRelaxations.NoStringInterning actually work?

Question

I am having problems demonstrating NoStringInterning

[assembly: System.Runtime.CompilerServices.CompilationRelaxations(System.Runtime.CompilerServices.CompilationRelaxations.NoStringInterning)]

    class Program
    {
        static void Main(string[] args)
        {
            String s1 = "Friday";
            String s2 = "Friday";
            String s3 = "Friday";
            String s4 = "Friday";
            String s5 = "Friday";
            String s6 = "Friday";
            String s7 = "Friday";
            String s8 = "Friday";
            String s9 = "Friday";
            // etc...
            Console.WriteLine(Object.ReferenceEquals(s1, s2));
            Console.WriteLine(Object.ReferenceEquals(s1, s3));
            Console.WriteLine(Object.ReferenceEquals(s1, s4));
            Console.WriteLine(Object.ReferenceEquals(s1, s5));
            Console.WriteLine(Object.ReferenceEquals(s1, s6));
            Console.WriteLine(Object.ReferenceEquals(s1, s7));
            Console.WriteLine(Object.ReferenceEquals(s1, s8));
            Console.WriteLine(Object.ReferenceEquals(s1, s9));
            // etc...

I've tried with .NET CLR 2, 3, 4.. as output all I get is a bunch of True. I am expecting a bunch of False!

Answer 1

The documentation states that the attribute:

Marks an assembly as not requiring string-literal interning.

In other words, it does not prevent the compiler from doing string interning, just providing a hint that it is not required. The documentation is a little bit sparse in this area, but this also seems to be the conclusion in this MSDN forum post.

Answer 2

Not kick in an opened door, but clearly the attribute doesn't do what you think it does. Documentation for it is quite poor, both in MSDN and the CLI spec. The only thing that's obvious to me from its usage inside the CLR is that, when it is turned on, the compiler only has to ensure that identical strings are interned at the module level. This has a number of side effects that are relevant for inlining, ngen-ed and mixed-mode assemblies.

That would next force me explain the exact difference between modules and assemblies. Which I can't, modules are strange beasts that have no practical usage in common .NET programming. Best to forget that this attribute is relevant at all. Unless you have a custom build system that runs the C# compiler with the /target:module option, the C# compiler always interns at the assembly level so your test will always produce "true".