dotnetup en preview: instala un SDK por usuario sin romper global.json

Instalar otro SDK de .NET no debería cambiar silenciosamente el que usa tu repositorio. El problema aparece cuando conviven tres decisiones: dónde se guardan los archivos, qué versión exige global.json y qué host encuentra el proceso mediante PATH; DOTNET_ROOT puede orientar a un apphost hacia una instalación y sus runtimes, pero no selecciona universalmente el SDK.

dotnetup intenta ordenar esas decisiones, pero sigue en vista previa pública. Microsoft lo presenta como un gestor de toolchains a nivel de usuario para instalar, actualizar y retirar SDK y runtimes sin escribir en una carpeta administrada por el sistema. Es una opción para probar versiones lado a lado, no una sustitución GA de Visual Studio, de los instaladores o de la administración de una máquina de producción.

Primero separa instalación, selección y proceso

Piensa en tres capas:

• Instalación: los SDK y runtimes que dotnetup conserva en su raíz administrada. En Windows, la documentación sitúa por defecto esa raíz bajo %LOCALAPPDATA%\\dotnetup\\dotnet; no es la copia de Program Files\\dotnet.
• Selección del repositorio: el global.json más cercano al directorio desde el que se trabaja puede expresar una versión y un rollForward. dotnetup sdk install usa ese archivo si no recibe un canal explícito.
• Proceso: dotnet --info se ejecuta con el host dotnet que resolvió el PATH. DOTNET_ROOT puede indicar a un apphost dónde buscar la instalación y los runtimes, pero no sustituye la resolución del SDK del host. dotnetup dotnet -- --info elige explícitamente el host administrado. Un proceso que no cargue la configuración de dotnetup puede seguir usando la instalación de máquina.

Por eso dotnetup list y dotnet --info responden preguntas distintas: el primero muestra requisitos e instalaciones que el gestor sigue; el segundo muestra qué host y SDK encontró el proceso actual.

Prueba el caso global.json en una carpeta temporal

No cambies el repositorio real. Una carpeta temporal de laboratorio evita editarlo, pero no aísla la instalación a nivel de usuario: dotnetup seguirá usando su raíz administrada y cualquier cambio de entorno tendrá el alcance documentado. Guarda en ella este archivo, que usa el ejemplo documentado por Microsoft:

{
  "sdk": {
    "version": "10.0.103",
    "rollForward": "latestPatch"
  }
}

Desde esa carpeta, inspecciona primero la versión del gestor y su inventario; después instala el requisito que se deriva del archivo:

dotnetup --version
dotnetup list
dotnetup sdk install
dotnetup list
dotnetup dotnet -- --info

La documentación define que latestPatch convierte 10.0.103 en el canal 10.0.1xx. Si usas latestFeature, el canal derivado es 10.0; latestMinor deriva 10; latestMajor deriva latest. Los valores disable, patch, feature, minor y major se tratan como una exigencia exacta. Una exigencia exacta queda fijada y no avanza con dotnetup update.

Si no hay un global.json en la ruta buscada, dotnetup sdk install usa latest. Si el archivo más cercano está mal formado, el comando falla en lugar de saltar a uno más lejano. Esa regla es útil para reproducibilidad: corrige el archivo que realmente gobierna el repositorio, no otro que casualmente esté en un directorio padre.

No confundas forwarding con modificar el PATH

La instalación y la configuración del entorno son operaciones distintas. Para un primer laboratorio, usa el modo none y ejecuta el host administrado mediante forwarding:

dotnetup env set none --dotnetup-on-path true
dotnetup env show
dotnetup dotnet -- --info

La forma --dotnetup-on-path true modifica solo el acceso al ejecutable dotnetup en PATH: no añade el dotnet administrado a PATH ni establece DOTNET_ROOT. Si ya puedes invocar dotnetup por otra ruta y quieres evitar incluso ese cambio, usa --dotnetup-on-path false. El cambio del acceso es reversible con dotnetup env clear; no toca el repositorio ni cambia la selección del dotnet normal. Así puedes comparar ese resultado con el entorno normal sin convertir la preview en la autoridad de todo el equipo.

El modo shell escribe la configuración en el perfil del shell y afecta a procesos iniciados desde una terminal nueva:

dotnetup env set shell --shell pwsh
dotnetup env script --shell pwsh | Invoke-Expression
dotnet --info

En Bash o Zsh cambia el valor de --shell según la documentación. El modo everywhere solo está disponible en Windows: modifica el PATH del sistema y el DOTNET_ROOT del usuario, puede requerir elevación y hace que la instalación administrada tenga precedencia sobre la copia de máquina. Es el modo con más alcance, así que no lo uses como primer experimento.

Para comprobar la ruta real, usa where.exe dotnet en Windows o command -v dotnet en Unix; en PowerShell también puedes usar Get-Command dotnet. Compara después con dotnetup dotnet -- --info. Si Visual Studio está instalado, recuerda que mantiene su propia copia de .NET a nivel de máquina; dotnetup no la actualiza ni la elimina.

Cuando quieras deshacer la configuración del entorno, dotnetup env clear retira ese cableado sin desinstalar .NET. Revisa antes dotnetup env show y abre una terminal nueva cuando el modo haya cambiado el perfil.

Actualiza canales, no versiones por accidente

dotnetup guarda el requisito solicitado separado de la versión concreta instalada. Un canal rodante puede resolver una versión más nueva:

dotnetup update
dotnetup list
dotnetup list --format json

También puedes acotar la operación a dotnetup sdk update, a dotnetup sdk update --all o a dotnetup runtime update. Una versión exacta se omite porque fue solicitada explícitamente. La actualización del gestor es otra operación: dotnetup self update no es lo mismo que actualizar los SDK y runtimes seguidos.

Si una actualización termina correctamente, dotnetup puede retirar componentes que ningún requisito restante necesita. Antes de automatizar una limpieza, guarda dotnetup list y confirma qué requisitos siguen registrados. La documentación indica que una versión permanece si otro requisito todavía la comparte.

Para escribir una versión resuelta dentro de global.json, usa solo el paso explícito y revisable:

dotnetup sdk install --update-global-json

Ese comando cambia el archivo del repositorio. Revisa el diff y decide si debe entrar en control de versiones; no lo incluyas en el primer laboratorio si solo quieres instalar lo que el archivo ya pide.

Decide si dotnetup encaja

Es razonable probarlo cuando necesitas SDKs lado a lado, instalaciones por usuario, canales preview/daily o una instalación guiada por global.json. Mantén el instalador, un gestor de paquetes o Visual Studio cuando necesitas una instalación generalmente disponible y soportada para una máquina de producción, una copia de máquina o una política centralizada de dispositivos.

No presentes latest, 10.0 o 10.0.1xx como versiones eternas: son intenciones que pueden resolver otra versión en el siguiente ciclo. Para builds reproducibles conserva el global.json, registra la versión resuelta y revisa cualquier diff antes de actualizar. La vista previa puede cambiar comandos, opciones y comportamiento antes de disponibilidad general; una prueba aislada hoy no es una promesa de compatibilidad futura.

Fuentes primarias: anuncio de dotnetup en .NET Blog, visión general de dotnetup, inicio y modos de acceso, configurar el acceso al .NET administrado, instalar el SDK requerido por global.json, actualizar instalaciones seguidas y cuándo usar dotnetup.