Cómo publicar y desplegar una utilidad WPF de .NET

Publicación desde Visual Studio

[1:03 - 1:25] Tim comienza haciendo clic derecho en el proyecto en Visual Studio y seleccionando Publicar. El asistente presenta varios destinos (Azure, Docker, ClickOnce), pero los pasa todos por alto y elige Carpeta. Para un utilitario personal que vive en tus propias máquinas, una publicación en carpeta es el camino más directo: produce archivos que puedes copiar donde los necesites sin ninguna infraestructura de despliegue.

Después de seleccionar el destino de la carpeta, Tim salta directamente a la página de configuraciones en lugar de ejecutar la publicación inmediatamente. Los valores predeterminados necesitan ajustes antes de que la salida coincida con lo que él desea.

Dependiente del Framework vs. Auto-Contenido

[1:25 - 2:32] La primera configuración es el modo de despliegue. Una construcción dependiente del framework asume que el SDK o runtime de .NET ya está instalado en la máquina de destino. La salida es pequeña, aproximadamente 200 kilobytes para esta aplicación, porque depende del runtime compartido que existe en tu sistema.

Un paquete autónomo contiene todo el runtime de .NET en la salida. Esto hace que el paquete sea portátil a máquinas sin .NET instalado, pero aumenta su tamaño a alrededor de 140 megabytes. Tim elige dependiente del framework porque todas las máquinas que utiliza ya tienen .NET instalado. Si estás distribuyendo una herramienta a colegas o clientes que podrían no tener el runtime, autónomo es la apuesta más segura, pero para utilidades personales el compromiso rara vez tiene sentido.

Por qué WPF y no MAUI

[2:50 - 4:10] Tim aborda los comentarios que recibió sobre el uso de WPF en lugar de MAUI para este proyecto. Su razonamiento es práctico más que ideológico. El visor de imágenes solo necesita ejecutarse en Windows. Introducir MAUI y su capa multiplataforma añade complejidad sin ofrecer ningún beneficio para una herramienta de una sola plataforma.

Más allá del argumento arquitectónico, hay un ángulo de mantenimiento. El código fuente original de Tim ha sobrevivido aproximadamente siete años a través de cuatro o cinco máquinas con cambios mínimos. Las únicas actualizaciones fueron actualizaciones de framework (de .NET Framework a .NET 8, y ahora a .NET 10). Si la utilidad se hubiera construido sobre un framework que requiere atención cada vez que Apple o Google lanzan una actualización de sistema operativo, esos siete años de operación sin intervención no habrían sido posibles. Una utilidad que cuesta más tiempo de mantener que lo que ahorra ya no te está ahorrando nada.

Publicar un solo archivo y archivos PDB

[4:59 - 6:32] Con el modo de implementación establecido, Tim habilita "Producir archivo único" y apunta a Windows x64. La publicación se completa y abre la carpeta de salida, que contiene dos archivos: el .exe y un .pdb.

Ese segundo archivo es un archivo de base de datos del programa, y vale la pena entender su función. Cuando compilas en modo Release, el compilador optimiza y renombra símbolos internos por rendimiento. El PDB mapea esos nombres optimizados de vuelta a tu base de código real, permitiéndote adjuntar un depurador al ejecutable en ejecución y establecer puntos de interrupción como si estuvieras trabajando en modo Debug. Para una aplicación de producción que sirve a clientes, deberías almacenar los archivos PDB de manera segura junto a cada versión para que puedas diagnosticar problemas después del despliegue.

Para una herramienta que construiste para ti mismo, Tim señala que el PDB no es necesario para que la aplicación funcione. Lo elimina por simplicidad, pero advierte a los espectadores que no adopten ese hábito para cualquier cosa enviada a los usuarios. El único .exe se ejecuta por sí solo sin que el PDB esté presente.

