NAnt ou MSBuild, qual escolher e quando?

Estou ciente de que existem outras perguntas relacionadas ao NAnt e MSBuild no Stack Overflow, mas não consegui encontrar uma comparação direta entre os dois, e aqui está a questão.

Quando alguém deve escolher o NAnt em vez do MSBuild? Qual é o melhor para quê? O NAnt é mais adequado para projetos domésticos / de código aberto e o MSBuild para projetos de trabalho? Qual é a experiência com qualquer um dos dois?

Eu fiz uma investigação semelhante esta semana. Aqui está o que eu consegui determinar:

NAnt:

• Plataforma cruzada (suporta Linux / Mono). Pode ser útil para instalar um site em vários destinos (ou seja, Linux Apache e Windows IIS), por exemplo.
• 95% de sintaxe semelhante ao Ant (fácil para os usuários atuais do Ant ou construtores de Java buscarem)
• Integração com o NUnit para executar testes de unidade como parte da compilação e com o NDoc para produzir documentação.

MSBuild:

• Incorporado ao .NET.
• Integrado ao Visual Studio
• Fácil de começar com o MSBuild no Visual Studio - tudo nos bastidores. Se você quiser se aprofundar, pode editar manualmente os arquivos.

Diferenças subjetivas: (YMMV)

• A documentação do NAnt é um pouco mais direta. Por exemplo, a Referência de Tarefas do MSBuild lista "Tarefa Csc - Descreve a tarefa Csc e seus parâmetros." (Obrigado pela "ajuda"?), Em comparação com a Referência da tarefa NAnt "programas csc - Compila C #". ATUALIZAÇÃO: Notei que a documentação do MSBuild foi aprimorada e está muito melhor agora (provavelmente a par do NAnt).
• Não é fácil descobrir como editar a fonte do script de compilação (arquivo de projeção *. *) Diretamente do Visual Studio. Com o NAnt, apenas o Visual Studio trata o script .build como um arquivo XML.
• Aparentemente, no Visual Studio, os projetos de aplicativos da Web não recebem um arquivo *. * Proj por padrão, por isso tive muita dificuldade em descobrir como fazer o MSBuild rodar no meu para criar um script de implantação.
• O NAnt não é interno ao Visual Studio e precisa ser adicionado, com um suplemento ou como uma "ferramenta externa". É um pouco difícil de configurar.
• (Editar :) Um dos meus colegas de trabalho trouxe isso à tona - se você deseja configurar uma máquina de compilação usando o CruiseControl para integração contínua, o CruiseControl integra-se perfeitamente ao NAnt. ATUALIZAÇÃO: CruiseControl também tem uma tarefa MSBuild .
• Por favor, veja os comentários abaixo para uma discussão completa e atualizada das diferenças subjetivas.

Um dos principais atrativos do MSBuild para mim (nas plataformas Windows) é que ele faz parte do próprio .NET. Isso significa que qualquer máquina Windows que esteja atualizada com o Windows Update terá o MSBuild disponível. Adicione a isso o fato de o compilador C # também fazer parte do próprio .NET e você ter uma plataforma que pode criar projetos em máquinas limpas. Não é necessário instalar o gigante do Visual Studio. O NAnt, por outro lado, precisa ser explicitamente instalado antes que uma compilação possa ser acionada.

Apenas para constar, usei NMake, Make, Ant, Rake, NAnt e MSBuild em construções não triviais do passado (nessa ordem). Meu favorito é o MSBuild, sem dúvida (e eu não sou a favor porque "é isso que o Visual Studio usa"). IMHO, é uma ferramenta de construção muito subestimada.

Eu compararia NAnt x MSBuild à diferença entre programação procedural e funcional. NAnt é bastante direto e você consegue o que vê. O MSBuild, por outro lado, requer um pouco mais de reflexão. A curva de aprendizado é mais acentuada. Mas uma vez que você "entende", pode fazer coisas incríveis com ele.

Portanto, eu recomendaria olhar para o MSBuild se você também se interessar por programação de estilo funcional ou lógico - se estiver disposto a investir um pouco de tempo e esforço antes de ver resultados tangíveis (é claro, eu também acredito fortemente que o investimento eventualmente compensa e você pode fazer coisas mais poderosas com mais eficiência).

Pessoalmente, eu uso os dois - para o mesmo projeto.

O MSBuild é ótimo na criação de soluções e projetos do Visual Studio - é para isso que ele foi feito.

NAnt é mais facilmente editável à mão, na minha opinião - principalmente se você já conhece o Ant. O NAnt pode chamar o MSBuild com muita facilidade com o NAntContrib. Então, eu crio manualmente um script NAnt para fazer coisas como copiar arquivos construídos, limpar etc - e chamo o MSBuild para fazer a parte real "transformar meu código-fonte C # em assemblies".

