it-swarm-pt.tech

Você pode adicionar os arquivos .suo e .user do Visual Studio ao controle de origem?

As soluções do Visual Studio contêm dois tipos de arquivos ocultos do usuário. Um é o arquivo .suo da solução, que é um arquivo binário. O outro é o arquivo .user do projeto, que é um arquivo de texto. Exatamente quais dados esses arquivos contêm?

Eu também tenho me perguntado se devo adicionar esses arquivos ao controle de origem (Subversion no meu caso). Se eu não adicionar esses arquivos e outro desenvolvedor verificar a solução, o Visual Studio criará automaticamente novos arquivos de usuário?

783
Ben Mills

Esses arquivos contêm configurações de preferências do usuário que são geralmente específicas para sua máquina, portanto, é melhor não colocá-las no SCM. Além disso, o VS irá alterá-lo quase toda vez que você executá-lo, então ele sempre será marcado pelo SCM como 'alterado'. Eu também não incluo, estou em um projeto usando o VS por 2 anos e não teve problemas em fazer isso. O único aborrecimento menor é que os parâmetros de depuração (caminho de execução, destino de implementação, etc.) são armazenados em um desses arquivos (não sei qual), portanto, se você tiver um padrão para eles, não conseguirá ' publicá-lo via SCM para outros desenvolvedores para ter todo o ambiente de desenvolvimento "pronto para uso".

638
Fabio Ceconello

Você não precisa adicioná-los - eles contêm configurações por usuário e outros desenvolvedores não querem sua cópia.

131
Steve Cooper

Outros explicaram porque ter os arquivos *.suo e *.user sob controle de origem não é uma boa idéia.

Eu gostaria de sugerir que você adicione esses padrões à propriedade svn:ignore por 2 motivos:

  1. Então, outros desenvolvedores não vão acabar com Com configurações de um desenvolvedor.
  2. Portanto, quando você visualizar o status ou confirmar os arquivos , Esses arquivos não irão sobrecarregar a base de código e ocultar os novos arquivos que você precisa adicionar.
66
JXG

Nós não cometemos o arquivo binário (* .suo), mas nós enviamos o arquivo .user. O arquivo .user contém, por exemplo, as opções de início para depurar o projeto. Você pode encontrar as opções de início nas propriedades do projeto na aba "Debug". Usamos o NUnit em alguns projetos e configuramos o nunit-gui.exe como a opção de início do projeto. Sem o arquivo .user, cada membro da equipe teria que configurá-lo separadamente.

Espero que isto ajude.

47
Thomas

