Um .sln deve ser comprometido com o controle de origem?


101

É uma prática recomendada confirmar um arquivo .sln para o controle de origem? Quando é apropriado ou inapropriado fazer isso?

Atualização Houve vários pontos positivos nas respostas. Obrigado pelas respostas!


21
Acredito que seja o arquivo .SUO que você NÃO deseja enviar.
apandit

Apenas para registro, acredito que as listas de tarefas (se você usá-las) são armazenadas no arquivo .SUO ... Portanto, embora você não queira enviá-las ao controle de origem, talvez não queira 'apenas excluí-las' como cruft estranho.
Benjol

Respostas:


69

Acho que está claro pelas outras respostas que os arquivos de solução são úteis e devem ser confirmados, mesmo se não forem usados ​​para compilações oficiais. Eles são úteis para qualquer pessoa que use recursos do Visual Studio, como Go To Definition / Declaration.

Por padrão, eles não contêm caminhos absolutos ou quaisquer outros artefatos específicos da máquina. (Infelizmente, algumas ferramentas de suplemento não mantêm adequadamente esta propriedade, por exemplo, AMD CodeAnalyst.) Se você tiver o cuidado de usar caminhos relativos em seus arquivos de projeto (C ++ e C #), eles serão independentes da máquina também.

Provavelmente, a pergunta mais útil é: quais arquivos você deve excluir? Aqui está o conteúdo do meu arquivo .gitignore para meus projetos do VS 2008:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(A última entrada é apenas para o criador de perfil AMD CodeAnalyst.)

Para o VS 2010, você também deve excluir o seguinte:

ipch/
*.sdf
*.opensdf

2
Eu também tenho uma regra para ignorar os resultados do teste de unidade. Algumas pessoas podem fazer o check-in, mas eu não gosto da desordem
Matthew Whited

9
+1 - Eu pessoalmente também não submeto nada que seja construído, portanto bin / e obj /
Steven Evers

Só envio arquivos .sln que contenham mais de 1 projeto
Justin

2
aqui está meu padrão de ignorar global do subversion: * .vsmdi * .suo * / [Bb] in [Bb] em * / obj obj TestResults *. [Uu] ser * Thumbs.db * Web.Publish.xml * WebApplication.Publish. xml * Web.log
Merritt

Aqui está um arquivo .gitignore comumente compartilhado que inclui arquivos temporários, resultados de compilação e arquivos gerados por complementos populares do Visual Studio.
Lauren Van Sloun,

58

Sim - acho que é sempre apropriado. As configurações específicas do usuário estão em outros arquivos.


3
Definitivamente O .sln tem referências aos arquivos .prj (projetos)
dplante

20

Sim, você deve fazer isso. Um arquivo de solução contém apenas informações sobre a estrutura geral de sua solução. As informações são globais para a solução e provavelmente comuns a todos os desenvolvedores do seu projeto.

Ele não contém nenhuma configuração específica do usuário.


13

Você definitivamente deveria ter. Além das razões que outras pessoas mencionaram, é necessário tornar possível uma etapa de construção de todos os projetos.


8

Em geral, concordo que os arquivos de solução devem ser verificados, no entanto, na empresa para a qual trabalho fizemos algo diferente. Temos um repositório bastante grande e os desenvolvedores trabalham em diferentes partes do sistema de vez em quando. Para apoiar a maneira como trabalhamos, teríamos um grande arquivo de solução ou vários menores. Ambos têm algumas deficiências e requerem trabalho manual por parte dos desenvolvedores. Para evitar isso, criamos um plug-in que trata de tudo isso.

O plug-in permite que cada desenvolvedor verifique um subconjunto da árvore de origem para trabalhar, simplesmente selecionando os projetos relevantes do repositório. O plug-in então gera um arquivo de solução e modifica os arquivos de projeto na hora para a solução fornecida. Ele também lida com referências. Em outras palavras, tudo que o desenvolvedor precisa fazer é selecionar os projetos apropriados e então os arquivos necessários são gerados / modificados. Isso também nos permite personalizar várias outras configurações para garantir os padrões da empresa.

Além disso, usamos o plug-in para oferecer suporte a várias políticas de check-in, o que geralmente evita que os usuários enviem código defeituoso / não compatível ao repositório.


Parece que esta pode ser a resposta a uma das minhas perguntas há muito sem resposta ( stackoverflow.com/questions/1490728/… ), alguma chance de conseguir uma cópia deste plugin?
Benjol

@Benjol: Desculpe, não, é uma ferramenta interna. Além dos recursos acima, ele também se integra a vários outros sistemas internos, por isso é muito específico para a forma como executamos as coisas. Se você só precisa da solução / parte do projeto, não é tão difícil de implementar.
Brian Rasmussen

OK, só uma coisa, em sua 'grande solução' você tem referências de projeto ou referências de arquivo? E se um desenvolvedor adicionar uma nova referência a um arquivo / projeto, o plug-in faz a conversão apropriada antes de fazer o check-in? E como você lida com as dependências que o desenvolvedor não decidiu verificar?
Benjol

8

Sim, as coisas que você deve se comprometer são:

  • solução (* .sln),
  • arquivos de projeto,
  • todos os arquivos de origem,
  • arquivos de configuração do aplicativo
  • construir scripts

Coisas que você não deve cometer são:

  • arquivos de opções do usuário de solução (.suo),
  • construir arquivos gerados (por exemplo, usando um script de construção) [Editar:] - somente se todos os scripts e ferramentas de construção necessários estiverem disponíveis sob controle de versão (para garantir que as construções sejam autênticas no histórico de cvs)

Em relação a outros arquivos gerados automaticamente, há um tópico separado .


1
Tenho que discordar de "qualquer arquivo gerado automaticamente".
Mehrdad Afshari

@Mehrdad você acha que os arquivos Intelisense também deveriam ser confirmados?
Edison Gustavo Muenz

1
@Edison: Não. Estou me referindo a arquivos de origem gerados automaticamente, como contexto de dados LINQ to SQL, por exemplo.
Mehrdad Afshari

2
Os arquivos Formname.Designer.cs não são considerados gerados automaticamente?
jasonh

1
O que eu quis dizer são arquivos gerados durante o tempo de construção. Eu acho isso freqüentemente - alguém submete um arquivo que é construído automaticamente, e então o SVN relata uma alteração apenas porque algum comentário foi alterado.
Bom dia

5

Sim, deve fazer parte do controle de origem. Sempre que você adicionar / remover projetos de seu aplicativo, .sln seria atualizado e seria bom tê-lo sob controle de origem. Isso permitiria que você retirasse as versões do código 2 do aplicativo e fizesse uma compilação diretamente (se necessário).


5

Na maioria das circunstâncias, é uma boa ideia enviar arquivos .sln para o controle de origem.

Se seus arquivos .sln forem gerados por outra ferramenta (como o CMake), provavelmente é impróprio colocá-los no controle de origem.


4

Sim, você sempre deseja incluir o arquivo .sln, ele inclui os links para todos os projetos que estão na solução.


2

Fazemos porque mantém tudo sincronizado. Todos os projetos necessários estão localizados juntos e ninguém precisa se preocupar em perder um. Nosso servidor de construção (Ant Hill Pro) também usa o sln para descobrir quais projetos construir para um lançamento.


2

Normalmente colocamos todos os nossos arquivos de soluções em um diretório de soluções. Dessa forma, separamos um pouco a solução do código e é mais fácil escolher o projeto no qual preciso trabalhar.


1

O único caso em que você consideraria não armazená-lo no controle de origem seria se você tivesse uma grande solução com muitos projetos que estavam no controle de origem e você quisesse criar uma pequena solução com alguns dos projetos da solução principal para alguns requisito transitório privado.


1

Sim - tudo usado para gerar seu produto deve estar no controle de origem.


1

Nós mantemos ou solucionamos arquivos no TFS Version Control. Mas como a solução principal é realmente grande, a maioria dos desenvolvedores possui uma solução pessoal contendo apenas o que precisam. O arquivo de solução principal é usado principalmente pelo servidor de construção.


0

.slns são a única coisa com que não tivemos problemas no tfs!


1
Isso é engraçado ... SLNs foram os únicos arquivos que eu já tive que consertar ... mas os problemas foram causados ​​por desenvolvedores que não tomavam cuidado com as mesclagens.
Matthew Whited
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.