Estamos usando o TeamCity para integração contínua e está criando nossos lançamentos por meio do arquivo de solução (.sln). Eu usei o Makefiles no passado para vários sistemas, mas nunca o msbuild (o que ouvi dizer é como Makefiles + XML mashup). Eu já vi muitas postagens sobre como usar o msbuild diretamente em vez dos arquivos de solução, mas não vejo uma resposta muito clara sobre por que fazê-lo.
Então, por que devemos nos preocupar em migrar de arquivos de solução para um 'makefile' do MSBuild? Temos alguns lançamentos que diferem de acordo com um #define (builds caracterizados), mas na maioria das vezes tudo funciona.
A maior preocupação é que agora teríamos que manter dois sistemas ao adicionar projetos / código-fonte.
ATUALIZAR:
As pessoas podem esclarecer o ciclo de vida e a interação dos três componentes a seguir?
- O arquivo .sln do Visual Studio
- Os vários arquivos .csproj no nível do projeto (que eu entendo de scripts "sub" do msbuild)
- O script msbuild personalizado
É seguro dizer que o .sln e o .csproj são consumidos / mantidos normalmente na GUI do Visual Studio IDE enquanto o script msbuild personalizado é escrito à mão e geralmente consome o .csproj individual já existente "no estado em que se encontra"? Essa é uma maneira de ver redução de sobreposição / duplicação na manutenção ...
Gostaria de receber alguma luz sobre isso da experiência operacional de outras pessoas
Because it's reputed to be better practice
Onde?
So, why should we bother migrating from solution files to an MSBuild 'makefile'?
Primeiro você tem que dizer por que você está considerando isso? O arquivo da solução não é suficiente?