Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

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…

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


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.


This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.NDepend.com Patrick Smacchia

    Thanks for the info Ayende, indeed it is in the VB.NET properties.

    However this doesn’t changethe fact that there is a bug in Code Model: in the example, the name of the assembly should be considered as a namespace of the type.

  • http://www.ayende.com/Blog/ Ayende Rahien

    This is not a VB bug. This is the expected behavior.
    Check the project properties, it is defined there.