Years ago my work took me from Java to .NET (both C# and VB.NET) but recently, as often happens, I found myself living again in the Java world.

I’m sure you know that the .NET and Java platforms and very similar. .NET has a virtual machine, an equivalent to Java Byte Code and built-in class libraries that include much of the functionality of the JCL.

But what are the differences? Over the next few months, I’ll be writing about several of the differences between the two environments—checked vs. unchecked exceptions, getters, setters and properties, primitive data types vs. structs, and perhaps others. In this brief article, I’ll discuss the Java classpath and .NET metadata.

All modern programs reference external libraries. A Java program contains a classpath (set at compile time or via an environmental variable) that points to the location of user-defined classes and packages [Figure 1(a)]. .NET programs, on the other hand, are compiled into assemblies (units of functionality present as either .exe or .dll files) that contain not only intermediate language but also metadata that identifies all external references [Figure 1(b)].

Figure 1

Jave and NET Figure 1

Java classes find required external classes and packages by searching in classpath entries defined at compilation or in an environmental variable. .NET assemblies, on the other hand, contain metadata within the compilation unit that identify external assemblies.

 

In Figure 1(a) the Java classpath is a pointer to a physical location elsewhere in the environment, but what does .NET metadata point to? In order to understand this, you need to know that there are two kinds of assemblies in .NET—private assemblies and shared assemblies.

Private assemblies are always located in either the same directory (or a subdirectory) of the calling assembly. Shared assemblies can also be located in a directory called the Global Assembly Cache (GAC) (Figure 2).

Figure 2

Java and NET Figure 2

Private assemblies can be located by their calling assemblies, provided that they are in the same directory or in a subdirectory. Strongly named assemblies can also be located in the Global Assembly cache (which is searched first).* The default location of the GAC is %windir%\Microsoft.NET\assembly in .NET 4.0. Earlier versions of .NET placed the GAC at %windir%\assembly.

 

If you use Visual Studio to compile your projects, your resulting assemblies are private by default. In order to create a shared assembly, you must sign it using the private key of a dual-key encryption system—the public portion of the key is inserted into the metadata of the assembly. (Figure 3).

Figure 3

Java and NET Figure 3

.publickey =  (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00  // .$…………..
00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00  // .$..RSA1……..
E3 C4 A7 AF 7B A6 52 E5 D2 BB 3A 76 30 25 E4 60  // ….{.R…:v0%.`
88 7B 0A 09 3C 75 07 83 85 2E 74 AA 8A 47 94 B8  // .{..<u….t..G..
A5 54 9F DE 98 EB C4 A8 D3 29 DA AB A6 BC 3D 1E  // .T…….)….=.
31 D3 37 27 C4 D6 B8 DF 5C 9D 7B 18 8E 5F 20 8B  // 1.7’….\.{.._ .
9D 93 24 0C FB 0C DD 1B 65 29 4F F5 1F 63 BF 89  // ..$…..e)O..c..
62 67 B2 C4 58 81 33 CC 9D 6A AF 0C 81 29 50 B9  // bg..X.3..j…)P.
92 33 E6 46 2C 9B 0B A1 C0 48 8C DA 8C CB 29 E3  // .3.F,….H….).
BC F2 10 C3 39 13 0C 48 9E 1B AC 2E 3D E9 CA BD ) // ….9..H….=…
.hash algorithm 0x00008004
.ver 1:0:0:0

Shared assemblies are created by signing them with the private key of a dual-key encryption system (called a strong name key file in Visual Studio). A strong-named assembly is a shared assembly and includes the entire public key in its metadata.

 

When an application sets a reference to an external shared assembly, it includes a token to the public key in its metadata [Figure 4(b)]. If the referenced external assembly is private then, of course, the public key token is missing [Figure 4(a)].

Figure 4

Java and NET Figure 4

Metadata references to shared assemblies include a public key token (b). Metadata references to private assemblies contain only a version number.

 

There are many more aspects to .NET metadata and private vs. shared assemblies, but this is enough to get you started.

To learn more about how the .NET run finds external references, go to https://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx.

To learn more about the GAC, go to https://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).aspx.

 

*An application will first look for an external resource compiled as a private assembly in the same directory as its own directory or in a subdirectory with the same name as the assembly. Alternatively, the application’s configuration file can identify another location contained within the directory of the calling assembly. If the external resource is a strongly named assembly, the rules are the same except that the first searched location is the GAC.

 

Leave a Reply

Your email address will not be published.