Você faz check-in de pastas bin ou depuração (e dlls) no seu TFS?

Pergunta rápida sobre TFS - Vocês fazem o check-in de pastas bin / debug no TFS? (se sim, por quê?) Como o conteúdo dessas pastas é gerado dinamicamente, é melhor deixá-las de fora para que o programador não tenha problemas somente leitura?

Como regra geral, o controle de origem é melhor usado apenas para fonte e os arquivos gerados não são de origem.

Há exceções. Às vezes (usando o Visual Studio), convém manter o arquivo .pdb para ler minidumps. Às vezes, você não pode duplicar uma cadeia de ferramentas, para que você não possa recriar necessariamente os arquivos gerados com precisão. Nesses casos, você está interessado principalmente em fazer isso no software lançado, não em todas as alterações do VCS e, em qualquer caso, elas podem residir facilmente em pastas com versão. (Geralmente, esses são arquivos binários e não têm alterações compreensíveis de uma versão para outra, e não se beneficiam muito por estar em um VCS.)

Resposta simples? Não. Não faça isso! Não consigo pensar em muitas razões para não fazê-lo, mas não há razão para que você queira.

A única vez que posso pensar que você faria o check-in de uma dll é se for de uma biblioteca de terceiros que você não espera que todos os desenvolvedores tenham instalado. Mas mesmo assim, isso não está localizado na pasta bin.

Dito isto, trabalhei em uma empresa que exigia que cada pacote de implantação fosse colocado no controle de origem, mas foi para que pudéssemos rastrear as várias compilações que fornecemos ao nosso cliente e que pudéssemos reverter facilmente, se necessário.

Não fazemos check-in na pasta bin no TFS. Como você provavelmente já percebeu, se você fizer isso, toda vez que um desenvolvedor criar a solução, ele estará verificando a pasta bin. Não é bom. No entanto, existem bibliotecas que o projeto precisa para compilar e executar, e nossa regra é que qualquer projeto possa ser aberto a partir do controle de origem, e ele deve ser compilado e executado. Portanto, o que fazemos é criar uma pasta "BinRef" para todas as DLLs às quais o projeto deve ter referência e criar as referências do projeto para a cópia na pasta BinRef. A pasta BinRef é registrada no TFS.

A outra vantagem dessa abordagem é que o BinRef está sempre no nível raiz do projeto da web. Se meu projeto residir C:\Projects\Marcie\SomeProjectCategory\ProjectAe eu criar uma referência a uma DLL que fica C:\DLLsThatILike, a referência acabará parecendo algo como

\..\..\..\NiceThing.dll

. Você pode manter os arquivos do projeto, o C:\ProjectAque significa que a referência do projeto ao NiceThing explodirá em sua máquina. Espero que as pessoas não estejam fazendo referências dessa maneira, mas eu já vi isso acontecer.

Fazemos o check-in do conteúdo dos diretórios bin, como parte de nosso processo de Solicitação de Mudança. Para evitar os problemas somente leitura, copiamos o conteúdo para uma pasta separada e fazemos o check-in a partir daí. Nossa política corporativa exige que todos os binários que vão para produção sejam registrados separadamente da fonte. Não é a melhor solução, mas funciona e nos fornece os arquivos exatos que estão em produção.

Hesito em verificar qualquer arquivo que não seja de texto no controle de origem. Especialmente aqueles que devem ser gerados pelo desenvolvedor. Também gosto de manter outros arquivos binários, como imagens e PDFs, compactados e armazenados em outro local para cada tag / release.

Não, mas nossa ferramenta interna de controle de projetos funciona automaticamente, o que me incomoda.

Minha solução é marcar todos os arquivos no lançamento e depurar como graváveis ​​e, quando o TFS se queixa, eu digo para ignorar os arquivos, para que eu nunca tenha um problema com uma falha na compilação.

Evito inseri-los no controle de origem. São informações redundantes, os binários podem ser construídos pelo código fonte dessa revisão. Além disso, o código fonte está sempre atualizado, as compilações podem não estar em consolidação.

Eu salvo alguns arquivos binários gerados, como interoperabilidade do .NET de outro projeto. Portanto, se eu tiver um projeto A que cria um objeto COM e você o usa em um projeto B muito vagamente relacionado que o usa por meio da interoperabilidade .NET, verifico a interoperabilidade gerada do projeto A para o projeto B. não é uma boa ideia, mas precisa ir a algum lugar porque o AFAIK Visual Studio não criará a interoperabilidade para você automaticamente durante a compilação.

Na minha opinião, não armazenar binários no controle de origem é um dos erros mais comuns. Eles devem ser armazenados, com versão, baselined / labeled junto com as fontes e também construir ferramentas. Suite-se com a construção de software não rastreável ...