.NET Framework technologies unavailable on .NET

Several technologies available to .NET Framework libraries aren't available for use with .NET 6+, 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

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 6+ 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.

Remoting

.NET Remoting isn't supported on .NET 6+. .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.

Because remoting is not supported, calls to BeginInvoke() and EndInvoke() on delegate objects will throw PlatformNotSupportedException. For more information, see Migrating Delegate BeginInvoke Calls For .NET Core.

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 6+. CAS is no longer treated as a security boundary, because there are too many cases in .NET Framework and the runtime where an elevation of privileges occurs. 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.

Security transparency

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.

To run processes with the least set of privileges, use security boundaries provided by the operating system, such as virtualization, containers, or user accounts.

System.EnterpriseServices

System.EnterpriseServices (COM+) isn't supported by .NET 6+.

Workflow Foundation

Windows Workflow Foundation (WF) is not supported in .NET 6+. For an alternative, see CoreWF.

Some reflection emit APIs are not supported

.NET 8 and earlier versions of .NET (Core) don't support saving assemblies that are generated by the System.Reflection.Emit APIs, and the AssemblyBuilder.Save method isn't available. In addition, the following fields of the AssemblyBuilderAccess enumeration aren't available:

• ReflectionOnly
• RunAndSave
• Save

In .NET 9, a PersistedAssemblyBuilder was implemented and the AssemblyBuilder.Save method was added back to the reflection emit library. To learn more about how to use this API, see System.Reflection.Emit.PersistedAssemblyBuilder class.

For more information about the different AssemblyBuilder implementations in .NET, see System.Reflection.Emit.AssemblyBuilder class

Loading multi-module assemblies

Assemblies that consist of multiple modules (OutputType=Module in MSBuild) are not supported in .NET 6+.

As an alternative, consider merging the individual modules into a single assembly file.

XSLT script blocks

XSLT script blocks are supported only in .NET Framework. They are not supported on .NET 6 or later.

See also

• Overview of porting from .NET Framework to .NET