Como Publicar e Implantar uma Utilidade WPF .NET

Publicando a partir do Visual Studio

[1:03 - 1:25] Tim começa clicando com o botão direito no projeto no Visual Studio e selecionando Publicar. O assistente apresenta várias opções (Azure, Docker, ClickOnce), mas ele as ignora e escolhe Pasta. Para uma ferramenta pessoal que vive em suas próprias máquinas, uma publicação em pasta é o caminho mais direto: ela produz arquivos que você pode copiar para onde precisar sem qualquer infraestrutura de implantação.

Após selecionar o alvo da pasta, Tim vai direto para a página de configurações em vez de executar a publicação imediatamente. Os padrões precisam de ajuste antes que a saída corresponda ao que ele deseja.

Dependente do Framework vs. Autossuficiente

[1:25 - 2:32] A primeira configuração é o modo de implantação. Um build dependente do framework assume que o SDK .NET ou runtime já está instalado na máquina de destino. A saída é pequena, cerca de 200 kilobytes para essa aplicação, porque depende do runtime compartilhado que existe no seu sistema.

Um build autossuficiente inclui todo o runtime .NET na saída. Isso torna o pacote portátil para máquinas sem .NET instalado, mas infla o tamanho para cerca de 140 megabytes. Tim escolhe dependente do framework porque todas as máquinas que ele usa já têm .NET instalado. Se você estiver distribuindo uma ferramenta para colegas ou clientes que podem não ter o runtime, autossuficiente é a aposta mais segura, mas para ferramentas pessoais a troca raramente faz sentido.

Por que WPF e não MAUI

[2:50 - 4:10] Tim aborda o feedback que recebeu sobre usar WPF em vez de MAUI para este projeto. Seu raciocínio é prático em vez de ideológico. O visualizador de imagens só precisa rodar no Windows. Introduzir MAUI e sua camada multiplataforma adiciona overhead sem fornecer benefícios para uma ferramenta de plataforma única.

Além do argumento arquitetônico, há um ângulo de manutenção. O código-fonte original de Tim sobreviveu por cerca de sete anos em quatro ou cinco máquinas com mudanças mínimas. As únicas atualizações foram upgrades de framework (de .NET Framework for .NET 8, e agora for .NET 10). Se a ferramenta tivesse sido construída em um framework que requer atenção toda vez que a Apple ou Google lançam uma atualização de SO, esses sete anos de operação sem intervenção não teriam sido possíveis. Uma ferramenta que custa mais tempo para manter do que economiza, não está mais economizando nada.

Publicação de Arquivo Único e Arquivos PDB

[4:59 - 6:32] Com o modo de implantação decidido, Tim habilita "Produzir arquivo único" e tem como alvo Windows x64. A publicação é concluída e abre a pasta de saída, que contém dois arquivos: o .exe e um .pdb.

Esse segundo arquivo é um arquivo de Banco de Dados de Programa, e seu papel vale a pena entender. Quando você compila em modo Release, o compilador otimiza e renomeia os símbolos internos para desempenho. O PDB mapeia esses nomes otimizados de volta para seu código-fonte real, permitindo que você anexe um depurador ao executável em execução e defina breakpoints como se estivesse trabalhando no modo Debug. Para uma aplicação de produção servindo clientes, você deve armazenar os arquivos PDB com segurança ao lado de cada lançamento para que possa diagnosticar problemas após a implantação.

Para uma ferramenta que você construiu para si mesmo, Tim observa que o PDB não é necessário para que o aplicativo funcione. Ele o deleta por simplicidade, mas adverte os espectadores para não adotarem esse hábito para nada enviado a usuários. O único .exe funciona sozinho sem a presença do PDB.

Uma peculiaridade que vale destacar: se você mudar de dependente do framework para autossuficiente e mantiver "arquivo único" habilitado, a saída não será mais um arquivo único. Arquivos adicionais do runtime aparecem ao lado do executável. A opção de arquivo único só produz um verdadeiro arquivo único quando combinada com um build dependente do framework.

Colocando a Ferramenta na Sua Máquina

[7:17 - 7:52] Com o executável em mãos, Tim o move para um local permanente. Ele usa uma pasta C:\Apps\SimpleImageViewer dedicada, uma convenção que mantém ferramentas pessoais separadas do Program Files e fáceis de localizar. O executável de 2024 ainda funciona de forma idêntica na máquina atual dele, o que reforça o ponto anterior sobre longevidade: uma ferramenta bem dimensionada com uma estrutura de projeto simples pode sobreviver a mudanças de hardware e upgrades de SO sem modificação.

Adicionando a Ferramenta ao Menu do Clique com o Botão Direito

[7:52 - 10:21] O passo final conecta a ferramenta ao menu de contexto do Windows Explorer. Tim modifica o Registro do Windows para adicionar entradas em dois locais: um para cliques com o botão direito em uma pasta (para que você possa abrir um diretório de imagens) e outro para cliques com o botão direito no espaço em branco dentro de uma pasta (para lançar o visualizador no diretório atual).

Cada entrada do registro cria um comando de shell que passa o caminho selecionado como um argumento de linha de comando para o executável. É aqui que o parâmetro args no ponto de entrada da aplicação recebe seu valor.

Tim fornece um arquivo .reg mas o renomeia para .txt antes de compartilhar. Essa precaução importa: clicar duas vezes em um arquivo .reg solicita imediatamente a escrita de valores no registro, e executar um arquivo de registro não confiável pode causar sérios problemas no sistema. Sua abordagem exige que você abra o arquivo, verifique os caminhos, atualize-os para corresponder à sua máquina, renomeie a extensão de volta para .reg, e só então execute. Se alguma disso parece desconhecido, o conselho de Tim é direto: não modifique o registro.

Para desenvolvedores familiarizados com o registro, as duas entradas são diretas. Cada um cria um comando de shell nomeado sob a chave apropriada, apontando para o caminho completo do seu executável com um marcador %V ou %1 que passa o diretório de destino ou caminho do arquivo em tempo de execução. Um reinício pode ser necessário antes que novas entradas no menu de contexto apareçam.

Concluindo: Implante Uma Vez, Use Para Sempre

[10:21 - 10:30] Todo o processo de implantação é de duas etapas: publicar para uma pasta e depois registrar o executável no menu do clique com o botão direito. Sem instalador, sem mecanismo de atualização, sem serviço em nuvem. Para uma ferramenta de propósito único na sua própria máquina, essa simplicidade é o ponto.

Conclusão

[10:30 - 10:40] Resumindo: dotnet publish com configurações dependentes de framework e de arquivo único produz um executável leve que você pode colocar em qualquer lugar. Um par de entradas de registro transforma isso em uma ação de menu de contexto disponível em qualquer lugar no Windows Explorer.

A lição que percorre todo o vídeo é restrição. Combine sua abordagem de implantação com o escopo do seu aplicativo. Uma ferramenta construída para uso pessoal não precisa da mesma infraestrutura que um produto enviado para milhares de clientes, e tratá-la dessa forma só cria trabalho de manutenção que desgasta o tempo que a ferramenta foi feita para economizar.

Dica de Exemplo: Mantenha seus arquivos PDB mesmo para projetos pessoais. Armazene-os na mesma pasta que o executável ou em um arquivo próximo. Se a ferramenta algum dia se comportar de maneira inesperada meses depois, ter o PDB permite que você anexe o Visual Studio e depure a versão de lançamento sem recompilar a partir do código-fonte.

Assista ao vídeo completo no canal dele no YouTube e ganhe mais insights sobre o desenvolvimento de aplicativos de desktop .NET.