Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News .NET 5 Breaking Changes: Historic Technologies

.NET 5 Breaking Changes: Historic Technologies

This item in japanese

In part two of our .NET 5 coverage, we take a look back at historic .NET technologies that never made the jump to .NET Core. What’s interesting about these technologies is their APIs were copied across, hinting that Microsoft was considering a .NET Core implementation of them in the future.

Global Assembly Cache

The theory behind the Global Assembly Cache (GAC) was that all .NET libraries could be stored in a single, centralized location. In this manner it would be similar to COM libraries. But unlike COM, it could store multiple versions of each library. In this way, Microsoft hoped to avoid the “DLL hell” scenario that plagued 90’s era applications.

However, versioning issues persisted. Furthermore, the need to obtain a code signing certificate and the increased security that came with Windows Vista made the GAC a hated technology. By the time .NET 4.5 was released, few applications used the GAC for non-Microsoft libraries. The major exception was commercial libraries, but even those have moved to a more NuGet friendly delivery model.

So, it is no surprise that under .NET Core, Microsoft radically changed their philosophy. In the new model, all library dependencies are deployed with the application, allowing the application to be isolated from other .NET Core applications. As such, .NET Core doesn’t have the concept of a GAC.

Nonetheless, the GAC APIs still exist in .NET Core. They don’t do much, for example the property that indicates if an assembly was in the GAC is hard-coded to return false.

In order to make their intentions clearer, all GAC APIs are now marked as obsolete and Microsoft is considering their removal in a future version.


.NET Remoting was inspired by DCOM and Java Remoting (Java RMI). In all three, the basic idea was one application could use a proxy object to manipulate a real object running inside another application. While it technically worked, .NET Remoting was never popular due to the difficulty in using it correctly and the general perception of it being brittle.

With this in mind, .NET Core never implemented the .NET Remoting APIs. Just like the GAC APIs, it only had inoperable placeholders. So, these too are being marked as obsolete with the intention that they will be eventually removed.

Code Access Security

Continuing the theme, Code Access Security (CAS) is yet another .NET Framework technology whose APIs were copied into .NET Core with the implementation. And like the others, those APIs are marked as obsolete.

Code Access Security was created in an era before isolated containers such as Docker. Back in the .NET Framework era, multiple applications would be hosted in a single Internet Information Server (IIS) instance. In theory, each would be isolated into a separate App Domain, but it wasn’t hard to break free and interfere with other applications running in IIS.

In order to limit the amount of damage possible, Code Access Security was created. The basic idea was that dangerous APIs would be flagged with attributes indicating the risk. The hosts such as IIS could be configured to run applications with various “trust” levels, theoretically putting them into a sandbox.

Another use of CAS was for browser-hosted applications. Long before Silverlight, it was possible to run Windows Forms applications inside Internet Explorer. The application’s trust level was partially dictated by where it was loaded from, with Intranet sites granting higher privileges.

But like many early .NET technologies, it was hard to implement CAS correctly. There were numerous ways for malicious applications to bypass CAS restrictions, while benign applications were often hamstrung by the restrictions. At a result, browser hosted applications were quickly banned and CAS trust levels were largely ignored for IIS.


It may come as a surprise that Thread.Abort was never implemented for .NET Core. While it was always considered to be dangerous, it was also unavoidable. Something as simple as a request timeout or client disconnect in ASP.NET would trigger a Thread.Abort call. And if the code wasn’t scrupulously written to handle it, this could result in resource leaks such as acquired locks or open database transactions.

By the time ASP.NET Core was created, CancellationToken had become the safe and widely accepted alternative to Thread.Abort, so there was no need to implement it in the first version of .NET Core. And though .NET Core has expanded its capabilities beyond just web sites, no other major application framework needed Thread.Abort so it continued to throw PlatformNotSupportedException.

With .NET 5, the method is finally marked as obsolete.

In part 3 of our .NET 5 Breaking Changes series we’ll be looking at ASP.NET Core.

Rate this Article