Un detalle curioso a notar: si cambias de dependiente del framework a autónomo y mantienes "archivo único" habilitado, la salida ya no es un solo archivo. Aparecen archivos de runtime adicionales junto al ejecutable. La opción de archivo único solo produce un archivo verdadero cuando se combina con una compilación dependiente del framework.

Colocando la utilidad en tu máquina

[7:17 - 7:52] Con el ejecutable en mano, Tim lo mueve a una ubicación permanente. Él usa una carpeta dedicada C:\Apps\SimpleImageViewer, una convención que mantiene las herramientas personales separadas de Archivos de Programa y fáciles de localizar. El ejecutable de 2024 todavía se ejecuta de forma idéntica en su máquina actual, lo que refuerza el punto anterior sobre la longevidad: una utilidad bien delimitada con una estructura de proyecto simple puede sobrevivir cambios de hardware y actualizaciones de sistema operativo sin modificaciones.

Agregando la herramienta al menú contextual

[7:52 - 10:21] El paso final conecta la utilidad al menú contextual de Windows Explorer. Tim modifica el Registro de Windows para agregar entradas bajo dos ubicaciones: una para hacer clic derecho en una carpeta (para que puedas abrir un directorio de imágenes) y otra para hacer clic derecho en un espacio en blanco dentro de una carpeta (para lanzar el visor en el directorio actual).

Cada entrada del registro crea un comando de shell que pasa la ruta seleccionada como un argumento de línea de comandos al ejecutable. Aquí es donde el parámetro args en el punto de entrada de la aplicación recibe su valor.

Tim proporciona un archivo .reg pero lo renombra a .txt antes de compartirlo. Esa precaución importa: al hacer doble clic en un archivo .reg inmediatamente se solicita escribir valores en el registro, y ejecutar un archivo de registro no confiable puede causar serios problemas en el sistema. Su enfoque requiere que abras el archivo, verifiques las rutas, las actualices para que coincidan con tu máquina, renombras la extensión de nuevo a .reg, y solo entonces lo ejecutes. Si alguna de esas tareas te resulta desconocida, el consejo de Tim es directo: no modifiques el registro.

Para desarrolladores cómodos con el registro, las dos entradas son sencillas. Cada uno crea un comando de shell con nombre bajo la clave adecuada, apuntando a la ruta completa de tu ejecutable con un marcador de posición %V o %1 que pasa el directorio de destino o la ruta del archivo en tiempo de ejecución. Puede ser necesario un reinicio antes de que aparezcan las nuevas entradas del menú contextual.

Resumiendo: Despliega una vez, usa para siempre

[10:21 - 10:30] Todo el proceso de despliegue consta de dos pasos: publicar en una carpeta, luego registrar el ejecutable en el menú contextual. Sin instalador, sin mecanismo de actualización, sin servicio en la nube. Para una utilidad de un solo propósito en tu propia máquina, esa simplicidad es el objetivo.

Conclusión

[10:30 - 10:40] En resumen: dotnet publish con configuraciones dependientes del marco y de archivo único produce un ejecutable liviano que puedes colocar en cualquier lugar. Un par de entradas en el registro lo convierten en una acción del menú contextual disponible en cualquier parte de Windows Explorer.

La lección que recorre todo el video es la moderación. Ajusta tu enfoque de despliegue al alcance de tu aplicación. Una utilidad construida para uso personal no necesita la misma infraestructura que un producto enviado a miles de clientes, y tratarla así solo crea trabajo de mantenimiento que erosiona el tiempo que la herramienta fue construida para ahorrar.

Consejo de ejemplo: Conserva tus archivos PDB incluso para proyectos personales. Almacénalos en la misma carpeta que el ejecutable o en un archivo cercano. Si la utilidad alguna vez se comporta inesperadamente meses más tarde, tener el PDB te permite adjuntar Visual Studio y depurar la compilación de release sin recompilar desde el origen.

Mira el video completo en su canal de YouTube y obtén más información sobre el despliegue de aplicaciones de escritorio .NET.