This post is about the reasons for such a move, and such reasons are incredibly basic to realize. Consider a platform other than Windows whether it be Linux, Windows Mobile, the Xbox 360 or even the Zune HD. Now think about how you would write a framework that supports some of (or all) these platforms and consider the problem of developing a class that implements something like INotifyCollectionChanged. The problem, of course, is that not all the platforms have access to WindowsBase.dll. Thus the developers come to a crossroads: either recreate the functionality for the platforms or don’t implement the functionality.

While that may not seem too unreasonable a dilemma, the problem is that Microsoft implemented functionality in a branched assembly that really has no dependency on any classes or interfaces within that assembly. Here the principle is simple: when possible, move functionality up the assembly hierarchy so as to reduce cross dependencies. In layman’s terms, by moving the INotifyCollectionChanged interface to System.dll, many more projects can take advantage of it without requiring any sort of platform dependent code. And here it is important to remember that one of the original goals of .NET was to enable true cross platform development.

To say that this case is the only one of its kind would be ignorant. The scary thing is that I don’t think anyone actually has a list of where these mistakes exist and what can be done about them. Even scarier than that is the fact that Microsoft is making these mistakes. Consider the following which further demonstrates this point.

While helping someone today with a few questions on the System.Reflection namespace, a point was made about how odd it is to compare generic types. When you have a generic class such as Nullable<T> you cannot do something as simple as if(foo is Nullable) because the generic parameter can make a difference. While this isn’t too much of a problem, Microsoft later also developed the System.Data assembly and included an interface called INullable within this assembly under the System.Data.SqlTypes namespace. This, like INotifyCollectionChanged, constricts the use of this interface to only assemblies that reference System.Data.dll. Furthermore, the interface contains a single boolean property and has not a single dependency on anything within the System.data assembly.

The problem and its solution should be obvious: move INullable to the System namespace in System.dll and make Nullable<T> implement it. This allows developers to easily check whether or not a type represents a nullable type while not creating a single problem in the entire framework’s design. Furthermore it would allow developers to treat System.Nullable and System.Data.SqlTypes.* as the same types which can come in handy.

Update: I added a suggestion on Connect for moving INullable to System.dll.

This is an important question and one that I can’t say I truly know the answer too. I had always assumed it was based on either the idea that System.* was part of the core framework where as Microsoft.* was for Microsoft specific functionality. For instance, it would be expected that much or all of the System.* functionality would be replicated on many other platforms where as Microsoft.* would not.

Certainly this is true for the very basic feature set such as the common types but it is not true for System.Windows.Forms. Which begs the question that I always wondered: why is Windows.Forms where it is? I always expected it to be in Microsoft.Windows.Forms as it is a Windows specific implementation based on many of the Win32 controls.

Note: You should not rely on this for accessing local data stores. Microsoft has done away with this method for a reason and relying on it in the future can cause problems.

The first thing we need to do is be able to get the Company Name from the assembly. Inside of a blank static class, add the following functions. I have named my class ApplicationExtensions.

Fortunately the company name is kept in an attribute:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public static string GetCompanyName(this Assembly assembly)
{
    string name = string.Empty;
 
    object[] attributes = assembly.GetCustomAttributes(typeof(AssemblyCompanyAttribute), true);
 
    if (attributes != null && attributes.Length > 0)
    {
        AssemblyCompanyAttribute aca = attributes[0] as AssemblyCompanyAttribute;
 
        if (aca != null)
        {
            name = aca.Company;
        }
    }
 
    return name;
}

Note my lack of any formal error handling. I will leave this up to you to handle. For now, returning an empty string will do. Next up, we need to be able to format the version number:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public static string GetFormattedVersion(this Assembly assembly)
{
    string version = string.Empty;
 
    try{
        Version assemblyVersion = assembly.GetName().Version;
 
        version = string.Format("{0}.{1}.{2}.{3}",
            assemblyVersion.Major,
            assemblyVersion.Minor,
            assemblyVersion.Build,
            assemblyVersion.Revision);
    }
    catch{}
 
    return version;
}

And finally, the LocalUserDataPath:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public static string GetLocalUserAppDataPath(this Application application)
{
    string path = string.Empty;
 
    Assembly assembly = Assembly.GetEntryAssembly();
 
    if (assembly != null)
    {
        path = Path.Combine(
            Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
            Path.Combine(
                Path.Combine(
                    assembly.GetCompanyName(),
                    assembly.GetName().Name),
                assembly.GetFormattedVersion()
                )
            );
    }
 
    return path;
}