.NET Framework technologies unavailable on .NET Core and .NET 5+
Several technologies available to .NET Framework libraries aren't available for use with .NET 5+ (and .NET Core), such as app domains, remoting, and code access security (CAS). If your libraries rely on one or more of the technologies listed on this page, consider the alternative approaches mentioned.
For more information on API compatibility, see Breaking changes in .NET.
Application domains (AppDomains) isolate apps from one another. AppDomains require runtime support and are resource-expensive. Creating more app domains isn't supported, and there are no plans to add this capability in the future. For code isolation, use separate processes or containers as an alternative. To dynamically load assemblies, use the AssemblyLoadContext class.
To make code migration from .NET Framework easier, .NET 5+ exposes some of the AppDomain API surface. Some of the APIs function normally (for example, AppDomain.UnhandledException), some members do nothing (for example, SetCachePath), and some of them throw PlatformNotSupportedException (for example, CreateDomain). Check the types you use against the
System.AppDomain reference source in the dotnet/runtime GitHub repository. Make sure to select the branch that matches your implemented version.
.NET Remoting isn't supported on .NET 5+ (and .NET Core). .NET remoting was identified as a problematic architecture. It's used for communicating across application domains, which are no longer supported. Also, remoting requires runtime support, which is expensive to maintain.
For simple communication across processes, consider inter-process communication (IPC) mechanisms as an alternative to remoting, such as the System.IO.Pipes class or the MemoryMappedFile class. For more complex scenarios, the open-source StreamJsonRpc project provides a cross-platform .NET Standard remoting framework that works on top of existing stream or pipe connections.
Across machines, use a network-based solution as an alternative. Preferably, use a low-overhead plain text protocol, such as HTTP. The Kestrel web server, which is the web server used by ASP.NET Core, is an option here. Also, consider using System.Net.Sockets for network-based, cross-machine scenarios. StreamJsonRpc, mentioned earlier, can be used for JSON or binary (via MessagePack) communication over web sockets.
For more messaging options, see .NET Open Source Developer Projects: Messaging.
Code access security (CAS)
Sandboxing, which relies on the runtime or the framework to constrain which resources a managed application or library uses or runs, isn't supported on .NET Framework and therefore is also not supported on .NET Core and .NET 5+. There are too many cases in the .NET Framework and the runtime where an elevation of privileges occurs to continue treating CAS as a security boundary. Also, CAS makes the implementation more complicated and often has correctness-performance implications for applications that don't intend to use it.
Use security boundaries provided by the operating system, such as virtualization, containers, or user accounts, for running processes with the minimum set of privileges.
Similar to CAS, security transparency separates sandboxed code from security critical code in a declarative fashion but is no longer supported as a security boundary. This feature is heavily used by Silverlight.
Use security boundaries provided by the operating system, such as virtualization, containers, or user accounts, for running processes with the least set of privileges.
System.EnterpriseServices (COM+) isn't supported by .NET Core and .NET 5+.
Workflow Foundation and WCF
Saving assemblies generated by reflection
.NET 5+ (including .NET Core) does not support saving assemblies that are generated by the System.Reflection.Emit APIs. The AssemblyBuilder.Save method is not available in .NET 5+ (including .NET Core). In addition, the following fields of the AssemblyBuilderAccess enumeration aren't available:
As an alternative, consider the ILPack library.
For more information, see dotnet/runtime issue 15704.
Loading multi-module assemblies
Assemblies that consist of multiple modules (
OutputType=Module in MSBuild) are not supported in .NET 5+ (including .NET Core).
As an alternative, consider merging the individual modules into a single assembly file.