Assemblies and versioning

Over the years Microsoft has been hammered by versioning problems. A common reason for failure is when an application expects version n of a library, but gets version n+1, which has subtly different behaviour. Complex interdependencies between DLLs make version problems hard to troubleshoot. As an aside, it seems to me that neither Java nor Linux, to mention two .Net competitors, has really addressed this problem.

In the .Net world the unit of deployment is called an assembly. An assembly is a .DLL or .Exe file. By default, applications can only access libraries that exist either in the application directory, or in a shared area called the Global Assembly Cache or GAC. You can specify other accessible assemblies through an XML configuration file. Assemblies in the GAC must have globally unique identifiers. Through policy files, you can lock your application to specific versions of its dependencies, or specify that it should use the latest version available.

After all, the reason for using shared libraries is that it is more efficient. In the .Net world, this is still possible, but its architects decided that efficiency was less important than reliability. They assumed that memory and disk space come cheaper than the time it takes to sort out version problems. Thus, the default behaviour is to stuff everything aside from the core Framework library into your own application directory. If you need to share additional libraries for efficiency, you can do it by consciously configuring the application to do so.

Another aspect of assemblies is the use of namespaces to disambiguate classes. Namespaces are somewhat similar to Java packages, although unlike Java you don’t need to match directory trees to package names.

The Languages

The .Net Framework already delivers on its multi-language promise. The current release features five official Microsoft languages, while others are available from third parties. Incidentally, Borland is working on Object Pascal for .Net, which is likely to be a significant addition to the .Net range.

C#

The native language of .Net is C#. This is Microsoft’s new language, and the one closest to Java. The Framework class library is written in C#. Here’s a few key features:

- Only about 80 keywords and 12 datatypes

- Familiar C++ -like syntax

- Single implementation inheritance, multiple interface inheritance

- Self-documenting with inline XML comments

- Supports attributes, metadata that is compiled into the code.

- Supports Reflection, allowing type discovery, late binding, and dynamic generation of IL at runtime.

- Component-oriented, supports properties, events and methods.

- Deeply object-oriented. For efficiency, C# has value types like byte, char, bool, int, float and double. It also supports structs. However, in C# everything can be treated as an object, even value types. For example:

int i = 4;
this.label1.Text = i.ToString();

Now, ToString is a method of Object, the ultimate superclass of all .Net classes. But int is a value type that doesn’t inherit from Object. Yet we can use still call ToString as if it did. The reason is a technique called boxing, which automatically wraps the value type in an object when required. It seems a small point, but it is certainly convenient. Of course there is a performance penalty.

Next