Tecnologías de .NET Framework no disponibles en .NET
Varias tecnologías disponibles para las bibliotecas de .NET Framework no están disponibles para su uso con .NET 6+, como dominios de aplicación, comunicación remota y seguridad de acceso a código (CAS). Si las bibliotecas dependen de una o varias de las tecnologías enumeradas en esta página, tenga en cuenta los enfoques alternativos mencionados.
Para obtener más información sobre la compatibilidad de api, consulte Cambios importantes en .NET.
Dominios de aplicación
Los dominios de aplicación (AppDomains) aíslan las aplicaciones entre sí. Los dominios de aplicación requieren soporte en tiempo de ejecución y son consumidores de recursos. No se admite la creación de más dominios de aplicación y no hay planes para agregar esta funcionalidad en el futuro. Para el aislamiento de código, use procesos o contenedores independientes como alternativa. Para cargar ensamblados dinámicamente, use la clase AssemblyLoadContext.
Para facilitar la migración de código desde .NET Framework, .NET 6+ expone parte de la superficie de api de AppDomain. Algunas de las APIs funcionan normalmente (por ejemplo, AppDomain.UnhandledException), algunos miembros no hacen nada (por ejemplo, SetCachePath) y algunos de ellos lanzan PlatformNotSupportedException (por ejemplo, CreateDomain). Compruebe los tipos que usa con e System.AppDomain origen de referencia en el repositorio de GitHub dotnet/runtime. Asegúrese de seleccionar la rama que coincida con la versión implementada.
Comunicación remota
.NET Remoting no se admite en .NET 6+. La comunicación remota de .NET se ha identificado como una arquitectura problemática. Se usa para comunicarse 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 una comunicación sencilla entre procesos, considere los mecanismos de comunicación entre procesos (IPC) como alternativa a la comunicación remota, como la clase System.IO.Pipes o la clase MemoryMappedFile. Para escenarios más complejos, el proyecto de código abierto StreamJsonRpc proporciona un marco multiplataforma para la comunicación remota en .NET Standard que funciona sobre conexiones de flujo o canalización existentes.
En los equipos, utilice una solución basada en red como una alternativa. Preferiblemente, use un protocolo de texto sin formato de baja sobrecarga, como HTTP. El servidor web Kestrel, que es el servidor web usado por ASP.NET Core, es una opción aquí. Además, considere la posibilidad de usar System.Net.Sockets para escenarios entre máquinas basados en red. StreamJsonRpc, mencionado anteriormente, se puede usar para la comunicación JSON o binaria (a través de MessagePack) a través de sockets web.
Para conocer más opciones de mensajería, consulte Proyectos de desarrolladores de código abierto de .NET: mensajería.
Dado que no se admite la comunicación remota, las llamadas a BeginInvoke() y EndInvoke() en los objetos delegados generarán una excepción PlatformNotSupportedException. Para más información, consulte Migración de llamadas a Delegate.BeginInvoke para .NET Core.
Seguridad de acceso al código (CAS)
Sandboxing, que se basa en el entorno de ejecución o en el marco para restringir qué recursos utiliza o ejecuta una aplicación o biblioteca gestionada, no se admite en .NET Framework y, por lo tanto, tampoco se admite en .NET 6+. CAS ya no se trata como un límite de seguridad, ya que hay demasiados casos en .NET Framework y el entorno de ejecución en el que se produce una elevación de privilegios. Además, CAS hace que la implementación sea más complicada y, a menudo, tiene implicaciones de rendimiento de corrección para las aplicaciones que no tienen intención de usarla.
Use los límites de seguridad proporcionados por el sistema operativo, como la virtualización, los contenedores o las cuentas de usuario, para ejecutar procesos con el conjunto mínimo 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 en gran medida esta característica.
Para ejecutar procesos con el menor conjunto de privilegios, use los límites de seguridad proporcionados por el sistema operativo, como la virtualización, los contenedores o las cuentas de usuario.
System.EnterpriseServices
System.EnterpriseServices (COM+) no es compatible con .NET 6+.
Workflow Foundation
Windows Workflow Foundation (WF) no se admite en .NET 6+. Para encontrar una alternativa, consulte CoreWF.
Sugerencia
El servidor de Windows Communication Foundation (WCF) se puede usar en .NET 6+ utilizando los paquetes NuGet de CoreWCF . Para más información, consulte Se ha publicado CoreWCF 1.0.
No se admiten algunas API de emisión de reflexión
.NET 8 y versiones anteriores de .NET (Core) no admiten guardar ensamblados generados por las API de System.Reflection.Emit y el método AssemblyBuilder.Save no está disponible. Además, los siguientes campos de la enumeración AssemblyBuilderAccess no están disponibles:
En .NET 9, se implementó un elemento PersistedAssemblyBuilder y el método AssemblyBuilder.Save se agregó de nuevo a la biblioteca de emisión de reflexión. Para obtener más información sobre cómo usar esta API, consulte clase System.Reflection.Emit.PersistedAssemblyBuilder.
Para obtener más información sobre las distintas implementaciones de AssemblyBuilder en .NET, vea clase System.Reflection.Emit.AssemblyBuilder.
Carga de ensamblajes multimodulares
Los ensamblados que constan de varios módulos (OutputType=Module en MSBuild) no se admiten en .NET 6+.
Como alternativa, considere la posibilidad de combinar los módulos individuales en un único archivo de ensamblado.
Bloques de script XSLT
Los bloques de script de XSLT solo se admiten en .NET Framework. No se admiten en .NET 6 o versiones posteriores.
