Vantagens de usar MSBuild ou NAnt contra correndo DEVENV.EXE a partir de linha de comando

Question

Alguém pode explicar o que vantagens existem para usar uma ferramenta como MSBuild (ou NAnt) para construir uma coleção de projetos contra correndo DEVENV.EXE a partir da linha de comando?

Um colega que eu tinha trabalhado com no passado tinha explicado que (pelo menos com versões mais antigas do Visual Studio) usando DEVENV.EXE foi muito mais lento do que as outras técnicas, mas eu não li qualquer evidência de que ou se isso agora é um ponto discutível agora que começando com 2005, o Visual Studio utiliza MSBuild sob o capô.

Eu sei que uma vantagem de usar MSBuild lhe permite construir seus projetos sem a necessidade de Visual Studio para ser instalado nas máquinas de construção, mas eu não tinha certeza se havia outros.

Answer 1

Uma das razões é que há muito mais para a construção de um produto que apenas compilá-lo. Tarefas como a criação de instalações, atualizando os números de versão, a criação de escrows, distribuindo os pacotes finais, etc. pode ser muito mais fácil por causa do que essas ferramentas (e suas extensões) proporcionar.

Quando você poderia fazer tudo isso com roteiros regulares, usando NAnt ou MSBuild dar-lhe uma estrutura sólida para fazer tudo isso. Há um monte de apoio da comunidade para ambos, incluindo tarefas adicionais que podem ser baixados (como o MSBuild Comunidade Projeto ). Além disso, há suporte para eles em numerosos terceiros e de código aberto produtos.

Se você está apenas interessado em compilar (e não todo o processo de construção), você pode encontrar um horário de benefício de MSBuild é o suporte para a construção com vários processadores .

Answer 2

A resposta óbvia a partir de minha equipe é que nem todo mundo tem visual studio instalado , em particular, nós não instalação do Visual Studio para o nosso build / servidores CI.

Answer 3

A principal razão para a utilização de uma ferramenta de construção externo como NAnt ou MsBuild é a capacidade de automatizar seu processo de construção e, assim, fornecer feedback contínuo sobre o estado do seu sistema. Também pode ser usado para cargas de coisas além de uma compilação "puro" e é aí que você realmente começar a obter valor a partir delas, é uma coisa extemamente valioso para ser capaz de construir e testar seu aplicativo com um único comando.

Você também pode começar a adicionar coisas como coleção de métricas, packinging de binários de liberação e todo tipo de coisa bacana assim.

Answer 4

No que diz respeito C # vai, devenv.exe 2005 é executado o compilador in-proc, que pode causar fora de exceções de memória para soluções consideráveis. MSBUILD resorts de lançar processo csc.exe para cada projeto. Projetos que não compilar com devenv / build funcionam bem com msbuild. Espero que gostem deste motivo.

Answer 5

Estamos experimentando a mudança de Devenv a uma ferramenta (Visual Build Pro) que usa MsBuild sob o capô e temos um "necessária referência ao assembly 'System.Drawing ..." erro para um projeto que não precisa -lo e que se baseia muito bem no Visual Studio.

Answer 6

Temos um grande sistema que consiste em C #, C ++ gerenciado e simples montagens de idade não gerenciado C ++ / dlls. Há código C ++ que depende de código gerenciado C ++ que depende de código C # que depende de código gerenciado C ++ que depende de bom e velho código C ++ (ufa!). Quando estávamos a criação de nosso ambiente de compilação automatizada alguns anos atrás, nós descobrimos que MSBuild.exe não tratar adequadamente todas as dependências que temos.

trabalhando com a Microsoft fomos capazes de resolver alguns dos problemas, mas não todos eles. Se minha memória não me falha, nós nunca poderia obter os conjuntos C # que dependiam DLLs gerenciado C ++ para construir. Então acabamos fazendo um script de construção personalizado que chamou devenv.exe na linha de comando e funcionou muito bem.

Claro, que estava com VS2005, pode ser corrigido agora, mas o roteiro ainda está trabalhando por isso não temos revisitado a questão.