MSBuild - Use o arquivo .csproj ou crie o seu próprio?

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

Pergunta

OK, admito prontamente que sou um novato quando se trata de integração contínua.

Dito isso, estou tentando configurar um ambiente CC.NET para me educar, mas estou tendo problemas para encontrar as informações necessárias para configurar a parte de construção automatizada.

Pelo que entendi, em C# o arquivo .csproj produzido pelo VS 2005 e posteriores é um arquivo MSBuild válido.A saber, consegui integrar a tarefa MSBuild ao CC.NET usando o arquivo .csproj, mas tenho alguns problemas com isso:

  1. Há muita coisa acontecendo aqui que não tenho certeza se realmente preciso em um ambiente de construção automatizado.
  2. Eu não criei este arquivo.Eu não entendo isso e isso me assusta.(Programação por coincidência)
  3. A maior parte do que está acontecendo parece ser abstraído através $(MSBuildToolsPath)\Microsoft.CSharp.targets
  4. Como resultado de 1, 2 e 3, modificar o arquivo para incluir algo como MbUnit parece complicado e mais difícil do que deveria ser.Minha única opção real é incluí-lo no AfterBuild seção, o que parece um hack para mim.

Então, algumas perguntas para o pessoal do CC.NET, do MSBuild e do MbUnit.

  1. Ao usar o MSBuild, é aconselhável usar o arquivo .csproj gerado pelo VS como arquivo de compilação?Ou devo criar o meu próprio?
  2. Os testes MbUnit devem fazer parte do arquivo MSBuild ou do arquivo CC.NET?Minha pesquisa parece sugerir que eles pertencem ao arquivo MSBuild.Se for esse o caso, devo criar um novo arquivo .proj do MSBuild e fazer check-in no CVS, além do arquivo .csproj?Ou a tarefa MbUnit passa a fazer parte do meu arquivo .csproj?
  3. Semelhante à pergunta 2.Se eu adicionar os testes MbUnit ao arquivo MSBuild e acabar usando o arquivo .csproj, o Target Name="AfterBuild" realmente a seção para adicionar essas informações?Não deveria haver um Target Name="Test" seção?Usar o arquivo .csproj gerado pelo VS parece impedir a segunda opção.

Eu sei que há muita coisa lá, mas a maior parte do que consegui encontrar online pressupõe um certo nível de familiaridade com esses tópicos que eu simplesmente não tenho - a menos que esteja enganado, a curva de aprendizado para essas coisas é não é uma curva, é uma função degrau.:)

Editar 1:Atualizei o texto para ser um pouco mais conciso e para responder a algumas dúvidas persistentes que tive com as respostas.

Foi útil?

Solução

Eu recomendaria usar os arquivos .csproj gerados - na verdade, para produção, acho que usar os arquivos .sln gerados é uma boa ideia.Descobri que você ganhará usando os mesmos arquivos de solução que os desenvolvedores.

Esteja ciente de que os arquivos .sln não são realmente arquivos de projeto msbuild válidos - eles são transformados em projetos msbuild pelo próprio msbuild quando são usados ​​como entradas.Complicado!

Para fins de aprendizagem, você pode registrar a construção de um .csproj e avançar para ter uma ideia do que está acontecendo.O MSBuild é um pouco mais declarativo do que o nant, então reserve um tempo e experimente um pouco.

Por fim, eu agruparia seus arquivos .sln ou .csproj em um projeto de script de construção contínua com tarefas msbuild para construir seus projetos e executar seus testes de unidade juntos.Dessa forma, os desenvolvedores não precisam executar o teste de unidade toda vez que constroem - mas toda vez que integrarem seu código, os testes de unidade serão executados.E sim, certifique-se de que eles corram rápido!Qualquer coisa que leve mais de um segundo deve ser executada durante uma compilação agendada (noturna?).Provavelmente serão menos testes de unidade e mais testes de integração escritos com uma estrutura de teste de unidade se demorarem mais de um segundo.

Editar: Algumas informações adicionais que achei úteis - o uso do MSBuild 3.5 permitirá que você obtenha a saída de destino de um arquivo .sln, embora essas informações não sejam retornadas no MSBuild 2.0 (embora eu ache que deva funcionar para arquivos .csproj em ambas as versões).Você pode usar a saída (seus arquivos criados) como entradas para sua estrutura de teste de unidade.

