Visual Studio .suo 및 .user 파일을 소스 제어에 추가해야합니까?
Visual Studio 솔루션에는 두 가지 유형의 숨겨진 사용자 파일이 있습니다. 하나는 .suo바이너리 파일 인 솔루션 파일입니다. 다른 하나는 .user텍스트 파일 인 프로젝트 파일입니다. 이 파일에는 정확히 어떤 데이터가 포함됩니까?
또한이 파일을 소스 제어 (제 경우 Subversion)에 추가해야하는지 궁금합니다. 이러한 파일을 추가하지 않고 다른 개발자가 솔루션을 체크 아웃하면 Visual Studio가 자동으로 새 사용자 파일을 생성하나요?
이러한 파일에는 일반적으로 컴퓨터에 특정한 사용자 기본 설정 구성이 포함되어 있으므로 SCM에 넣지 않는 것이 좋습니다. 또한 VS는 실행할 때마다 거의 변경하므로 항상 SCM에서 '변경됨'으로 표시됩니다. 나도 포함하지 않고 2 년 동안 VS를 사용하는 프로젝트에 있는데 문제가 없었습니다. 유일한 사소한 성가심은 디버그 매개 변수 (실행 경로, 배포 대상 등)가 해당 파일 중 하나에 저장된다는 것입니다 (어떤 파일인지 알 수 없음). 따라서 해당 파일에 대한 표준이있는 경우 ' 다른 개발자가 전체 개발 환경을 '사용 준비'할 수 있도록 SCM을 통해 게시합니다.
추가 할 필요가 없습니다. 여기에는 사용자 별 설정이 포함되어 있으며 다른 개발자는 귀하의 사본을 원하지 않을 것입니다.
다른 사람들은 *.suo및 *.user파일을 소스 제어하에 두는 것이 좋은 생각이 아닌 이유를 설명했습니다 .
svn:ignore두 가지 이유로 속성에 이러한 패턴을 추가 할 것을 제안하고 싶습니다 .
- 따라서 다른 개발자는 한 개발자의 설정으로 끝나지 않습니다.
- 따라서 상태를 보거나 파일을 커밋 할 때 이러한 파일은 코드 기반을 복잡하게 만들고 추가해야하는 새 파일을 모호하게 만들지 않습니다.
바이너리 파일 (* .suo)은 커밋하지 않지만 .user 파일은 커밋합니다. .user 파일에는 예를 들어 프로젝트 디버깅을위한 시작 옵션이 포함되어 있습니다. "디버그"탭의 프로젝트 속성에서 시작 옵션을 찾을 수 있습니다. 일부 프로젝트에서는 NUnit을 사용하고 프로젝트의 시작 옵션으로 nunit-gui.exe를 구성했습니다. .user 파일이 없으면 각 팀 구성원이 별도로 구성해야합니다.
도움이 되었기를 바랍니다.
2011 년에 Google을 통해이 질문 / 답변을 찾았으므로 잠시 시간을내어 Visual Studio 2010에서 만든 * .SDF 파일에 대한 링크를 버전 관리에 추가하면 안되는 파일 목록에 추가 할 것이라고 생각했습니다 ( IDE에서 다시 생성합니다). * .sdf 파일이 다른 곳에서 합법적으로 사용되는지 확신 할 수 없었기 때문에 SVN의 특정 [projectname] .sdf 파일 만 무시했습니다.
Visual Studio 변환 마법사 2010이 대용량 SDF 데이터베이스 파일을 만드는 이유는 무엇입니까?
아니요, 말했듯이 사용자별로 다르기 때문에 소스 제어에 추가해서는 안됩니다.
SUO (솔루션 사용자 옵션) : 솔루션과 연결할 수있는 모든 옵션을 기록하여 열 때마다 사용자 지정 내용이 포함되도록합니다.
.user 파일에는 프로젝트에 대한 사용자 옵션이 포함되어 있고 (SUO는 솔루션에 대한 것임) 프로젝트 파일 이름을 확장합니다 (예 : anything.csproj.user에는 anything.csproj 프로젝트에 대한 사용자 설정이 포함됨).
기본적으로 Microsoft의 Visual SourceSafe는 이러한 파일이 사용자 별 설정 파일이기 때문에 소스 제어에 포함하지 않습니다. SVN을 소스 제어로 사용하는 경우 해당 모델을 따를 것입니다.
이 문제에 대한 Microsoft의 의견 인 것 같습니다.
귀하의 프로젝트가 suo 파일에 DebuggingWorkingDirectory를 저장하는 이유를 모르겠습니다. 사용자 별 설정 인 경우 * .proj.user 파일 이름에 저장하는 것을 고려해야합니다. 해당 설정이 프로젝트에서 작업하는 모든 사용자가 공유 할 수있는 경우 프로젝트 파일 자체에 저장하는 것을 고려해야합니다.
소스 제어에 suo 파일을 추가 할 생각조차하지 마십시오! SUO (솔루 톤 사용자 옵션) 파일은 사용자 별 설정을 포함하기위한 것이며 동일한 솔루션에서 작업하는 사용자간에 공유해서는 안됩니다. scc 데이터베이스에 suo 파일을 추가하는 경우 IDE에서 다른 것이 무엇인지 알지 못하지만 소스 제어 관점에서 웹 프로젝트 scc 통합, Lan vs Internet 플러그인 사용 다른 사용자에 의해 VSS 액세스가 가능하며 scc가 완전히 손상 될 수도 있습니다 (유효 할 수있는 suo 파일에 저장된 VSS 데이터베이스 경로는 다른 사용자에게 유효하지 않을 수 있음).
Alin Constantin (MSFT)
Visual Studio가 자동으로 생성합니다. 나는 그것들을 소스 제어에 두는 것을 권장하지 않습니다. 로컬 개발자의 SOU 파일로 인해 VS가 해당 개발자 상자에서 비정상적으로 작동하는 경우가 여러 번있었습니다. 파일을 삭제 한 다음 VS를 다시 만들면 항상 문제가 해결되었습니다.
온 MSDN 웹 사이트 , 명확한다고
솔루션 사용자 옵션 (.suo) 파일에는 사용자 별 솔루션 옵션이 포함되어 있습니다. 이 파일은 소스 코드 제어에 체크인하지 않아야합니다 .
따라서 소스 제어에 물건을 체크인하는 동안 이러한 파일을 무시하는 것이 매우 안전하다고 말하고 싶습니다.
나는하지 않을 것이다. "사용자"별로 변경 될 수있는 것은 일반적으로 소스 제어에서 좋지 않습니다. .suo, .user, obj / bin 디렉토리
These files are user-specific options, which should be independent of the solution itself. Visual Studio will create new ones as necessary, so they do not need to be checked in to source control. Indeed, it would probably be better not to as this allows individual developers to customize their environment as they see fit.
You cannot source-control the .user files, because that's user specific. It contains the name of remote machine and other user-dependent things. It's a vcproj related file.
The .suo file is a sln related file and it contains the "solution user options" (startup project(s), windows position (what's docked and where, what's floating), etc.)
It's a binary file, and I don't know if it contains something "user related".
In our company we do not take those files under source control.
They contain the specific settings about the project that are typically assigned to a single developer (like, for example, the starting project and starting page to start when you debug your application).
So it's better not adding them to version control, leaving VS recreate them so that each developer can have the specific settings they want.
.user is the user settings, and I think .suo is the solution user options. You don't want these files under source control; they will be re-created for each user.
Using Rational ClearCase the answer is no. Only the .sln & .*proj should be registered in source code control.
I can't answer for other vendors. If I recall correctly, these files are "user" specific options, your environment.
Don't add any of those files into version control. These files are auto generated with work station specific information, if checked-in to version control that will cause trouble in other work stations.
If you set your executable dir dependencies in ProjectProperties>Debugging>Environment, the paths are stored in '.user' files.
Suppose I set this string in above-mentioned field: "PATH=C:\xyz\bin" This is how it will get stored in '.user' file:
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
This helped us a lot while working in OpenCV. We could use different versions of OpenCV for different projects. Another advantage is, it was very easy to set up our projects on a new machine. We just had to copy corresponding dependency dirs. So for some projects, I prefer to add the '.user' to source control.
Even though, it is entirely dependent on projects. You can take a call based on your needs.
No, they shouldn't be committed to source control as they are developer/machine-specific local settings.
GitHub maintain a list of suggested file types for Visual Studio users to ignore at https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
For svn, I have the following global-ignore property set:
*.DotSettings.User
*.onetoc2
*.suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
debug
*.user
*.vshost.*
*.tss
*.dbml.layout
As explained in other answers, both .suo and .user shouldn't be added to source control, since they are user/machine-specific (BTW .suo for newest versions of VS was moved into dedicated temporary directory .vs, which should be kept out of source control completely).
However if your application requires some setup of environment for debugging in VS (such settings are usually kept in .user file), it may be handy to prepare a sample file (naming it like .user.SAMPLE) and add it to source control for references.
Instead of hard-coded absolute path in such file, it makes sense to use relative ones or rely on environment variables, so the sample may be generic enough to be easily re-usable by others.
No.
I just wanted a real short answer, and there wasn't any.
'Programing' 카테고리의 다른 글
| Node.js를 사용하려면 ES6 가져 오기 / 내보내기가 필요합니다. (0) | 2020.09.29 |
|---|---|
| Liskov Substitution Principle의 예는 무엇입니까? (0) | 2020.09.29 |
| C ++ 펑터와 그 용도는 무엇입니까? (0) | 2020.09.29 |
| CSS 만 사용하여 링크를 비활성화하는 방법은 무엇입니까? (0) | 2020.09.29 |
| 백그라운드에서 CSS 이미지 확장 및 크기 조정-CSS 만 사용 (0) | 2020.09.29 |