Platform vs Library Versioning in Longhorn/Orcas

6/14/2004 10:11:00 PM

Platform vs Library Versioning in Longhorn/Orcas

I just went to a NETDA lecture, in which Jeffrey Richter spoke on major changes to versioning.

In Win32, we had DLL hell, where one dll with the same name could overwrite another dll of the same name in the windows directory, causing a previously working application to fail. The .NET Frameworks solved this problem by introducing strongly named assemblies; however, it introduced another problem called "Versioning Hell," because a library could not easily be updated since the CLR looked for an exact version match. There was a complex way to solve this problem through policy files; however, even engineers at Microsoft found this approach too difficult.

Microsoft has a new approach for Longhorn and Orcas (.NET v3.0), which divides assemblies into two categories, Platforms and Libraries. The classification dictates which version of an assembly, an application references, is loaded by the CLR.

The main difference between the two is that the CLR binds to the latest version of a platform assembly but attempts to bind to the same version of a library assembly that an application was compiled against (major & minor version must match;though, the highest build & revision is used for "servicing"). Because the latest version of platform assemblies are used, platforms assemblies must be assembly committed to backward compatibility.

One analogy Richter used is that platforms are to interfaces and libraries are to implementation. Platform assemblies should only really include abstract classes, interfaces and basic types, because of limited flexibility and the need for backward compatibility. Another limitation of platform assemblies is that they cannot reference types from other "library" assemblies--only platform assemblies. Platform assemblies are good for providing contractual interfaces and basic types for data interchange throughout the system across multiple libraries, app-domains and process. Libraries, which have more freedom to change, should contain actual implementation.

Most assemblies will or should be libraries. Microsoft discourages the use of platform assemblies. However, it makes sense for assemblies that behave like system APIs, such as providing access to a single shared resource in the computer.

There are actually three types of platform assemblies: System-wide, process-wide, and app domain-wide. The latter two support a feature called interim rollback, in case an application fails to work with a newer version of the assembly than it was compiled against. System-wide platform assemblies do not support interim rollback. An administrator can exclude a specific newer version of a non-SW platform assembly from being loaded if the application fails to run with that assembly; however, if an even newer version of that platform assembly is loaded, the application will bind to that latest version, because it was not specifically excluded. This is because it is probably the case the later version will have fixed the incompatibility caused by the prior version. So, both process-wide and app-domain platform assemblies can have different platform assemblies run on different processes and app-domains, respectively.

The CLR, of course, will be a machine-wide platform assembly. In a break from the present scheme, Longhorn will no longer support multiple CLRs. Every managed application will be forced to use the latest version of the CLR on the system.

As for the other WinFX APIs, Indigo is most likely to be build as libraries, although some abstract classes may be available in AppDomain platforms. Avalon Core will be machine-wide platform assembly, with much of the non-core Avalon Framework as app-domain platform assemblies. WinFS, I recall, will probably be available as app-domain platform assemblies as well. Aero (the shell) will be machine-wide platform assembly as much of the assembly wraps machine-wide Win32 dlls.

As for the possibility that applications using reflection may break on a newer version of CLR, the CLR team has purposely made reflection behave less predictably. For example, the order of members returned from Type.GetMembers() is randomized prior to being returned.

Whidbey is expected to include an Assembly attribute, AssemblyFlagsAttribute, which allows to developer to specify Library, AppDomainPlatform, ProcessPlatform, SystemPlatform, or Legacy to identify the versioning scheme the CLR uses to load a reference assembly.

One other interesting news is that Virtual PC may actually be included and integrated within Longhorn.

Comments

 

Navigation

Categories

About

Net Undocumented is a blog about the internals of .NET including Xamarin implementations. Other topics include managed and web languages (C#, C++, Javascript), computer science theory, software engineering and software entrepreneurship.

Social Media