Devo mudar de nant para msbuild?

StackOverflow https://stackoverflow.com/questions/10634

Pergunta

Atualmente uso nant, ccnet (controle de cruzeiro), svn, mbunit.Eu uso o msbuild para fazer meu sln build só porque era mais simples desembolsar.

Há algum mérito em mudar todo o meu script de construção para o MSBuild?Preciso ser capaz de executar testes, testes de estilo watir, implantação de xcopy.Isso é mais fácil?

Atualizar:Algum recurso atraente que me faria mudar do nant para o msbuild?

Foi útil?

Solução

Eu gosto do MSBuild.Um dos motivos é que os arquivos .csproj são arquivos msbuild e compilar no VS é como compilar na linha de comando.Outro motivo é o bom suporte do TeamCity, que é o servidor de CI que uso.Se você começar a usar o MSBuild e quiser fazer mais coisas personalizadas em seu processo de compilação, obtenha o Tarefas da comunidade MSBuild.Eles oferecem um monte de tarefas extras interessantes.Faz vários anos que não uso o NAnt e não me arrependo.

Além disso, como Ruben menciona, existem os Tarefas do SDC tarefas no CodePlex.

Para ainda mais diversão, existe o Pacote de extensão MSBuild no CodePlex, que inclui uma tarefa do Twitter.

Outras dicas

Meu conselho é exatamente o oposto: evite o MSBuild como uma praga.O NANT é muito mais fácil de configurar sua compilação para fazer testes automáticos, implantar em vários ambientes de produção, integrar-se ao cruisecontrol para um ambiente de entrada e integrar-se ao controle de origem.Passamos por muitos problemas com o TFS/MSBuild (usando TFSDeployer, scripts Powershell personalizados, etc.) para fazer com que ele fizesse o que pudemos fazer com o NANT pronto para uso.Não perca seu tempo.

O motivo mais convincente para usar o MSBuild (pelo menos no .NET 3.5 e posteriores) é que o mecanismo de compilação pode ser compilado simultaneamente.

Isso significa uma grande velocidade em suas compilações, pois você tem vários núcleos/processadores.

Anterior à versão 3.5, o MSBuild não fazia compilações paralelas.

Sinto que o MSBuild e o Nant são bastante comparáveis.Se você estiver usando um desses, geralmente não alternaria entre eles, a menos que houvesse um recurso atraente faltando no produto que você selecionou.

Eu pessoalmente uso o MSBuild para qualquer novo projeto, mas sua milhagem pode variar.

Espero que ajude!

Editar: @ChanChan - @Jon menciona que Nant não cria aplicativos .NET 3.5.Isso pode ser motivo suficiente para alterá-los ou, pelo menos, usá-los em paralelo.À medida que avancei mais para o MSBuild, provavelmente não sou a pessoa mais informada para destacar quaisquer outros obstáculos com qualquer uma das tecnologias.

Editar: Parece que Nant agora cria aplicativos .NET 3.5.

O NAnt existe há mais tempo e é um produto consideravelmente mais maduro e também mais fácil de usar na IMO.Há muito conhecimento da comunidade disponível para ser explorado, e também é multiplataforma, caso você esteja interessado em criar aplicativos que possam ser executados em Mono, bem como em .NET e Silverlight.Pronto para uso, ele faz muito mais do que o MSBuild.Ah, sim, e você pode ligar para o MSBuild do NAnt (OK, do NAntContrib) :-)

Do lado negativo, o NAnt e o seu projecto irmão NAntContrib parecem ter estagnado, com a actualização mais recente a ocorrer no final de 2007.

As principais vantagens que vejo no MSBuild é que ele vem com o .NET Framework, portanto é um produto a menos para instalar;e há um desenvolvimento mais activo em curso (embora em locais que possam acompanhar o NAnt mais antigo).

Pessoalmente, acho sua sintaxe um pouco mais difícil de entender, mas tenho certeza de que a exposição contínua ao ti tornaria as coisas mais fáceis.

Conclusão?Se você estiver trabalhando com scripts NAnt existentes, continue com eles, não vale a pena se preocupar com a portabilidade.Se você está iniciando um novo projeto e se sente aventureiro, experimente o MSBuild.

Também mudamos de nant para msbuild.Se sua compilação for bastante padrão, você não terá muitos problemas para configurá-la, mas se tiver muitas tarefas de compilação específicas, terá que escrever tarefas personalizadas de compilação do ms, pois há muito menos tarefas personalizadas para o msbuild.

