Solución:
Editar
Se lanzó .NET Core 3.x SDK. A diferencia de la v2.2 y las versiones anteriores, esta versión no no admite la capacidad de apuntar a tiempos de ejecución anteriores (es decir, netcoreapp2.2, netcoreapp2.1, etc.)
tldr;
Si. Al instalar .NET Core Runtime 2.2.3, puede ejecutar aplicaciones destinadas a netcoreapp2.0, netcoreapp2.1 y netcoreapp2.2, sin necesidad de instalar tiempos de ejecución adicionales.
Explicación
Microsoft:
… Las actualizaciones de tiempo de ejecución de .NET Core son compatibles dentro de una ‘banda’ de versión principal, como 1.xy 2.x.
En otras palabras: (Las actualizaciones menores dentro de la misma versión principal son compatibles con versiones anteriores)
Microsoft:
Además, las versiones más recientes de .NET Core SDK generalmente mantienen la capacidad de crear aplicaciones que tienen como destino versiones anteriores del tiempo de ejecución de una manera compatible.
En otras palabras: (el último SDK puede apuntar a tiempos de ejecución anteriores)
Microsoft:
En general, solo necesita el SDK más reciente y la versión de parche más reciente de los tiempos de ejecución requeridos para su aplicación.
En otras palabras: (en términos generales, solo debe instalar el último SDK / tiempo de ejecución)
Microsoft:
Con el tiempo, a medida que instala versiones actualizadas del tiempo de ejecución de .NET Core y el SDK, es posible que desee quitar las versiones obsoletas de .NET Core de su máquina. La eliminación de versiones anteriores del tiempo de ejecución puede cambiar el tiempo de ejecución elegido para ejecutar aplicaciones de marco compartido
En otras palabras: (a medida que instala SDK / tiempos de ejecución adicionales uno al lado del otro a lo largo del tiempo, ocasionalmente debe eliminar las versiones anteriores, en favor de la última)
Fuente: https://docs.microsoft.com/en-us/dotnet/core/versions/remove-runtime-sdk-versions?tabs=windows
Control de versiones de .NET Core
Según documentación:
“.NET Core 2.1” hace referencia al número de versión de .NET Core Runtime. .NET Core Runtime tiene un enfoque mayor / menor / parche para el control de versiones que sigue al control de versiones semántico.
En otras palabras, las versiones en tiempo de ejecución de .NET Core siguen el esquema de control de versiones semántico:
[Major].[Minor].[Patch]
Dónde:
- Las actualizaciones importantes introducen cambios importantes
- Las actualizaciones menores son actualizaciones de funciones que son compatibles con versiones anteriores de versiones menores.
- Las actualizaciones de parches son generalmente correcciones de errores o parches de seguridad para funciones existentes (también son compatibles con versiones anteriores de versiones menores).
Entonces, la respuesta a la pregunta anterior se basa en el control de versiones semántico:
- Las actualizaciones importantes no son compatibles con versiones anteriores anterior versión principal
- Las actualizaciones menores y / o de parches son compatibles con versiones anteriores dentro del mismo versión
Con este conocimiento, cuando las aplicaciones .NET Core se compilan, publican o restauran, tienen como objetivo una versión principal y un conjunto de características según lo indicado por los números de versión principal / secundaria que se encuentran en el nombre del tiempo de ejecución. Entonces, netcoreapp2.2 es compatible con versiones anteriores netcoreapp2.1, que, a su vez, es compatible con versiones anteriores netcoreapp2.0. Pero todos son incompatibles con netcoreapp1.x o netcoreapp3.x.
Con una instalación de .NET Core 2.1.5 en tiempo de ejecución y suponiendo una implementación de publicación dependiente del marco, podrá ejecutar aplicaciones dirigidas a:
- netcoreapp2.0
- netcoreapp2.1
Pero no:
- netcoreapp1.0 (incompatible)
- netcoreapp2.2 (aún no admitido)
Si hay varios tiempos de ejecución instalados, se elige el tiempo de ejecución exacto en función del último tiempo de ejecución instalado con el parche más alto.
Acerca del SDK
El SDK no se basa en el control de versiones semántico. Sin embargo, cada SDK tiene como objetivo un tiempo de ejecución máximo de .NET Core y es compatible con todas las versiones anteriores.
Eso significa que no necesita instalar más de un SDK en su servidor de compilación si desea compilar en varios tiempos de ejecución (aunque podría hacerlo). El SDK ya incluye todos los tiempos de ejecución necesarios para crear aplicaciones en la versión actual (o en cualquier versión anterior) fuera de la caja. Por ejemplo, si instala .NET Core 2.2.105 SDK, puede compilar para netcoreapp1.0, netcoreapp2.0, netcoreapp2.1 o netcoreapp2.2. Pero no puede compilar para .NET Core 2.3 o 3.0.
Un ejemplo
Supongamos que tengo un servidor de compilación, que tiene instalado el SDK de .NET Core más reciente (SDK 2.2.105 – 2.2.3 Runtime).
Aunque el SDK 2.2.105 está instalado, es posible que desee compilar y publicar una aplicación .NET Core 2.1:
dotnet publish
/p:Configuration=Release -r win-x64 --self-contained false
/p:IsWebConfigTransformDisabled=true --framework netcoreapp2.1
/p:DebugSymbols=false /p:DebugType=None
-
/p:Configuration=Release– configurar para lanzamiento -
-r win-x64– implementación de Windows de destino (en lugar de portátil). Para obtener una lista completa, consulte este https://docs.microsoft.com/en-us/dotnet/core/rid-catalog. -
--self-contained false– Implementación dependiente del marco (requiere que el tiempo de ejecución esté instalado en el host) -
/p:IsWebConfigTransformDisabled=true– no transforme web.config para evitar errores con el web.config predeterminado generado por Visual Studio (puede ser necesario al migrar de 2.1 a 2.2) -
--framework netcoreapp2.1– apuntar explícitamente a un marco de tiempo de ejecución -
/p:DebugSymbols=false /p:DebugType=None– deshabilitar archivos .PDB
Esta compilación podría instalarse en un servidor de producción con el último tiempo de ejecución .NET Core Runtime + Hosting Bundle 2.2.3; no se necesitan otros tiempos de ejecución (o SDK).
Espero que esto ayude a alguien más