Enhancements in Assemblies and Versioning in Visual Studio

[assembly: InternalsVisibleTo("MyClient")]

We can generate a strong name in plain and password-protected. If you uncheck the Protect My Key file with a password checkbox, Visual Studio 2005 will generate a file with the name specified and with the sink (Strong Name Key) extension. Visual Studio 2005 will generate a file with the name specified and with the pfx (Personal Information Exchange) extension. The pfx file is more secure because whenever another user tries to use the file, that user will be prompted for the password. The other advantage of a pfx file is that you can add it to a certificate container (see the sidebar Protecting Your Keys). If instead of creating a new key file you would like to browse for an existing key, Visual Studio 2005 will bring up a dialog letting you browse for either .snk or .pfx files. Once you have selected a file, Visual Studio 2005 will copy that file to the project folder. In addition, unlike Visual Studio 2003, Visual Studio 2005 does not use attributes for storing the key file name. Instead, it persists in the project settings. Whenever create if we sign the assembly for the strong name, Visual Studio 2005 creates and .pfx file added to the solution as shown in Figure.

Extern alias Keyword

In .NET 2.0, by default, all types are rooted in a namespace called global. You don't need to explicitly use the global namespace since it is always implied by default. The global namespace is instrumental in resolving type name conflicts, especially when multiple assemblies are involved.

When you add an assembly reference, it is possible to create a conflict with another type already defined by your application in another assembly it references. For example, consider the MyApplication.exe and MyLibrary.dll assemblies, which both define the class My Class in the namespace, My Namespace.

// In MyApplication.exe
namespace MyNamespace
{
    public class MyClass
    {
        //...
    }
}

// In MyLibrary.dll
namespace MyNamespace
{
    public class MyClass
    {
        //...
    }
}

Each definition of MyClass is completely distinct, providing different methods and behaviors. If you add a reference to MyLibrary.dll from within MyApplication.exe, when you try to use the type MyClass like so.

using MyNamespace;

MyClass obj = new MyClass();

The compiler will issue an error because it does not know how to resolve it that is; it doesn't know which definition of MyClass to reference.

C# 2.0 allows you to resolve type name conflicts by aliasing the assembly reference. To alias an assembly, first, add a reference to it in Visual Studio 2005. Next, expand the Reference folder in the Solution Explorer, and display the properties of the referenced assembly.

If you added the reference by browsing the assembly, the Aliases property will be set explicitly to global.

Next, add as the first line of the file the extern alias directive, instructing the compiler to include the types from the alias in the search path.

extern alias MyLibraryAlias;

You can now refer to the class MyClass from MyLibrary.dll.

MyLibraryAlias::MyNamespace.MyClass obj;
obj = new MyLibraryAlias::MyNamespace.MyClass();

Note that the extern alias directive must appear before any using directives and that all types in the MyLibrary.dll can only be referred to via the alias because these types are not imported to the global scope.

Using aliases and fully qualified namespaces may result in exceedingly long lines. As a shorthand, you can also alias the fully qualified name.

using MyLibrary = MyLibraryAlias::MyNamespace;

MyLibrary.MyClass obj;
obj = new MyLibrary.MyClass();

Summary

In this article, I discussed some new features introduced for assemblies and versioning in .NET 2.0 and Visual Studio 2005.