Se você quiser exibir resultados de construção razoáveis, terá que mexer com registradores personalizados, etc.Toda a construção da equipe não está tão madura quanto nant.

Mas o benefício real é a integração com o controle de origem e os serviços de relatórios do TFS.Se você não estiver usando o TFS como sistema de controle de origem, não vale a pena.

  • Não mude a menos que tenha um motivo muito convincente (pelo menos).
  • NAnt é de código aberto e se não fosse eu não seria capaz de personalizar nosso sistema de compilação, o MSBuild não é.
  • O NAnt pode executar facilmente o MSBuild, não tenho certeza sobre o contrário.
  • Os scripts do MSBuild já foram escritos para você se você usar o VS2005 ou mais recente (os arquivos do projeto são Arquivos MSBuild.)
  • Se você usa o NAnt e usa o VS para editar arquivos, definições e configurações do projeto, você terá que escrever uma ferramenta de conversão/sincronização para atualizar seus arquivos NAnt a partir dos arquivos do projeto VS.

@Brad Leach

Geralmente, eu não alternaria entre eles, a menos que houvesse um recurso atraente faltando

quais são os motivos convincentes para usar o msbuild?existem contras?

Até agora estou recebendo um bom "não, não se preocupe" com sua resposta.

Acho que eles são relativamente comparáveis ​​tanto em recursos quanto em facilidade de uso.Só por ser baseado em C #, acho o msbuild mais fácil de trabalhar do que o nants, embora isso não seja um motivo convincente para mudar.

O que exatamente nant não está fazendo por você?Ou você está apenas esperando que haja algum recurso interessante que possa estar perdendo?:)

Uma coisa muito legal sobre C# é que se você tiver o framework .net, terá tudo o que precisa para executar o msbuild.Isso é fantástico quando você está trabalhando em grandes equipes/projetos e há rotatividade de pessoas/hardware.

Pessoalmente, prefiro SCons a ambos :)

O principal motivo pelo qual ainda uso nAnt em vez de msbuild para minhas compilações automatizadas é que tenho um controle mais granular sobre minhas compilações.Devido ao msbuild usar o csproj com seu arquivo de construção, toda a fonte desse projeto é compilada em um assembly.O que faz com que eu tenha muitos projetos na minha solução para projetos grandes onde estou separando lógica.Bem, com o nant, posso organizar minha construção onde posso compilar o que quero em vários assemblies de um projeto.

Gosto dessa rota porque evita que eu tenha muitos arquivos de projeto na minha solução.Posso ter um projeto com pastas dividindo as camadas e depois usar o nant para construir cada camada em sua própria montagem.

No entanto, eu uso nant e msbuild em conjunto para algumas tarefas de construção, como a construção de aplicativos WPF.É muito mais fácil compilar um aplicativo WPF com o destino msbuild no nant.

Para finalizar, o ponto da minha resposta é que gosto de usá-los lado a lado, mas quando uso o msbuild nesta configuração, geralmente é para compilação direta, sem executar nenhuma tarefa de automação de compilação, como copiar arquivos para um diretório, gerar a documentação de ajuda ou executando meus testes de unidade, por exemplo.

Na verdade, ainda estou tentando resolver essa questão sozinho, mas há um grande bônus para o MSBuild aqui:usando o mesmo arquivo de construção para integração contínua local chamando msbuild.exe diretamente, ao mesmo tempo que pode usar a integração contínua do lado do servidor do VSTS com o mesmo arquivo de construção (embora provavelmente propriedades/configurações diferentes).

ou sejaem comparação com o suporte do TeamCity para scripts MSBuild, VSTS apenas suporta scripts MSBuild!Já resolvi isso no passado executando o NAnt do MSBuild;Já vi outras pessoas recomendarem essa prática e também o contrário, mas me parece desajeitado, então tento não fazê-lo se puder evitá-lo.Portanto, quando você estiver usando "a pilha completa da Microsoft" (VSTS e TFS), sugiro apenas usar os scripts do MSBuild.

Nant tem mais recursos prontos para uso, mas MSBuild tem uma estrutura fundamental muito melhor (pedras de metadados de itens), o que torna muito mais fácil construir scripts MSBuild reutilizáveis.

O MSBuild demora um pouco para entender, mas depois de feito isso é muito bom.

Materiais de aprendizagem:

Não vejo motivo para mudar.O próprio MsBuild bloqueia você na estrutura que você está usando.Se você usar o NAnt, poderá usá-lo em vários frameworks e desembolsar para o msbuild para realmente fazer a tarefa de construção para você.