Se você quiser um exemplo disso, veja meu arquivo de construção de Buffers de Protocolo . (Eu não diria que é um fabuloso script NAnt, mas funciona.)

O NAnt possui mais recursos prontos , mas o MSBuild possui uma estrutura fundamental muito melhor (rochas de metadados do item), o que facilita a criação de scripts reutilizáveis ​​do MSBuild.

O MSBuild leva um tempo para entender, mas uma vez feito, é muito bom.

Materiais de aprendizagem:

• Por dentro do Microsoft Build Engine: Usando o MSBuild e o Team Foundation Build
  por Sayed Ibrahim Hashimi (janeiro de 2009)
• Implantando aplicativos .NET: aprendendo MSBuild e ClickOnce por Sayed
  por Y. Hashimi (setembro de 2008)

KISS = Use MSBuild.

Por que adicionar outra coisa à mistura quando você tem algo que fará um trabalho razoável fora da caixa? Quando o MSBuild chegou, NAnt morreu. E o Mono terá uma implementação do MSBuild ( xbuild ).

DRY = Use MSBuild.

Pergunte a si mesmo o que você quer de um sistema de compilação? Eu quero um sistema de compilação que também seja usado pelo meu IDE, em vez de manter duas configurações diferentes.

Pessoalmente, eu adoraria ouvir alguns argumentos reais para o NAnt, porque simplesmente não consigo pensar em nenhum que realmente retenha água.

Uma coisa que notei que vários pôsteres mencionaram foi a necessidade de editar manualmente os arquivos .csproj (ou .vbproj, etc.).

O MSBuild permite a personalização desses arquivos. * Proj através do uso de arquivos .user. Se eu tiver um projeto chamado MyCreativelyNamedProject.csproj e quiser personalizar as tarefas do MSBuild, posso criar um arquivo chamado MyCreativelyNamedProject.csproj.user e usar o CustomBeforeMicrosoftCommonTargets e CustomAfterMicrosoftCommonTargets para personalizar esses arquivos.

Além disso, o NAnt e o MSBuild podem ser personalizados para o conteúdo do coração por meio de tarefas personalizadas do MSBuild e por extensões do NantContrib.

Portanto, o uso do NAnt ou MSBuild realmente se resume à familiaridade:

• Se você já conhece o Ant, use o NAnt. A curva de aprendizado será muito fácil.
• Se você não estiver familiarizado com nenhuma das ferramentas, o MSBuild já estará integrado ao Visual Studio e não precisará de ferramentas adicionais.

Também vale a pena acrescentar que é garantido que o MSBuild funcione com todas as novas versões do .NET e Visual Studio assim que forem lançadas, enquanto o NAnt pode ter algum atraso.

Eu uso os dois porque meus scripts NAnt chamam MSBuild. Meu principal motivo para ficar com NAnt é o isolamento . Deixe-me explicar por que sinto que isso é importante:

1. Adicionando dependências ao seu projeto. O arquivo de construção NAnt é estranho ao Visual Studio (no meu caso, considero isso um profissional), portanto, o Visual Studio não tenta fazer nada com ele. As tarefas do MSBuild são incorporadas para fazer parte da solução e podem se referir a outras tarefas do MSBuild. Recebi o código fonte de outra pessoa apenas para descobrir que não consegui construir, porque as tarefas da comunidade MSBuild não foram instaladas. O que acho particularmente frustrante é que o Visual Studio simplesmente não criou e gerou muitos erros que me fizeram perder tempo na depuração. Isso, apesar do fato de que a compilação solicitada poderia ter avançado (como uma compilação de depuração, por exemplo) sem alguns dos extras da tarefa MSBuild. Resumindo: não gosto de adicionar dependências ao meu projeto se puder evitá-lo .

2. Não confio no Visual Studio na medida em que pude lançar sua equipe de desenvolvimento. Isso remonta aos primeiros dias do Visual Studio, quando massacrava meu HTML. Ainda não uso o designer, por exemplo (em uma conferência recentemente, descobri que colegas fizeram o mesmo). Eu descobri que o Visual Studio pode estragar dependências e números de versão no arquivo DLL (não consigo replicar isso, mas aconteceu em um projeto de forma consistente e causou muita dor e perda de tempo). Eu recorri a um procedimento de compilação que usa o Visual Studio para compilar apenas no modo de depuração. Para produção, eu uso o NAnt para controlar tudo externamente . O Visual Studio não pode mais interferir se eu criar usando o NAnt.

