Tecnologías de .NET Framework no disponibles en .NET

  • Artículo

Varias tecnologías disponibles para las bibliotecas de .NET Framework no están disponibles para su uso con .NET 6 y versiones posteriores como, 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 6 y versiones posteriores 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

Comunicación remota de .NET no se admite en .NET 6 y versiones posteriores. 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.

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 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 6 o versiones posteriores. CAS ya no se trata como un límite de seguridad, puesto que hay demasiados casos en .NET Framework y en el runtime en los que se produce una elevación de privilegios. 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.

Para ejecutar procesos con el menor conjunto de privilegios, use los límites de seguridad que proporciona el sistema operativo, como la virtualización, los contenedores o las cuentas de usuario.

System.EnterpriseServices

System.EnterpriseServices (COM+) no se admite en .NET 6 o versiones posteriores.

Workflow Foundation

Windows Workflow Foundation (WF) no se admite en .NET 6 o versiones posteriores. Para encontrar una alternativa, consulte CoreWF.

Sugerencia

El servidor de Windows Communication Foundation (WCF) se puede usar en .NET 6 y en versiones posteriores mediante 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 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 más información sobre cómo usar esta API, consulte Clase System.Reflection.Emit.AssemblyBuilder.

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 6 o versiones posteriores.

Como alternativa, considere la posibilidad de combinar los módulos individuales en un único archivo de ensamblado.

Bloques de scripts de XSLT

Los bloques de scripts de XSLT solo se admiten en .NET Framework. No se admiten en .NET 6 o versiones posteriores.

Vea también