¿Qué hace 'useLegacyV2RuntimeActivationPolicy' en la configuración de .NET 4?

214

Al convertir un proyecto que usaba SlimDX y, por lo tanto, tenía código no administrado, a .NET 4.0 me encontré con el siguiente error:

El ensamblaje de modo mixto se compila con la versión 'v2.0.50727' del tiempo de ejecución y no se puede cargar en el tiempo de ejecución 4.0 sin información de configuración adicional.

Buscar en Google me dio la solución, que es agregar esto a la configuración de las aplicaciones:

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

Mi pregunta es, ¿qué está useLegacyV2RuntimeActivationPolicyhaciendo? No puedo encontrar ninguna documentación al respecto.

.net .net-4.0 app-config mixed-mode Cameron MacFarland
fuente

Respuestas:

165

Después de un poco de tiempo (y más búsquedas), encontré esta entrada de blog de Jomo Fisher.

Uno de los problemas recientes que hemos visto es que, debido a la compatibilidad con los tiempos de ejecución uno al lado del otro, .NET 4.0 ha cambiado la forma en que se une a ensamblajes de modo mixto más antiguos. Estos ensamblados son, por ejemplo, los que se compilan desde C ++ \ CLI. Los conjuntos DirectX disponibles actualmente están en modo mixto. Si ve un mensaje como este, entonces sabe que se ha encontrado con el problema:

El ensamblaje de modo mixto se compila con la versión 'v1.1.4322' del tiempo de ejecución y no se puede cargar en el tiempo de ejecución 4.0 sin información de configuración adicional.

[Recorte]

La buena noticia para las aplicaciones es que tiene la opción de recurrir al enlace de la era .NET 2.0 para estos ensamblados configurando un indicador app.config de esta manera:

<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0"/>
</startup>

Por lo tanto, parece que la forma en que el tiempo de ejecución carga los ensambles de modo mixto ha cambiado. No puedo encontrar ningún detalle sobre este cambio, o por qué se hizo. Pero el useLegacyV2RuntimeActivationPolicyatributo vuelve a cargar CLR 2.0.

Cameron MacFarland
fuente
28
Vale la pena señalar aquí que, mientras tanto, marklios answer ( stackoverflow.com/questions/1604663/… ) proporciona un enlace a su explicación detallada sobre este cambio.
Steffen Opel
1
Puede encontrar una explicación completa de esto en MSDN (aunque no menciona explícitamente la solución mencionada anteriormente): msdn.microsoft.com/en-us/magazine/ee819091.aspx
Mouhammed Soueidane
¿Qué sucede si agregué esto a la configuración de mi aplicación y a la configuración de mi proyecto UnitTest y sigo recibiendo un error de carga de archivos al ejecutar las pruebas? ¿Debo publicar una nueva pregunta?
CodenameCain
126

Aquí hay una explicación que escribí recientemente para ayudar con el vacío de información sobre este atributo. http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx (enlace de la máquina Wayback de Internet Archive)

Para citar los bits más relevantes:

[Instalar .NET] v4 es "no impactante". No debe cambiar el comportamiento de los componentes existentes cuando está instalado.

El atributo useLegacyV2RuntimeActivationPolicy básicamente le permite decir: “Tengo algunas dependencias en las API de shim heredadas. Haga que funcionen como solían hacerlo con respecto al tiempo de ejecución elegido ".

¿Por qué no hacemos de este el comportamiento predeterminado? Podría argumentar que este comportamiento es más compatible y hace que la transferencia de código de versiones anteriores sea mucho más fácil. Si recuerdas, este no puede ser el comportamiento predeterminado porque haría que la instalación de v4 sea impactante, lo que puede dañar las aplicaciones existentes instaladas en tu máquina.

La publicación completa explica esto con más detalle. En RTM, los documentos de MSDN sobre esto deberían ser mejores.

Mark Miller
fuente
user20493, ¿puede ejecutar su aplicación con la variable de entorno COMPlus_CLRLoadLogDir establecida en un directorio vacío al que la aplicación tiene acceso de escritura y comparte los registros resultantes (busque cualquier PII antes de compartir). Puede ayudar a explicar lo que está sucediendo. Es posible que el atributo config no se aplique al contexto en el que se ejecuta su aplicación.
Mark Miller
Este enlace también debería ayudarlo a comprender cuál es el problema y cuál es la solución para usted: msdn.microsoft.com/en-us/magazine/ee819091.aspx
Mouhammed Soueidane