Visual Studioの.suoファイルと.userファイルをソース管理に追加する必要がありますか？
Visual Studioソリューションには、2種類の隠しユーザーファイルがあります。一つはバイナリファイルであるソリューション.suoファイルです。もう1つはテキストファイルであるプロジェクト.userファイルです。これらのファイルにはどのようなデータが含まれていますか？
私はこれらのファイルをソース管理に追加すべきかどうかも考えていました（私の場合はSubversion）。これらのファイルを追加せずに他の開発者が解決策をチェックアウトした場合、Visual Studioは自動的に新しいユーザーファイルを作成しますか？
これらのファイルには、一般的にあなたのマシンに固有のユーザー設定が含まれているので、それをSCMに入れない方がいいでしょう。また、VSは実行するたびにそれを変更するため、SCMによって常に「変更済み」とマークされます。私はどちらも含めないで、私は2年間VSを使っているプロジェクトにいます、そして、それをすることに何の問題もありませんでした。唯一のちょっとした煩わしさは、デバッグパラメータ（実行パス、デプロイメントターゲットなど）がこれらのファイルのうちの1つに格納されていることです（どちらがわかりません）開発環境全体を「使用できるようにする」ために、「SCMを介して他の開発者に公開する」。
これらを追加する必要はありません - ユーザーごとの設定が含まれており、他の開発者はあなたのコピーを望んでいません。
他の人たちは、*.suoおよび*.userファイルをソース管理下に置くのは得策ではない理由を説明しました。
2つの理由から、これらのパターンをsvn:ignoreプロパティに追加することをお勧めします。
- そのため、他の開発者が1人の開発者の設定に縛られることはありません。
- そのため、ステータスを表示したりファイルをコミットしたりしても、それらのファイルによってコードベースが乱れたり、追加する必要がある新しいファイルがあいまいになることはありません。
バイナリファイル（* .suo）はコミットしませんが、.userファイルはコミットします。 .userファイルには、プロジェクトをデバッグするための起動オプションなどが含まれています。開始オプションは、プロジェクトのプロパティの[デバッグ]タブにあります。いくつかのプロジェクトでNUnitを使用し、プロジェクトの開始オプションとしてnunit-gui.exeを設定しました。 .userファイルがないと、各チームメンバーは個別に設定する必要があります。
お役に立てれば。
2011年にGoogleでこの質問/回答を見つけたので、ちょっと時間をかけてVisual Studio 2010で作成された* .SDFファイルへのリンクをバージョン管理に追加してはいけないファイルのリストに追加します。 IDEはそれらを再作成します。 * .sdfファイルが他の場所で合法的に使用されているかどうかわからないので、SVNからの特定の[projectname] .sdfファイルのみを無視しました。
いいえ、あなたが言ったように - それらはユーザ固有であるので、あなたはそれらをソース管理に追加するべきではありません。
SUO（Solution User Options）：ソリューションを開くたびに、行ったカスタマイズが含まれるように、ソリューションに関連付ける可能性のあるすべてのオプションを記録します。
.userファイルにはプロジェクトのユーザーオプションが含まれ（SUOはソリューション用）、プロジェクトファイル名が拡張されます（例、anything.csproj.userにはanything.csprojプロジェクトのユーザー設定が含まれます）。
デフォルトでは、MicrosoftのVisual SourceSafeはこれらのファイルをユーザー管理の設定ファイルであるため、ソース管理に含めません。 SVNをソース管理として使用している場合は、そのモデルに従います。
これは、この問題に関するマイクロソフトの意見のようです。
なぜあなたのプロジェクトがsugingファイルにDebuggingWorkingDirectoryを格納しているのかわかりません。これがユーザー固有の設定である場合は、*。proj.userファイル名に保存することを検討する必要があります。その設定がプロジェクトで作業しているすべてのユーザー間で共有可能な場合は、プロジェクトファイル自体に保存することを検討する必要があります。
suoファイルをソース管理に追加することすら考えないでください！SUO（soluton user options）ファイルにはユーザー固有の設定が含まれているため、ユーザー間で共有しないでください。同じ解決策に取り組んでいます。あなたがsccデータベースにsuoファイルを追加しようとしているのであれば、IDE内にある他のものが壊れているのではないかと思いますが、ソース管理の観点からはWebプロジェクトのscc統合は壊れますLAN対インターネットプラグインはVSSアクセスのために異なるユーザによって使用され、あなたはsccを完全に壊すことさえできます（あなたにとって有効であるかもしれないsuoファイルに格納されたVSSデータベースパスは他のユーザにとって有効でないかもしれません）。
アリンコンスタンタン（MSFT）
Visual Studioによって自動的に作成されます。それらをソース管理に入れることはお勧めしません。ローカル開発者のSOUファイルによってVSがその開発者ボックス上で不規則に振舞う原因となっていたことが何度もありました。ファイルを削除してからVSに再作成させると、常に問題が解決しました。
MSDN Webサイト では、それは明確に述べています
ソリューションユーザーオプション（.suo）ファイルには、ユーザーごとのソリューションオプションが含まれています。 このファイルをソースコード管理にチェックインしないでください。
だから私はそれがあなたのソース管理にものをチェックインしている間これらのファイルを無視することはかなり安全であると言うでしょう。
しません。 「ユーザー」ごとに変更される可能性があるものは、通常、ソース管理には適していません。 .suo、.user、obj/binディレクトリ
これらのファイルはユーザー固有のオプションであり、ソリューション自体とは無関係です。 Visual Studioは必要に応じて新しいものを作成するので、ソース管理にチェックインする必要はありません。実際、個々の開発者が自分たちの環境を自分の好みに合わせてカスタマイズできるため、おそらくそうしない方がよいでしょう。
.userファイルはソース管理できません。これはユーザー固有のためです。それはリモートマシンの名前と他のユーザ依存のものを含んでいます。それはvcproj関連ファイルです。
.suoファイルはsln関連ファイルであり、「ソリューションユーザオプション」（スタートアッププロジェクト、ウィンドウの位置（ドッキングされている場所、移動している場所など）など）を含んでいます。
それはバイナリファイルです、そして、それが何か「ユーザー関連」を含んでいるかどうか私は知りません。
当社では、これらのファイルをソース管理下に置かないでください。
これらには、通常1人の開発者に割り当てられているプロジェクトに関する特定の設定が含まれています（たとえば、開始プロジェクトおよびアプリケーションのデバッグ時に開始する開始ページなど）。
そのため、バージョン管理に追加しないほうがよいでしょう。各開発者が必要な特定の設定を行えるように、VSがそれらを再作成するようにしてください。
.userはユーザー設定であり、私は.suoがソリューションユーザーオプションであると思います。これらのファイルをソース管理下に置かないでください。ユーザーごとに再作成されます。
Rational ClearCase を使用すると、答えは「いいえ」です。 .sln＆。* projだけがソースコード管理に登録されるべきです。
他のベンダーには答えられません。私が正しく思い出したならば、これらのファイルはあなたの環境の "ユーザー"特有のオプションです。
これらのファイルをバージョン管理に追加しないでください。バージョン管理にチェックインすると、ワークステーション固有の情報でこれらのファイルが自動生成されます。他のワークステーションでトラブルを起こします。
いいえ、それらは開発者/マシン固有のローカル設定なので、ソース管理に専念するべきではありません。
GitHubは、 https://github.com/github/gitignore/blob/master/VisualStudio.gitignore で無視するVisual Studioユーザー向けの推奨ファイルタイプのリストを保守しています - ）
Svnについては、私は以下のglobal-ignoreプロパティセットを持っています：
* .DotSettings.User
*。onetoc2
*。suo
。vs
プリコンパイル済みウェブ
thumbs.db
obj
bin
デバッグ
*。ユーザー
*。vshost。*
*。tss
*。dbml.layout
他の回答で説明したように、.suoと.userの両方をソース管理に追加すべきではありません。これらはユーザー/マシン固有です（BTW .suo VSの最新バージョンは専用の一時ディレクトリ.vs。ソース管理から完全に遠ざける必要があります）。
ただし VSでデバッグするために環境の設定が必要な場合（このような設定は通常.userファイルに保持されます）、サンプルファイルを準備すると便利です（.user.SAMPLE）そして、参照のためにソース管理に追加します。
このようなファイルにハードコードされた絶対パスの代わりに、相対パスを使用するか、環境変数に依存することは理にかなっています。
実行可能ディレクトリの依存関係をProjectProperties> Debugging> Environmentで設定した場合、パスは '.user'ファイルに保存されます。
この文字列を上記のフィールドに設定したとします。 "PATH = C：\ xyz\bin"これが '.user'ファイルに格納される方法です。
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
OpenCVで作業している間、これは私たちを大いに助けました。プロジェクトごとに異なるバージョンのOpenCVを使用できます。もう1つの利点は、プロジェクトを新しいマシンにセットアップするのが非常に簡単だったことです。対応する依存関係ディレクトリをコピーするだけです。だからいくつかのプロジェクトでは、私はソース管理に '.user'を追加することを好む。
それにもかかわらず、それは完全にプロジェクトに依存しています。必要に応じて電話をかけることができます。
いや.
本当の短い答えが欲しかったのですが、何もありませんでした。