Saída de uma construção incluída em outro

Question

Qual é a maneira correta de incluir uma saída de uma construção como um binário em outra compilação?

Digamos que eu tenha uma solução chamada CompanyName.Domain (minha camada de domínio). Eu o tenho configurado como uma construção e ele constrói todas as noites.

Agora eu quero adicionar uma solução chamada algum project.web. E quero incluir o binário fora da empresa. Em seguida, o projeto algum projects.web referência aos binários CompanyName.Domain.dll funcionará.

Quais são as melhores práticas para fazer isso? Conheço alguém que disse que estava tentando fazer isso com ramificação. Eu sou um "controle de origem" total Newb. Mas algo sobre isso parece errado.

Answer 1

Assim como Daryl, usamos uma pasta "binários" da qual fazemos referência a binários. Nossas "bibliotecas" criam apenas xcopy os resultados no local dos binários; portanto, se desejarmos atualizar as bibliotecas, apenas conferimos os binários, construímos e verificamos novamente.

Isso nos permite compartilhar todas as nossas bibliotecas internas (bem como quaisquer bibliotecas de terceiros que usamos) de um único local padronizado, e todas as nossas bibliotecas podem ser pré -construídas, economizando nossos desenvolvedores que precisam construí -los se não estiverem realmente mudando nada no Libs.

Tome cuidado para referenciar apenas as compilações de versão de suas bibliotecas (a única exceção que temos a isso é que temos uma biblioteca de depuração de ajudantes que são compilados condicionalmente compilados apenas em depuração, e devemos referir a versão de depuração, caso contrário, toda a nossa depuração é Compilado fora do programa, mesmo no Debug Builds!)

Uma última nota: evite ramificar, a menos que não haja alternativa razoável.

Answer 2

Minha empresa faz isso criando uma pasta "referências" para manter todos os arquivos .dll necessários para criar conjuntos referenciados externamente, pois a pasta BIN não é realmente salva no controle de origem.

Answer 3

Nós usamos o Replicador de dependência do TFS, que pode copiar arquivos para qualquer projeto no TFS após a criação de um projeto. Ele não tem uma ótima documentação, mas parece fazer o que deveria depois de você configurar.

A postagem do blog Implementando a replicação de dependência com a TFS Team Build Recomenda a configuração de um cenário de ramificação para ajudar no rastreamento de quais projetos estão usando quais dependências também fazem sentido para mim.

Answer 4

Meu processo é semelhante ao dos outros pôsteres.

Digamos que eu tenha dois projetos, chame -os de CoreProject e AppProject. CoreProject é compartilhado. O AppProject possui uma pasta chamada SharedBinários. É aqui que todas as referências de montagem apontam.

Meu script TFSBuild para o CoreProject está configurado para fazer o seguinte:

-Receber as últimas

-Build Drop to Drop Zone (algo como Server DropZone CoreProjectBuildNameAndNumber)

-Drop é copiado para uma pasta na zona de gota (algo como server DropZone mais recente CoreProject)

O script TFSBuild para AppProject está configurado para fazer o seguinte:

-Receber as últimas

-Cechar os arquivos na pasta SharedBinários

-Copy Arquivos de Server DropZone mais recente CoreProject

-Construir

-Drop to Drop Zone (algo como server DropZone AppProjectBuildNameAndNumber)

-Se a compilação for bem -sucedida, a compilação é copiada para uma zona de gota de pasta (algo como server dropzone mais recente appproject) e os arquivos no SharedBinários são verificados

-Se a compilação falhar, os arquivos copiados em sharedbinários têm o checkout desfeito.

Eu achei que isso funciona muito bem. O AppProject está sempre construindo com os bits mais atuais do CoreProject, por isso sabemos imediatamente se houver uma mudança de ruptura. Ao fazer binários compartilhados verificados no TFS, posso obter uma versão específica e executar o código com as mesmas DLLs do CoreProject que foram usadas naquele momento. Também tenho que me tornar mais recente e minha máquina local está construindo com os mais recentes bits.