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?
Respostas:
Eu fiz uma investigação semelhante esta semana. Aqui está o que eu consegui determinar:
NAnt:
MSBuild:
Diferenças subjetivas: (YMMV)
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:
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:
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:
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 .
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:
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