Desde que encontrei esta pergunta/resposta através do Google em 2011, pensei em tirar um segundo e adicionar o link para os arquivos * .SDF criados pelo Visual Studio 2010 à lista de arquivos que provavelmente não deveriam ser adicionados ao controle de versão ( o IDE irá recriá-los. Como eu não tinha certeza se um arquivo * .sdf poderia ter um uso legítimo em outro lugar, ignorei apenas o arquivo específico [projectname] .sdf do SVN.

Por que o assistente de conversão do Visual Studio 2010 cria um arquivo de banco de dados SDF massivo?

25
Stephen

Não, você não deve adicioná-los ao controle de origem, pois - como você disse - eles são específicos do usuário.

SUO (Opções do usuário da solução): Registra Todas as opções que você pode Associar à sua solução para que Cada vez que você abri-la, inclua Personalizações que você fez. 

O arquivo .user contém as opções do usuário para o projeto (enquanto o SUO é para a solução) e estende o nome do arquivo do projeto (por exemplo, anything.csproj.user contém configurações do usuário para o projeto anything.csproj).

22
JRoppert

Esta parece ser a opinião da Microsoft sobre o assunto:

Adicionando (e editando) arquivos .suo ao controle de fonte

Eu não sei porque seu projeto armazena o DebuggingWorkingDirectory em O arquivo suo. Se essa for uma configuração específica do usuário, considere Armazenando isso no nome do arquivo * .proj.user. Se essa configuração for compartilhável Entre todos os usuários que trabalham no projeto, você deve considerar armazenar No próprio arquivo de projeto.

Nem pense em adicionar o arquivo suo ao controle de origem! O arquivo SUO (Opções do usuário soluton) deve conter configurações específicas do usuário E não deve ser compartilhado entre usuários que trabalham na mesma solução . Se você estivesse adicionando o arquivo suo no banco de dados scc, eu não Sei que outras coisas no IDE você quebraria, mas do controle de origem Ponto de vista você interromperá a integração scc de projetos da web, o plug-in Lan vs usado por diferentes usuários para acesso ao VSS, e você poderá fazer com que o scc quebre completamente (caminho do banco de dados VSS armazenado em arquivo suo que pode ser válido para você pode não ser válido para outro usuário).

Alin Constantin (MSFT)

17
Scott W

Por padrão, o Visual SourceSafe da Microsoft não inclui esses arquivos no controle de origem porque eles são arquivos de configurações específicos do usuário. Eu seguiria esse modelo se você estiver usando o SVN como controle de origem.

17
cori

O Visual Studio irá criá-los automaticamente. Eu não recomendo colocá-los no controle de origem. Houve inúmeras vezes em que o arquivo SOU de um desenvolvedor local estava fazendo com que o VS se comportasse de forma irregular nessa caixa de desenvolvedores. Excluir o arquivo e depois permitir que o VS o recriesse sempre corrigiu os problemas. 

11
Bloodhound

No site MSDN , afirma claramente que 

O arquivo de opções do usuário da solução (.suo) contém opções de solução por usuário . Este arquivo não deve ser registrado no controle do código-fonte.

Então, eu diria que é bastante seguro ignorar esses arquivos enquanto verifica o material no seu controle de origem. 

10
Farax

Eu não faria. Qualquer coisa que possa mudar por "usuário" geralmente não é boa no controle de origem. Diretórios .suo, .user, obj/bin

8
ScaleOvenStove

Esses arquivos são opções específicas do usuário, que devem ser independentes da própria solução. O Visual Studio criará novos conforme necessário, para que eles não precisem ser registrados no controle de origem. Na verdade, provavelmente seria melhor não, pois isso permite que desenvolvedores individuais personalizem seu ambiente da forma que preferirem.

7
benefactual

Você não pode controlar os arquivos .user por fonte, porque isso é específico do usuário. Ele contém o nome da máquina remota e outras coisas dependentes do usuário. É um arquivo relacionado ao vcproj.

O arquivo .suo é um arquivo relacionado ao sln e contém as "opções do usuário da solução" (projeto (s) de inicialização, posição do Windows (o que está encaixado e onde, o que está flutuando), etc.)

É um arquivo binário e não sei se contém algo "relacionado ao usuário".

Em nossa empresa, não levamos esses arquivos sob controle de origem.

6
ugasoft

Eles contêm as configurações específicas sobre o projeto que são geralmente atribuídas a um único desenvolvedor (como, por exemplo, o projeto inicial e a página inicial para iniciar quando você depurar seu aplicativo).

Portanto, é melhor não adicioná-los ao controle de versão, deixando o VS recriá-los para que cada desenvolvedor possa ter as configurações específicas desejadas. 

6
massimogentilini

.user é a configuração do usuário, e eu acho que o .suo é a opção do usuário da solução. Você não quer esses arquivos sob controle de origem; eles serão recriados para cada usuário.

4
Nick

Usando o Rational ClearCase a resposta é não. Apenas o .sln &. * Proj deve ser registrado no controle do código-fonte.

Eu não posso responder por outros fornecedores. Se bem me lembro, esses arquivos são opções específicas do usuário, seu ambiente.

3
titanae

Não adicione nenhum desses arquivos no controle de versão. Esses arquivos são gerados automaticamente com informações específicas da estação de trabalho, se estiverem registrados no controle de versão, o que causará problemas em outras estações de trabalho. 

1
Amila

Como explicado em outras respostas, .suo e .user não devem ser adicionados ao controle de origem, pois são específicos de usuário/máquina (BTW .suo para as versões mais recentes do VS foram movidas para o diretório temporário dedicado .vs, que deve ser mantido fora da fonte controle completamente).

No entanto se seu aplicativo requer alguma configuração de ambiente para depuração no VS (tais configurações são normalmente mantidas no arquivo .user), pode ser útil preparar um arquivo de amostra (nomeando-o como .user.SAMPLE) e adicioná-lo ao controle de origem referências.

Em vez de um caminho absoluto codificado em tal arquivo, faz sentido usar os relativos ou confiar em variáveis ​​de ambiente, portanto, a amostra pode ser genérica o suficiente para ser facilmente reutilizável por outros.

1
AntonK

Não, eles não devem estar comprometidos com o controle de origem, pois são configurações locais específicas do desenvolvedor/máquina.

O GitHub mantém uma lista de tipos de arquivos sugeridos para os usuários do Visual Studio ignorarem em https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

Para o svn, eu tenho o seguinte conjunto de propriedades global-ignore:

* .DotSettings.User
* .onetoc2
* .suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
depurar
*.do utilizador
* .vshost. *
* .tss
* .dbml.layout

0
Stephen Kennedy

Se você definir as dependências do diretório executável em ProjectProperties> Debugging> Environment , os caminhos serão armazenados em arquivos '.user'. 

Suponha que eu configure essa string no campo acima mencionado: "PATH = C:\xyz\bin" É assim que ela será armazenada no arquivo '.user': 

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

Isso nos ajudou muito ao trabalhar no OpenCV. Poderíamos usar diferentes versões do OpenCV para diferentes projetos. Outra vantagem é que foi muito fácil configurar nossos projetos em uma nova máquina. Acabamos de copiar os diretórios de dependência correspondentes. Portanto, para alguns projetos, prefiro adicionar o '.user' ao controle de origem. 

Mesmo assim, é totalmente dependente de projetos. Você pode atender uma chamada com base nas suas necessidades.

0
adheen