Outras dicas

Deixe o arquivo csproj bem em paz (como você diz, você não entende).

Crie seu próprio arquivo msbuild proj e ligue para o CSPROJ (ou SLN) do seu arquivo de construção principal através da tarefa MSBUILD. Diga ao seu servidor de CI para criar seu arquivo de construção.

Essa separação facilita a adição de suas próprias tarefas pré e post (testes de unidade, scripts SQL de teste de fumaça, análise FXCOP/outras análises estáticas, etc.) e você não quebrará seu ambiente de trabalho. Isso também significa que você pode fazer suas metas personalizadas no que quiser (msbuild/formig, etc.) dar uma olhada como msbuildcontrib no codeplex para obter uma bondade extra.

Você não precisa do Visual Stuido em seu servidor de construção (Unles que você tem projetos de implantação, a menos que isso também tenha sido alterado desde a última vez que parecia)

Crie seu próprio arquivo de projeto (qualquer coisa que termine com *proj é considerada um arquivo de projeto da msbuild) e ligue para sua compilação a partir daí. Assim:

<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">

Observe que o msbuild também pode criar .sln (arquivo de solução) sem alterações, o que geralmente é mais fácil do que ter um monte de arquivos CSPROJ ...

Eu uso Nant e MSBuild. Nant foi atualizado com NantContrib para que eu tenha msbuild Taks. Posso ser uma configuração temporária, mas até agora não corri em grandes problemas. Dito isto, eu também não cria um novo arquivo CSPROJ porque uso o mesmo CSProj/SLN que uso no VS2008. Construindo projetos com msbuild simplificou muito os scripts legados nant (usamos csc tarefa).

Notas:

  1. Se você usar o Windows Workflow Foundation em seus projetos, terá grandes dificuldades para criar esse projeto sem o MSBUILL.
  2. Não instale o vs.net em sua máquina de construção. Você pode usar Wix Crie a instalação MSI.
  3. @Franci Penov: Os testes de unidade em execução devem fazer parte de todas as compilações. Você realmente quer esperar até amanhã para encontrar um bug? Há uma nota lateral: os testes de unidade devem ser executados muito rápido.

Pessoalmente, acho que não há problema em ir com o arquivo .csproj. Não há muita coisa acontecendo lá, que você não precisaria se adicionar se rolar seu próprio projeto MSBuild.

No entanto, qualquer que seja o caminho que você decidir seguir, eu ainda recomendo não adicionar o MBunit como parte da sua etapa de construção, mas adicione -a como uma etapa separada no CC.NET. Os testes de unidade em execução devem fazer parte do ciclo diário de IC; No entanto, não deve fazer parte de todas as compilações.

Ok, poucas coisas para se observar. O formato CSPROJ mudou de VS2005 para VS2008. Além disso, se você estiver indo com o msbuild, lembre -se de que não poderá criar arquivos .vdproj (configuração); Para isso, você precisa Devenv (o VS executável). Dito isto, você sempre pode criar uma tarefa MSBuild que chama Devenv e a cria para você.

Quanto à sua pergunta se deve construir seu próprio arquivo csproj ou usar o criado pelo VS2005, sugiro uma estrada do meio: Crie seu próprio modelo de projeto, que atende às suas necessidades e deixe o vs cuidar do resto.

Não há problema em usar .csproj como entrada para msbuild. Você pode adicionar manualmente tarefas para isso ao CSProj, que serão ignoradas durante o queixas do vs. Mas se você for fazer algumas coisas não triviais, é melhor criar scripts do MSBuild separados. E eles podem ser referenciados a partir de arquivos CSPROJ. Você deu uma olhada no MS Build Server, que faz parte do TFS? Ele se integra ao SourceControl do TFS e pode ser usado para o IC. Seus arquivos de projeto são scripts msbuild.

Se eu usei o NANT, é necessário que o VS deve ser instalado no servidor? Você quis dizer 'msbuild'? Não, não é necessariamente instalar o VS para usar o msbuild com arquivos CSPROJ.

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