23 11 2016
Como incrementar o número da versão automaticamente no Visual Studio
Imagine a seguinte situação: você está de boa implementando uma nova funcionalidade no seu projeto quando, do nada, o telefone toca. Um dos clientes do seu sistema está reclamando de um bug que você já corrigiu faz um tempão. E agora? Será que o bug está de volta? Ou será que o cliente está com uma versão antiga da aplicação, na qual o bug ainda não tinha sido corrigido?
É por essas e outras que é importantíssimo controlarmos o número da versão dos nossos assemblies. Dessa forma, conseguimos saber se o usuário já está utilizando a última versão da aplicação. Porém, se você já tentou controlar o número da versão manualmente, você sabe que essa é uma tarefa um tanto quanto chata. Não é à toa que o Visual Studio tem uma funcionalidade de cálculo automático do número de build e revisão. Entretanto, essa funcionalidade do Visual Studio não é nada flexível, uma vez que não conseguimos incrementar o número da versão começando em zero (ele usa uma data e hora fixas como base).
Mas, não se preocupe. Como de costume, existe uma extensão do Visual Studio que implementa essa possibilidade para os nossos projetos. Quer conferir tudo sobre às versões de assemblies no mundo .NET? Então, vem comigo!
O arquivo AssemblyInfo
Sempre que criamos um novo projeto no Visual Studio, ele cria automaticamente um arquivo chamado AssemblyInfo.cs (ou AssemblyInfo.vb no caso de projetos VB.NET). Em projetos C#, conseguimos abrir esse arquivo facilmente pelo Solution Explorer, expandindo o nó “Properties“:
Como falei no parágrafo anterior, no VB.NET nós temos também o arquivo AssemblyInfo. Porém, nós não conseguimos acessá-lo através do Solution Explorer. Para abrirmos o arquivo AssemblyInfo.vb, temos que navegar até o subdiretório “My Project” do nosso projeto através do Windows Explorer:
Já é de se imaginar que esse arquivo armazena diversas informações sobre o assembly – afinal, ele se chama “AssemblyInfo“. Uma das informações que encontramos nesse arquivo é a versão do assembly. Mas, não pense que nós só temos um número de versão para cada assembly. Para complicar as coisas, nós temos a possibilidade de definir 3 (!!) números de versões diferentes.
Primeiramente, temos a versão do assembly propriamente dita, definida com o atributo “AssemblyVersion“:
Em seguida, temos o número da versão do “arquivo do assembly“, que pode ser definida com o atributo “AssemblyFileVersion“:
Por fim, temos um outro número de versão que pouca gente conhece: o número da versão do produto! Essa versão pode ser definida com o atributo “AssemblyInformationalVersion“:
As versões do assembly e do “arquivo do assembly” também podem ser definidas nas propriedades do projeto, clicando no botão “Assembly Information“:
A versão mais importante é a versão do assembly. Se a versão do “arquivo do assembly” estiver em branco, o número da versão do assembly será considerado no seu lugar. O mesmo acontece com a versão do produto – se ela estiver em branco, a versão do “arquivo do assembly” será utilizada. Ou seja, a hierarquia dos números de versões é: versão do assembly => versão do arquivo do assembly => versão do produto.
Além disso, como a descrição do arquivo AssemblyInfo já explica, os números de versão são compostos por quatro seções:
– Primeira seção = versão principal
– Segunda seção = versão secundária
– Terceira seção = número da build
– Quarta seção = número da revisão
Descobrindo o número da versão em tempo de execução
Não é nada difícil descobrirmos o número da versão em tempo de execução. A versão do assembly pode ser acessada através da propriedade Version do assembly. Já as outras versões podem ser acessadas através da classe FileVersionInfo. Por exemplo, em um projeto do tipo “Console Application“, o código para pegarmos os três tipos de versão e imprimirmos no console ficaria assim:
// C# string assemblyVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString(); string fileVersion = System.Diagnostics.FileVersionInfo.GetVersionInfo(System.Reflection.Assembly.GetExecutingAssembly().Location).FileVersion; string productVersion = System.Diagnostics.FileVersionInfo.GetVersionInfo(System.Reflection.Assembly.GetExecutingAssembly().Location).ProductVersion; Console.WriteLine(string.Format("Assembly Version: {0}", assemblyVersion)); Console.WriteLine(string.Format("File Version: {0}", fileVersion)); Console.WriteLine(string.Format("Product Version: {0}", productVersion));
' VB.NET Dim AssemblyVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString() Dim FileVersion = System.Diagnostics.FileVersionInfo.GetVersionInfo(System.Reflection.Assembly.GetExecutingAssembly().Location).FileVersion Dim ProductVersion = System.Diagnostics.FileVersionInfo.GetVersionInfo(System.Reflection.Assembly.GetExecutingAssembly().Location).ProductVersion Console.WriteLine(String.Format("Assembly Version: {0}", AssemblyVersion)) Console.WriteLine(String.Format("File Version: {0}", FileVersion)) Console.WriteLine(String.Format("Product Version: {0}", ProductVersion))
Por padrão, a versão do assembly vem configurada como “1.0.0.0” quando criamos um projeto novo no Visual Studio. Dessa forma, o resultado da execução desse código para um projeto feito “do zero” deve ser:
Atenção! Se o seu projeto tiver mais de um assembly (por exemplo, um projeto com um “exe” e várias “dlls“), esse código retornará a versão do assembly onde o código está sendo executado. Ou seja, se você colocar esse código em um assembly que não seja o “exe“, pode ser que o número retornado não seja o que você está esperando. Se você quiser recuperar explicitamente a versão do executável principal da aplicação, substitua a chamada de “GetExecutingAssembly” por “GetEntryAssembly“.
Incrementando o número da build e revisão utilizando asterisco (*)
O próprio Visual Studio possui um mecanismo de atualização automática do número de versão a cada build. Porém, como veremos a seguir, ele não é nada flexível.
A opção que temos no Visual Studio possibilita que incrementemos automaticamente o número da build ou o número da revisão (ou ambos). Para fazer isso, utilizamos um asterisco (*) na terceira ou quarta seção do número da versão. Por exemplo, se utilizarmos o asterisco na última seção, este será o resultado:
Já se utilizarmos o asterisco no número da build, este será o resultado:
Se utilizamos o asterisco no número da build, nós não podemos colocar um número fixo no número da revisão. Ou seja, ao escolhermos fazer o incremento automático do número da build, o número da revisão também terá que ser obrigatoriamente incrementado de forma automática.
Porém, você viu que o Visual Studio utilizou uns valores bastante esquisitos para o número da build e revisão? Pois é, os números não serão incrementados de um em um, mas sim, utilizando uma lógica pré-estabelecida.
Ao utilizarmos asterisco no número da build, ela será incrementada diariamente. O valor atribuído será a diferença de dias entre hoje e o dia 1 de janeiro de 2000. Você pode confirmar isso fazendo a conta no Excel:
Para o número da revisão, o Visual Studio considerará a quantidade de segundos desde a meia noite do dia atual. Ou seja, para cada compilação, o assembly receberá um número de revisão diferente.
Esse sistema de numeração automática do Visual Studio até que é legalzinho e muito fácil de utilizar, mas, como falei anteriormente, ele não é nada flexível. Se quisermos criar uma metodologia de incremento que não considere a data/hora, mas sim, um incremento começando com o número “1“, nós teríamos que fazer o controle manualmente.
Extensão Automatic Versions
Para nossa sorte, o Visual Studio é extremamente extensível. Não sei se você já deu uma olhada no Visual Studio Gallery, mas, tem extensão para tudo quanto é coisa! Uma extensão muito útil no que diz respeito ao incremento de versões é a Automatic Versions.
Ao instalarmos essa extensão, uma nova opção será adicionada no menu “Tools” do Visual Studio:
Ao clicarmos nesse item, veja só que legal:
Note que podemos configurar números de versões globalmente, para a solução ou para projetos específicos dentro da solução. Por exemplo, para configurarmos o nosso projeto de forma que o número da revisão seja incrementado em cada compilação (começando em “1“), fazemos o seguinte:
Feito isso, temos que voltar nas propriedades do projeto para removermos o asterisco que colocamos anteriormente no número da build:
Em seguida, se recompilarmos o nosso projeto, o número da revisão será incrementado automaticamente:
Para cada vez que recompilarmos o projeto, o número da revisão será incrementado em “1“. Legal, não? Pois saiba que a extensão Automatic Versions disponibiliza diversas outras opções para numerarmos os nossos assemblies:
Por exemplo, se quisermos que o número da versão tome como base a data e hora da compilação, basta configurá-lo da seguinte maneira:
E esse seria o resultado:
Concluindo
Uma vez que começamos a distribuir os nossos aplicativos para os nossos clientes, é importante fazermos o controle do número da versão. Dessa forma, fica fácil saber qual versão o usuário está executando, sem termos que ficar olhando a data dos arquivos.
O controle do número da versão dos nossos assemblies pode obviamente ser feito de maneira manual, porém, isso não é nada prático. Por isso, o Visual Studio traz consigo a possibilidade de incrementarmos automaticamente o número da build e o número da revisão para cada compilação. Entretanto, essa funcionalidade do Visual Studio tem como base uma data e hora fixas, fazendo com que a versão dos nossos assemblies fique um tanto quanto esquisitas.
Para fazermos com que o número da versão seja incrementado em cada processo de compilação, podemos utilizar a extensão chamada Automatic Versions. Essa extensão possibilita definirmos incrementos automáticos da versão ou até mesmo lógicas mais complexas (como a utilização da data/hora da compilação como versão do assembly).
No artigo de hoje você conferiu todas essas opções de numeração de versões dos nossos assemblies com o Visual Studio. E você? Como você faz a numeração dos assemblies do seu projeto? Manualmente? Utilizando o incremento do Visual Studio? Ou quem sabe utilizando uma extensão para fazer isso de forma automática? Compartilhe os detalhes das suas estratégias de numeração de versão nos comentários!
Por fim, convido você a inscrever-se na minha newsletter. Ao fazer isso, você receberá um e-mail toda semana sobre o artigo publicado e ficará sabendo também em primeira mão sobre o artigo da próxima semana, além de receber dicas “bônus” que eu só compartilho por e-mail. Inscreva-se utilizando o formulário logo abaixo.
Até a próxima!
André Lima
Image by Pixabay used under Creative Commons
https://pixabay.com/en/data-configure-organize-27652/
Como imprimir um formulário no Windows Forms com C# e VB.NET? Trabalhando com múltiplas tabelas no Report Viewer através da expressão Lookup
Muito interessante este artigo!
Olá Ronaldo, muito obrigado pelo comentário! Fico feliz que você tenha gostado do artigo.. :)
Abraço!
André Lima
Muito bom!
Não sabia como era feito o cálculo. Gostei da extensão também. Achei bem mais flexível!
Parabéns pelo artigo.
Olá Marco, muito obrigado pelo comentário!
Pois é, essa extensão é realmente bem bacana.. Dá para controlar bem melhor os números das versões com ela.. :)
Um grande abraço e uma ótima semana aí pra você!
André Lima
André, seguindo sua experiência, qual método de incrementação vc mais recomenda? Esse método de incrementar um inteiro a partir do 1 é legal, mas como não conheço outros, pode ser que exitam ideias melhores.
Olá Tony!
Cara, isso vai muito da preferência pessoal e da quantidade de releases que são geradas por dia.. Eu particularmente gosto de utilizar um número fixo para Major Version, incrementado de forma manual quando alguma funcionalidade muito grande é adicionada no aplicativo.. Dessa forma você teria versão 1.*, 2.*, etc.. E as outras partes da versão eu gosto de utilizar a data, só para ter uma base de quão antiga é a versão que o cliente está utilizando.. Ou seja, um número de versão típico ficaria assim: 4.2016.12.13..
Mas, mais uma vez, não tem um jeito certo ou errado para numerar as versões.. Vai mais da sua preferência pessoal mesmo..
Abraço!
André Lima
Mais uma vez amigo, parabéns pelas matérias interessantes e pela ótima didática.
Obrigado mais uma vez, Charles! Se ficar com alguma dúvida em um dos artigos ou se tiver alguma sugestão de temas para outros artigos, é só entrar em contato..
Abraço!
André Lima
[…] disponível ou não. Caso você não saiba, eu já publiquei um artigo uns tempos atrás mostrando como gerenciar números de versão em projetos .NET. O código apresentado acima é uma versão simplificada do código elaborado no artigo sobre […]
Cada vez mais animado com seus posts. Ótimos para o dia a dia de desenvolvedores e testers !
Abraço
Valeu João Victor! Muito obrigado por acompanhar as publicações.. Qualquer dúvida é só entrar em contato..
Abraço!
André Lima
Sua didática é muito boa, a qualidade do conhecimento agregado é ótima tb e o grau de utilidade do artigo é pra lá de alto!
Olá Adrian, muito obrigado pelo comentário! Fico feliz por você ter gostado do estilo do artigo.. :)
Abraço!
André Lima
Mais um post Sensacional, estava procurando por isso mesmo… Obrigado por ler nossos pensamentos.
Olá Fabio, muito obrigado pelo comentário! Fico feliz que você tenha gostado..
Abraço!
André Lima
Olá André,
Parabéns pelo artigo! Uma pergunta: Como faria esse controle de versão num projeto que está no github e com vários programadores trabalhando nele?
Olá Sommus!
Cara, sinceramente não sei como você poderia controlar a versão nesse caso, uma vez que o git não é centralizado, o que torna bem difícil a manutenção de um número de versão global que fosse válido para todo mundo..
Tem uma thread no StackOverflow onde é dada a sugestão de utilizar o hash do commit como versão.. Veja se te ajuda:
Creating a .NET incrementing assembly build version in Git
Abraço!
André Lima
Muito interessante esse assunto.
Parabéns….
Olá Rafael! Muito obrigado pelo comentário! Fico feliz que você tenha gostado..
Abraço!
André Lima