Sou fã do NAnt nesse aspecto, porque ele separa um pouco você do framework.

Eu criei uma estrutura que coloca convenções em compilações automatizadas e a construí no NAnt.Chama-se UppercuT e é o Build Framework incrivelmente fácil de usar.

Construções automatizadas tão fáceis quanto (1) nome da solução, (2) caminho de controle de origem, (3) nome da empresa para a maioria dos projetos!

http://code.google.com/p/uppercut/

Algumas boas explicações aqui: Gancho

A integração do MSBuild com o Visual Studio oferece aos programadores menos atrito para usar o sistema de compilação.Tudo se resume principalmente a eles terem que ir em "Construir Solução" e tudo funcionar, em vez de ter que usar Etapas de Construção Personalizadas e outras coisas, ou, pior, forçar os desenvolvedores a construir lançando algum tipo de script externo.

Agora, eu costumo preferir o MSBuild ao NAnt porque é mais simples.Claro, o NAnt tem muito mais recursos, é mais poderoso, etc., mas pode rapidamente sair do controle.Se você e seus engenheiros de construção tiverem disciplina para manter os scripts NAnt simples, então está tudo bem.No entanto, já vi muitos sistemas baseados em NAnt irem para o sul, a ponto de ninguém entender mais o que estão fazendo, e não há nenhuma maneira real de depurá-los além de fazer o equivalente a um bom e velho printf.No momento em que você começa a usar alguma instrução if/else ou loop for, é aí que, IMHO, começa a cheirar.

Por outro lado, o MSBuild possui uma base sólida baseada em metadados e uma sintaxe menos detalhada.Sua simplicidade (ou falta de recursos...dependendo de como você vê) força você a escrever lógica em código .NET por meio de novas tarefas, em vez de escrever lógica em marcação XML.Isso incentiva a reutilização e, acima de tudo, permite que você depure seu sistema de compilação em um depurador real.

O único problema com o MSBuild é o bug não tão ocasional (especialmente na primeira versão) ou comportamento obscuro (embora documentado).E, se esse é o tipo de coisa que realmente te incomoda, estar vinculado à Microsoft.

Mudei de NANT para MSBuild.O projeto está rodando em .Net 4.0.

Minha experiência em Nant foi boa.O projeto meio que morreu.E quando o .Net 4.0 apareceu, era hora de reavaliar o processo de construção.

Desde que o Nant foi lançado pela última vez, o MSBuild evoluiu bastante.Neste ponto, o MSBuild é o caminho a percorrer.É fácil de usar e possui muitas extensões.Reescrevi meus roteiros de Nant em um dia e meio.O script MSBuild tem 1/3 do tamanho dos scripts Nant.

Grande parte do trabalho no roteiro de Nant consistia em configurar os diferentes ambientes.No MsBuild/.Net 4.0 está integrado.

Eu uso o MSBuild ao lado Nant, porque a versão atual do Nant ainda não pode compilar aplicativos .NET 3.5 (o mesmo acontecia quando o .NET 2.0 foi lançado).

A única razão que vejo para usar o msbuild é se você gostaria de usar um servidor de compilação automatizado, como o controle de cruzeiro.Se você não vai mudar, eu deixaria isso como está.

Eu uso o Nant e adoro.Eu usei o MSBuild e odiei por causa destes:

  1. A Microsoft força você a seguir seu próprio procedimento de construção que é tão intrínseco às suas ações que pelo menos não consegui fazê-lo funcionar (tive que compilar o NET1.1, então tive que misturar Nant e MSbuild).Sei que você pode criar seu próprio arquivo MSBuild, mas achei complexo de entender e manter.

  2. ItemTypes para realizar operações de arquivo são muito difíceis de seguir.Você pode fazer com que o Nant faça exatamente as mesmas coisas e de forma muito mais fácil e direta (tive que criar uma lista ItemType e depois passar para as operações do arquivo).

  3. No MsBuild você tem que criar sua própria dll de tarefa, no Nant você pode fazer isso ou pode incorporar código C# em seu script, então é muito mais fácil avançar e apenas construir o projeto inteiro.

  4. Nant funciona com Net1.1, MsBuild não.

  5. Para instalar o nant, posso até descompactar e localizar dentro do meu próprio repositório para executá-lo.Instalar o MsBuild é muito mais difícil, pois depende de muitas coisas do Visual Studio, etc.(talvez eu esteja errado aqui, mas isso parece ser a verdade).

Bom, essas são minhas opiniões...

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top