The article discusses a couple of new features introduced for assemblies and versioning in Visual Studio 2005.
1. Referencing an Executable
This feature helps the developer to reference an .EXE file from the code. Visual Studio 2005 allows developers to add a reference to both library and EXEs. This is used to access the class files which are inside an .EXE file.
In the below example, the client in the assembly named EXE 1 can consume Class D, which resides in the application assembly named EXE 2
2. Installing Executables to Global Assembly Cache
In Visual Studio 2003 you could not able to install application assemblies in GAC. In Visual Studio 2005 you can even add application assemblies to the GAC. You can install Exe to GAC.
3. Friend Assemblies
An interesting assembly-level attribute introduced by .NET 2.0 is the InternalsVisibleTo attribute, defined in the System.Runtime.CompilerServices namespace. The InternalsVisibleTo attribute allows you to expose internal types and methods to clients from another specified assembly. This is also known as declaring a friend assembly.
[Assembly: InternalsVisibleTo ("MyClient")]
4. Supplying Assembly Version Number
In Visual Studio 2003, you had to manually write the various assembly-level attributes, including the version number. Visual Studio 2005 provides visual editing of all the attributes commonly found in the Assembly Info file. Visual Studio 2005 will even auto-populate certain values such as company name and copyright statements based on the information found in the Registry as part of the Windows activation process.
To specify the version number using Visual Studio 2005, bring up the assembly properties and open the application tab. Next, click the "Assembly Information" button to display the Assembly Information dialog.
In old versions of .net, you had to create a strong name manually and you have to mention the file name in Assembly info.cs file. In visual studio 2005, it provides to sign the assembly and we can even protect with encryption keys in the visual studio environment.
In the project properties, select the "Signing" pane By checking the "Sign the assembly" checkbox, you instruct the compiler to sign the assembly with the key file specified.
The Choose a strong name key file combo box will allow you to either create a new key or to browse to an existing file. If you choose to create a new key, Visual Studio 2005 will launch the Create Strong Name Key dialog box shown in Figure.
![assembly4.gif]()
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 snk (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 that in the project settings. Whenever create if we sign the assembly for the strong name, Visual Studio 2005 creates and .pfx file adds to solution as shown in Figure.
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 to 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.