.net

.net - ¿Qué sucede si elimino el elemento auto admitido supportedRuntime?



(2)

Tengo mi proyecto objetivo 4.0. Lo actualicé a 4.5 y VS agregó

<startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/> </startup>

Además de cambiar TargetFrameworkVersion y tengo curiosidad si esto es redundante. Según entiendo, si el tiempo de ejecución no encuentra supportedRuntime, usa la versión de .net utilizada para compilar exe. Entonces, en este caso, el exe se compila usando 4.5 y también ha dicho que use 4.5. ¿Se comportaría de manera diferente si tengo esto o no y lo ejecutaré en una máquina que solo tiene 4.0?


La documentación de MSDN no da ninguna buena explicación de esto, pero encontré una publicación de blog de Scott Hanselman titulada " .NET Versioning y Multi-Targeting - .NET 4.5 es una actualización in situ a .NET 4.0 " que revela:

Si está creando una aplicación cliente, como WinForms, Console, WPF, etc., esto es completamente automático. Tu app.config contiene el hecho de que necesitas .NET 4.5 e incluso recibirás un mensaje para instalarlo.

Por lo tanto, la entrada de configuración trata de lo que sucede si un usuario con .NET 4.0 en su máquina (pero no .NET 4.5) intenta ejecutar su aplicación .NET 4.5. Tanto .NET 4.0 como .NET 4.5 están basados ​​en la versión 4 del CLR, por lo que son teóricamente compatibles; mismos formatos binarios y todo eso. La única diferencia entre un binario construido contra .NET 4.0 y uno creado contra .NET 4.5 es las bibliotecas a las que hacen referencia.

Entonces, una aplicación compilada para .NET 4.5 podría ejecutarse en una computadora con solo .NET 4.0 instalado. Sin embargo, obtendría una excepción de tiempo de ejecución si intenta utilizar cualquier API que no existía en 4.0.

Si tiene esta entrada de archivo de configuración, y un usuario con .NET 4.0 intenta ejecutar su aplicación, la aplicación no se ejecutará, y se le pedirá al usuario que instale .NET 4.5. (Vea la captura de pantalla en la publicación del blog de Scott.) Este es un buen valor predeterminado para la mayoría de las personas.

Si no tiene la entrada del archivo de configuración, entonces un usuario con .NET 4.0 podrá ejecutar su aplicación, pero obtendrá una excepción de tiempo de ejecución si intenta llamar a cualquier método o utiliza cualquier tipo que se haya agregado en 4.5. Esto será un gran problema para usted como desarrollador y para sus probadores. Solo debe hacer esto si tiene requisitos específicos para que su aplicación se ejecute en .NET 4.0 y debe aprovechar las nuevas características 4.5 si están presentes (y deberá tener cuidado con el manejo de excepciones y probar exhaustivamente ambas versiones )

Si desea ejecutar .NET 4.0, pero no necesita ninguna 4.5 API nueva, entonces su vida es mucho más simple: vaya a la pestaña Generar de Propiedades del proyecto y diríjase a .NET 4.0. Luego, el compilador se asegurará de que no llame a ninguna API que no existía en 4.0, y su aplicación se ejecutará correctamente en ambas máquinas, .NET 4.0 y .NET 4.5.


Respondiendo al comentario de @Dai y también abordando el hecho de que cuando se ejecuta como un servicio de Windows, es posible que no reciba un aviso para instalar la versión especificada en el archivo App.config.

¿Hay alguna forma de eliminarlo, pero aplicar de manera confiable una verificación de versión .NET 4.0 vs 4.5 en el código?

Esto es lo que uso para asegurarme de que el programa actual se ejecute en una versión dada de .NET Framework, inspirada en ¿Cómo detecto en tiempo de ejecución que .NET versión 4.5 está actualmente ejecutando su código?

/// <summary> /// Throws an exception if the current version of the .NET Framework is smaller than the specified <see cref="supportedVersion"/>. /// </summary> /// <param name="supportedVersion">The minimum supported version of the .NET Framework on which the current program can run. /// The version to use is not the marketing version, but the file version of mscorlib.dll. /// See <see href="https://blogs.msdn.microsoft.com/dougste/2016/03/17/file-version-history-for-clr-4-x/">File version history for CLR 4.x</see> and/or <see href="https://it.wikipedia.org/wiki/.NET_Framework#Versioni">.NET Framework Versioni (Build pubblicata)</see> for the version to use. /// </param> /// <exception cref="NotSupportedException">The current version of the .NET Framework is smaller than the specified <see cref="supportedVersion"/>.</exception> /// <returns>The version of the .NET Framework on which the current program is running.</returns> public static Version EnsureSupportedDotNetFrameworkVersion(Version supportedVersion) { var fileVersion = typeof(int).Assembly.GetCustomAttribute<AssemblyFileVersionAttribute>(); var currentVersion = new Version(fileVersion.Version); if (currentVersion < supportedVersion) throw new NotSupportedException($"Microsoft .NET Framework {supportedVersion} or newer is required. Current version ({currentVersion}) is not supported."); return currentVersion; }

Ejemplo de uso para garantizar la ejecución en .NET 4.6.2:

var v462 = new Version(4, 6, 1590, 0); EnsureSupportedDotNetFrameworkVersion(v462);