これはおそらく以前に投稿されていますが、検索する用語がわかりません！Visual Studio：プロジェクト間で共有されるコードを管理する方法
簡単な説明。
いくつかのプロジェクトで共有されるコードがあります。このコードはまだ処理中です。問題は、このコードを何かのために更新する必要があるときはいつでも、私は3回それをしなければならないことを望んでいない、これは悪夢になるだろうということです。
プロジェクトに追加する方法は、プロジェクトのフォルダにそれをコピーせず、ありますか？ つまり私は、共有クラスは、次のように私の3つのプロジェクトにリンクさせたい
C：\コードリポジトリの\ sharedclass.csされていません\ eachproject \ binに
が、それは自分だと私はそれを作成する必要がありますか\のsharedclass.csライブラリプロジェクト？コンパイラがそれを「外部」コードとしてコンパイルできれば、はるかに良いでしょう。
乾杯。
別のプロジェクトのライブラリに共通部分を抽出し、すべてのソリューション/依存プロジェクトにこのプロジェクトの参照を追加することをお勧めします。
そうしないと、Add code/file/item as Linkができます。 Microsoftは今、VSに組み込まれていますオープンソースプロジェクトを支援してい
この特定のインスタンスでは、リンクとして追加が最適に機能しました。 –
リンクが壊れています。 – benderto
はい。
あなたはどこでもあなたのハードドライブ上のソリューションにプロジェクトを追加することができます。したがって、共有コードをクラスライブラリに入れ、3つのプロジェクトに追加します。
これは私が物事を行う方法です。私は、コードのどの部分でも使う多くの有用なものを含む一般的なツールライブラリを持っているので、私が取り組んでいる他のプロジェクトにそのプロジェクトを追加します。コードを変更すると、このプロジェクトを使用する他のアプリケーションで変更されます。リリースする必要があるときは、DLLから作業して「適切なバージョン」として保存することをお勧めします。これはしばらくの間他のプログラムで作業すると、古いプログラムリリース時にDLLを保持していれば、作業が簡単になります。 – Joe
、その呼ばNuGet、あなたはnugetファイルとして出力共有プロジェクトをあなたの他のプロジェクトでそれを消費することができます。
それは実際にあなたがビルド時にパッケージに指定したすべてのファイルを展開します。
これは、.NETが依存関係をサポートする方法です。あなたはEFのようなものでさえ、NuGetパッケージを介して来ることに気付くでしょう。 MyGet.orgのような場所で無料でホストすることもできます。私はこれを使用しています。
はい、別のクラスライブラリプロジェクト内で共有する必要があるコードを入れて、それを構築し、これはあなたの他のプロジェクトに組み込むから作成されたDLLを参照します。
ソリューションエクスプローラでソリューションを右クリックし、[追加]> [既存のプロジェクト]を選択して一般的なプロジェクト.csprojファイルを参照すると、元の場所からソリューションに追加されます。
この2つの問題は、またはあなたのチームのサイズに応じて、問題があってもなくてもよいがあります
1 - 一般的なプロジェクトは、ソリューションファイルへの相対パスで、各溶液中に含まれます（IE：... \ CommonProject \ Common.csproj）。これは、すべての開発者が同じ作業ファイル構造を持つ必要があること、またはメインプロジェクトを開くときにエラーが発生することを意味します。
2 - このシナリオでは、共通のプロジェクトが複数のプロジェクト（例えば2つのAとB）によって参照され、プロジェクトAで作業する開発者は、共通のプロジェクトをタスクの一部として変更する必要があります。その開発者は、プロジェクトBを実際にチェックアウトしてコンパイルすることなく、変更がプロジェクトBを中断するかどうかを知ることはできません。ますます多くのプロジェクトが共通のプロジェクトを参照するにつれて、この事態の危険性は増大し、管理不能に陥ります。次のように
他のが言ってきたように繰り返しますが、これを行うには「正しい」方法はありませんが、しかし、私が取ったアプローチは次のとおりです。
1 - なクルーズコントロールなどの使用継続的インテグレーションは、の建物を管理します共通プロジェクトをサーバー上のスタンドアロンプロジェクトとして配置します。
2 - ソースコントロールの下に、作成された共通DLLを格納するディレクトリを作成します。ビルドマシンでこのディレクトリをチェックアウトし、共通プロジェクトがビルドされるたびに、出力DLLをDLLフォルダにコピーし、これらの変更をソース管理にコミットします。
3 - すべての開発者マシンとビルドサーバーで環境変数を使用して、共通のDLLフォルダの場所を制御し、ハードコードされたパスではなくその変数を使用してDLLを参照します。 （C：\ Source \ MyCommonProjectDLLSに変数MyCommonLocationを設定して、C：\ Source \ MyCommonProjectDLLS \ Common.dllではなくIEを使用します）
4 - 参照するプロジェクト共通DLLは、そのプロジェクトのビルドサーバーで共通DLLフォルダを監視するCIトリガを設定します。変更がコミットされるたびに、構築サーバーはすべての消費プロジェクトを構築する必要があります。
これにより、他のプロジェクトの変更が壊れているかどうかをすぐに知ることができます。唯一の欠点は、このモデルでは、消費するプロジェクトは、作成されるとすぐに共通のDLLに更新を加えることです。別の方法としては、ビルド時にソースコントロールリビジョンから共通DLLをバージョン化し、各バージョンを共通DLLフォルダの下にある独自のサブディレクトリに配置する方法があります。
共通のDLL -1.0.0.1234
-1.0.0.1235
-1.0.0.1236
そしてそうで
：だからで終わるでしょう。これの利点は、各プロジェクトが新しいバージョンのコードを参照するだけで、共通DLLへの更新をいつ受け取るかを選択できることです。しかし、これは両方の方法を削減します。これは、共通コードの古いバージョンが残っているプロジェクトがあることを意味する可能性があるため、最終的にそれらの変更を反映させる作業が増える可能性があるためです。
これが役に立ちます。
チップをありがとう、私はあなたが上記の問題を満たして、あなたの答えは非常に有用だった！ – QtRoS
私はこれを達成するためにgit submodulesを使用します。
ソリューションに共有プロジェクトが含まれるようになりましたので、変更をサブモジュールにプッシュして取り込むことができ、これらの変更は自動的にソリューションに組み込まれます。また、サブモジュールを参照する他のgitリポジトリの変更を見ることもできます。
Visual Studioで "ファイルをリンクとして追加"オプションのような意味ですか？ http://support.microsoft.com/kb/306234（編集：これは単に共有プロジェクトを使用しないことを前提としています） –
ソリューションに異なるプロジェクトを含めて、プロジェクトではなく、コンパイルされた.dll。私たちのソースコードリポジトリには、共有コード（主にクラスライブラリプロジェクト）を含むフォルダがあり、ツリーのまったく異なる領域のソリューションからそれらのプロジェクトを参照します。難しいことは、あなたのチームにこれを直感的に理解させるためにソースコード内にコードを配置する方法を考え出すことです。 （そしてそれを行う "正しい"方法はありません。それを設定する方法は非常に多くの要因に依存しますが、正しく計画するには時間がかかることがあります） – David
http://msdn.microsoft.com/en-us /library/1xhzskbe.aspx –