The Anonymous Namespace Bug

 

Actively participating in the development of a static code analyzer such as NDepend is a good way to learn about tricky Common Type System (CTS) details. Every feature have to be tested properly to cop with things like managed and unsafe unmanaged pointer types (ref out and *), open/close generic types, generic parameter types, methods with special name (.ctor() .cctor() get_ set_ add_ remove_...), all sorts of arrays combination, virtual/new/override methods, explicit interface implemented methods, nested types, anonymous namespace... And of course, all this tricky points can be more or less combinated.

During our tests we found 2 bugs related to anonymous namespace. One in VSTS Coverage and one in the Visual Studio Code Model. Hopefully, the other CTS peculiarity seems to be bug free as far as our tests are concerned.

When the lightning strikes 2 times the same place, I suppose that this is not by chance: namespace are not first class citizen in the CTS. In other words, there are no metadata tables related to namespace in the metadata of an assembly. At IL level, namespace are just types names' prefixes. This lack of support for namespace certainly leads team responsible for these features to forget about testing these cases.

 

The Team Coverage Anonymous Namespace Bug

This bug occurs when there is a nested type in a type declared in an anonymous namespace. For example testing this piece of code.

using NUnit.Framework; namespace Namespace.Tests { [TestFixture] public class Test_ClassInAnonymousNamespace_NestedClass { [Test] public void MethodTest() { Assert.IsTrue(ClassInAnonymousNamespace.NestedClass.MethodTested(3,4) == 7); } } } class ClassInAnonymousNamespace { internal class NestedClass { internal static int MethodTested(int a, int b) { return a + b; } } }

.leads to the following Team Coverage XML. We can see that instead of having the class ClassInAnonymousNamespace.NestedClass declared inside the anonymous namespace, we have a class named .NestedClass declared in the ClassInAnonymousNamespace namespace.

<CoverageDSPriv> <Module> ... <NamespaceTable> ... <NamespaceName>ClassInAnonymousNamespace</NamespaceName> <Class> <ClassKeyName>AnonymousNamespaceBug1.dllClassInAnonymousNamespace.NestedClass</ClassKeyName> <ClassName>.NestedClass</ClassName> ...

 

The Visual Studio Code Model Anonymous Namespace Bug

This bug occurs with VB.NET, when you have a type declared in an anonymous namespace. For the VB.NET compiler, the anonymous namespace doesn't exist. Indeed, the VB.NET compiler makes it so that every type declared in an assembly are prefixed by the name of the assembly. I don't know the reason for such choice, but I hope there is a solid one because it is really not elegant. Update 24 July 2008:  This is a customizable VB.NET project setting: Application > Root Namespace.

Now consider the VisualStudio code model. As shown below, a VB.NET type declared in an anonymous namespace doesn't reference a namespace object. To see the assembly name namespace, one needs to analyze the delta between the FullName and the Name of the type.

 

Source Click Here.