Devo 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 de usuário ocultos. Um é o .suoarquivo de solução, que é um arquivo binário. O outro é o .userarquivo do projeto, que é um arquivo de texto. Exatamente quais dados esses arquivos contêm?

Também estive pensando 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?

Esses arquivos contêm configurações de preferência do usuário que geralmente são específicas para sua máquina, portanto, é melhor não colocá-lo no SCM. Além disso, o VS o altera quase toda vez que você o executa, por isso sempre será marcado pelo SCM como 'alterado'. Também não incluo, estou em um projeto usando o VS por 2 anos e não tive problemas para fazer isso. O único incômodo menor é que os parâmetros de depuração (caminho de execução, destino de implantação etc.) são armazenados em um desses arquivos (não sei qual). Portanto, se você tiver um padrão para eles, não poderá ' publique 'via SCM para outros desenvolvedores terem todo o ambiente de desenvolvimento' pronto para uso '.

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

Outros explicaram por que manter os arquivos *.suoe *.usersob controle de origem não é uma boa ideia.

Gostaria de sugerir que você adicione esses padrões à svn:ignorepropriedade por 2 razões:

1. Portanto, outros desenvolvedores não terminam com as configurações de um desenvolvedor.
2. Portanto, quando você exibe o status ou confirma os arquivos, esses arquivos não atrapalham a base de código e ocultam os novos arquivos que você precisa adicionar.

Não confirmamos o arquivo binário (* .suo), mas confirmamos o arquivo .user. O arquivo .user contém, por exemplo, as opções de inicialização para depurar o projeto. Você pode encontrar as opções de início nas propriedades do projeto na guia "Depuração". 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.

Como encontrei essa pergunta / resposta no Google em 2011, pensei em levar 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 não tinha certeza de que um arquivo * .sdf possa ter um uso legítimo em outro lugar, ignorei apenas o arquivo [nome do projeto] .sdf específico do SVN.

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

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, toda vez que você a abra, inclua personalizações feitas.

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

Parece ser a opinião da Microsoft sobre o assunto:

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

Não sei por que seu projeto armazena o DebuggingWorkingDirectory no arquivo suo. Se essa for uma configuração específica do usuário, considere armazená-la no nome do arquivo * .proj.user. Se essa configuração for compartilhável entre todos os usuários que trabalham no projeto, considere armazená-la no próprio arquivo do projeto.

Nem pense em adicionar o arquivo suo ao controle de origem! O arquivo SUO (opções de usuário do 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ê estiver adicionando o arquivo suo no banco de dados scc, não sei quais outras coisas no IDE você quebraria, mas do ponto de vista do controle de origem, você quebrará a integração scc de projetos da web, o plug-in Lan vs Internet usado por usuários diferentes para acesso ao VSS, e você pode até fazer com que o scc se quebre completamente (o caminho do banco de dados do VSS armazenado no arquivo suo que pode ser válido para você pode não ser válido para outro usuário).

Alin Constantin (MSFT)

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

O Visual Studio os criará 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 maneira irregular na caixa de desenvolvedores. A exclusão do arquivo e, em seguida, a recriação do VS sempre corrigia os problemas.

No site da 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 de código-fonte .

Então, eu diria que é bastante seguro ignorar esses arquivos enquanto faz o check-in no seu controle de origem.

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

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. De fato, provavelmente seria melhor não, pois isso permite que os desenvolvedores individuais personalizem seu ambiente como acharem melhor.

Você não pode controlar os arquivos .user da 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 das janelas (o que está ancorado 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 colocamos esses arquivos sob controle de origem.

Eles contêm as configurações específicas sobre o projeto que normalmente são atribuídas a um único desenvolvedor (como, por exemplo, o projeto inicial e a página inicial a serem iniciadas quando você depura 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.

.user são as configurações do usuário, e acho que .suo é a solução para as opções do usuário. Você não deseja que esses arquivos estejam sob controle de origem; eles serão recriados para cada usuário.

Não.

Eu só queria uma resposta muito curta, e não havia nenhuma.

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

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

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

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 svn, tenho o seguinte global-ignoreconjunto de propriedades:

* .DotSettings.User
* .onetoc2
* .suo
.vs
Pré-compiladoWeb
thumbs.db
obj
bin
debug
* .user
* .vshost. *
* .Tss
* .dbml.layout

Se você definir suas dependências dir executáveis ​​em ProjectProperties> Debugging> Environment , os caminhos serão armazenados nos arquivos '.user'.

Suponha que eu defina essa sequência 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 enquanto trabalhamos 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. Nós apenas tivemos que 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 em suas necessidades.

Conforme explicado em outras respostas, ambos .suoe .usernão devem ser adicionados ao controle de origem, pois são específicos de usuário / máquina (o BTW .suodas versões mais recentes do VS foi movido para o diretório temporário dedicado.vs , que deve ser mantido completamente fora do controle de origem).

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

Em vez de um caminho absoluto codificado nesse 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 reutilizada por outras pessoas.