In the bad old days of COM, shared components were usually dumped into that unorganized Windows warehouse, the System directory, and then "registered" in Windows so other programs could locate them. This is a big reason why the registry is such a critical and sensitive part of Windows. Without it, one piece of software can't locate another one. (The registry is still used in .NET, by the way. But .NET doesn't use it to identify components anymore.) In .NET, every assembly starts with something called a manifest that takes the place of the information that was formerly placed in the registry. The manifest contains metadata (data about data) telling the CLR what it needs to know to execute the assembly instructions.
One of the things the CLR needs to know is the version number of components used by the assembly. To illustrate the point, let's compare the manifest of a very simple 1.1 and 2.0 .NET component (DLL file) using the ILDASM utility. This is a standard tool that is installed with the .NET Framework and it lets you look inside the IL code in an assembly. (In the article, The .NET Framework Tools - Introduction and ILDASM, I recommend that you use the Framework supplied SDKVARS command program. Note that Framework 2.0 has a new version of both the SDKVARS command program and the ILDASM utility. If you have upgraded to Visual Basic 2.0 from 1.1, make sure you are using the right one.)
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
The illustration demonstrates that the two programs call for entirely different versions of the core .NET component libraries such as mscorlib, Microsoft.VisualBasic, and System. And everything is verified by passing an encryption key token to prevent unauthorized changes. If you create a component of your own and reference it, exactly the same versioning and security will guarantee that the right component is used. This is why you can run several versions of .NET and the COM based Visual Studio 6 side-by-side with never a problem. Each version uses only the components programmed and tested with it. You can run your own versions of identically named programs side-by-side just as easily.
Visual Basic .NET gets the information necessary for the assembly manifest from the AssemblyInfo.vb file in your project. To check out the contents of AssemblyInfo.vb, click the Show All Files button in Solution Explorer and then select View Code for AssemblyInfo.vb under your project. (VB 1.0/1.1 show all files by default.) You can change the information here, or in the Assembly Information dialog under the Project > Properties menu selection in Visual Studio 2005. Click the Assembly Information button. This is also the same information you see when you right-click an executable file under Windows and select properties.
One reason that COM dumped everything into the Windows system directory was to make a single copy available to any program that needed it. This works for components that are used by a lot of different programs (unless you run into the problem of incompatible versions, DLL Hell, mentioned earlier). But even if no other program references a unique component developed for just one system, you have to do it the same way when you use COM. A big improvement in .NET architecture is that it recognizes that this just isn't necessary. .NET lets you simply store the components where you want to, usually in the directory with your application executable.
For components that really do need to be shared by a lot of other programs, you can create just one copy in the GAC, or Global Assembly Cache. I explained how to use GACUTIL, the GAC Utility, in the About Visual Basic article GACUTIL - Sharing your work in the Global Assembly Cache. .NET keeps track of different versions here too. And Windows even gives you a customized display of the GAC. In the Windows Explorer view of the GAC, the subdirectory structure is hidden and the Paste option isn't even available because you must "install" an assembly in the GAC after it has been given a "strong name". See the About Visual Basic article SN.EXE - Code Strong Programs with Strong Names for more information about how to do this.
To help you see the difference, here's the view of the GAC in both Windows Explorer and the much more basic DOS Tree command.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