PS: Sou desenvolvedor web e não desenvolvo o Windows Forms.

Embora eu não esteja muito familiarizado com o MsBuild, tenho a impressão de que algumas das principais diferenças de ambos os lados podem ser complementadas por adições:

• MsBuildTasks
• NantContrib

Recentemente, tive que construir um projeto do Silverlight em Nant. Eu descobri que a vida seria mais fácil se eu fizesse isso com o MsBuild - acabei chamando uma tarefa MsBuild de dentro de um script Nant, então suponho que não seja muito fora do comum misturar e combinar os dois.

Além disso, suponho que seja uma questão de preferência pessoal - obviamente, você pode gerenciar algumas / a maioria das funcionalidades do MsBuild no Visual Studio, se é isso que você gosta. Nant parece mais flexível e mais adequado se você preferir escrever scripts manualmente e, se você vem do mundo Java, provavelmente estará em casa com ele.

Acabei usando os dois. Ao redesenhar nosso sistema de construção, eu estava enfrentando um problema complicado. Ou seja, eu não conseguia me livrar do .vcproj (e da família) porque todo mundo estava usando o VS para atualizar os arquivos, as configurações e os projetos do projeto. Portanto, sem um processo enorme de duplicação e propenso a erros, não poderíamos basear nosso sistema de criação em um novo conjunto de arquivos.

Por esse motivo, decidi manter os arquivos 'proj' do VS e usar o MSBuild (eles são arquivos do MSBuild, pelo menos o VS2005 e o VS2008 usam arquivos de projeto do MSBuild). Para todo o resto (configuração personalizada, teste de unidade, embalagem, preparação de documentação ...) usei o NAnt.

Para integração contínua, usei o CruiseControl. Por isso, tínhamos scripts CC que acionavam os trabalhos do NAnt, que para a construção do MSBuild usado.

Uma observação final: o MSBuild NÃO suporta projetos de instalação! Então, você está preso ao ligar para o DevEnv.com ou ao usar o Visual Studio diretamente. Foi o que acabei fazendo, mas desativei o projeto de instalação por padrão de todas as configurações da solução, já que os desenvolvedores normalmente não precisariam compilá-los e, se o fizerem, eles podem selecionar manualmente.

Recentemente, mudei do NAnt para o MSBuild por causa de sua capacidade de criar soluções VS. Eu ainda uso o NAnt ocasionalmente.

Você também pode conferir as Tarefas da Comunidade MSBuild, que são como NAntContrib.

A documentação e os tutoriais disponíveis para o NAnt facilitam o aprendizado de scripts de construção com o NAnt. Depois de pegar o jeito do NAnt e criar scripts de construção, comecei a traduzir esse conhecimento para o MSBuild (fiz o X no NAnt, como faço o X no MSBuild?). A documentação da Microsoft geralmente assume um nível bastante alto de conhecimento antes de ser útil.

O motivo da mudança do NAnt para o MSBuild é porque o MSBuild é mais atual. Infelizmente, a última versão do NAnt foi em 8 de dezembro de 2007, enquanto o MSBuild 4.0 (.NET 4.0) não está muito longe. Parece que o projeto NAnt morreu.

Se você encontrar uma boa documentação para alguém que está começando a aprender a criar scripts de compilação usando o MSBuild, pule o NAnt e vá direto para o MSBuild. Se o NAnt lançar um novo lançamento, eu consideraria ficar com o NAnt, mas eles estão atrasados ​​agora.

Nós usamos os dois. O NAnt é responsável por todo o material de "script", como copiar, implantar no IIS , criar pacotes e o MSBuild é responsável pela criação da solução. Em seguida, podemos evitar problemas com o .NET 4.0 não suportado por uma nova versão do NAnt.

NAnt também é mais escalável. Se queremos migrar os scripts de implantação para os servidores de produção, copiamos apenas o arquivo de compilação e instalamos uma versão adequada do .NET - sem problemas do Visual Studio com arquivos csproj :)

O YDeliver by Manoj é um framework de construção construído sobre o PSake. Ele possui um rico conjunto de funções de biblioteca, capacidade de definir fluxos de trabalho e nós o usamos para entregar mais de seis projetos empresariais à produção.

Use-o em conjunto com o TeamCity , CruiseControl ou qualquer coisa que possa executar o PowerShell .

Nós usamos o FlubuCore. É uma biblioteca C # de código aberto para criar projetos e executar scripts de implantação usando o código C #.

Exemplo simples de como o flubu é usado:

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

Você pode encontrar mais informações sobre o flubu e como começar aqui: escolha-para-construir-ferramenta-msbuild-nant-ou-outra-coisa