Tecnologías de .NET Framework no disponibles en .NET Core y .NET 5+
Varias tecnologías disponibles para las bibliotecas de .NET Framework no están disponibles para su uso con .NET 5+ (y .NET Core), por ejemplo, dominios de aplicaciones, comunicación remota y seguridad de acceso del código (CAS). Si las bibliotecas dependen de una o varias de las tecnologías que se enumeran en esta página, tenga en cuenta los enfoques alternativos que se mencionan.
Para obtener más información sobre la compatibilidad de API, vea Cambios importantes en .NET.
Dominios de aplicación
Los dominios de aplicación aíslan las aplicaciones entre sí. Los dominios de aplicación necesitan la compatibilidad con el entorno de ejecución y consumen muchos recursos. No se admite la creación de dominios de aplicación adicionales y no existen planes para agregar esta funcionalidad en el futuro. En el caso del aislamiento del código, use contenedores o procesos independientes como alternativa. Para cargar ensamblados de forma dinámica, use la clase AssemblyLoadContext.
Para facilitar la migración de código de .NET Framework, .NET 5+ expone parte de la superficie de la API AppDomain. Algunas de las API funcionan con normalidad (por ejemplo, AppDomain.UnhandledException), algunos miembros no hacen nada (por ejemplo, SetCachePath) y algunos de ellos generan PlatformNotSupportedException (por ejemplo, CreateDomain). Compruebe los tipos que usa con el System.AppDomain origen de referencia en el repositorio de GitHub dotnet/runtime. Asegúrese de seleccionar la rama que coincida con su versión implementada.
Comunicación remota
La comunicación remota de .NET no se admite en .NET 5+ (y .NET Core). La comunicación remota de .NET se ha identificado como una arquitectura problemática. Se usa para la comunicación entre dominios de aplicación, que ya no se admiten. Además, la comunicación remota necesita compatibilidad con el runtime, cuyo mantenimiento resulta caro.
Para lograr una comunicación sencilla entre procesos, considere la posibilidad de usar mecanismos de comunicación entre procesos (IPC) como alternativa a la comunicación remota, como las clases System.IO.Pipes o MemoryMappedFile. En escenarios más complejos, el proyecto StreamJsonRpc de código abierto proporciona un marco de comunicación remota de .NET Standard multiplataforma que funciona sobre las conexiones de canalización o secuencia existentes.
En los equipos, utilice una solución basada en red como una alternativa. Si es posible, use un protocolo de texto sin formato con poca sobrecarga, como HTTP. Como opción, aquí se puede usar el servidor web Kestrel, el que utiliza ASP.NET Core. También considere el uso de System.Net.Sockets para escenarios de conexión entre equipos basada en red. StreamJsonRpc, que se ha mencionado antes, se puede usar para la comunicación JSON o binaria (por medio de MessagePack) sobre sockets web.
Para conocer más opciones de mensajería, consulte Proyectos de desarrolladores de código abierto de .NET: mensajería.
Seguridad de acceso del código (CAS)
El espacio aislado, que se basa en el runtime o en el marco para restringir qué recursos usa o ejecuta una aplicación administrada, no es compatible con .NET Framework y, por tanto, tampoco se admite en .NET Core y.NET 5+. Hay demasiados casos en .NET Framework y en el runtime en los que se produce una elevación de privilegios para continuar tratando la seguridad de acceso al código (CAS) como un límite de seguridad. Además, la seguridad de acceso del código dificulta más la implementación y suele tener implicaciones en el rendimiento correcto para las aplicaciones que no pretenden usar esta funcionalidad.
Use los límites de seguridad que proporciona el sistema operativo, como la virtualización, los contenedores o las cuentas de usuario para ejecutar procesos con el menor conjunto de privilegios.
Transparencia de seguridad
Como ocurre con la seguridad de acceso al código, la transparencia de seguridad separa el código del espacio aislado del código crítico de seguridad de manera declarativa, pero ya no se admite como un límite de seguridad. Silverlight usa mucho esta característica.
Use los límites de seguridad que proporciona el sistema operativo, como la virtualización, los contenedores o las cuentas de usuario para ejecutar procesos con el menor conjunto de privilegios.
System.EnterpriseServices
System.EnterpriseServices (COM+) no es compatible con .NET Core y .NET 5+.
Workflow Foundation y WCF
Windows Workflow Foundation (WF) y Windows Communication Foundation (WCF) no se admiten en .NET 5 y versiones posteriores (incluido .NET Core). Para ver alternativas, consulte las páginas CoreWF y CoreWCF.
Guardar los ensamblados generados por la reflexión
.NET 5+ (incluido .NET Core) no permite guardar los ensamblados generados por las API System.Reflection.Emit. El método AssemblyBuilder.Save no está disponible en .NET 5+ (incluido .NET Core). Además, los siguientes campos de la enumeración AssemblyBuilderAccess no están disponibles:
Como alternativa, considere la biblioteca ILPack.
Para más información, vea la incidencia 15704 de dotnet/runtime.
Carga de ensamblados de varios módulos
Los ensamblados que constan de varios módulos (OutputType=Module en MSBuild) no se admiten en .NET 5 y versiones posteriores (incluido .NET Core).
Como alternativa, considere la posibilidad de combinar los módulos individuales en un único archivo de ensamblado.