11

これはおそらく以前に投稿されたものですが、どの検索用語を探すべきかわかりません。

簡単な説明。

いくつかのプロジェクト間で共有されるコードがあります。このコードはまだ進行中です。問題は、このコードを更新する必要があるときはいつでも、3回更新する必要がないということです。これは、悪夢になります。

プロジェクトフォルダにコピーせずに、プロジェクトに追加する方法はありますか？つまり、共有クラスを3つのプロジェクトにリンクさせたい

C：\ code repository \ sharedclass.cs NOT \ eachproject \ bin \ sharedclass.cs

独自のライブラリプロジェクトとして作成する必要がありますか？コンパイラがそれを「外部」コードとしてコンパイルできれば、はるかに良いでしょう。

乾杯。

4

6 に答える 6

7

他の人が言ったように、ソリューション エクスプローラーでソリューションを右クリックし、[追加] > [既存のプロジェクト] を選択して、共通プロジェクトの .csproj ファイルを参照すると、元の場所からソリューションに含まれます。

ただし、これには 2 つの問題があり、チームの規模に応じて、問題になる場合とならない場合があります。

  1. 共通プロジェクトは、ソリューション ファイルへの相対パス (つまり、...\CommonProject\Common.csproj) を使用して各ソリューションに含まれます。これは、すべての開発者が同じ作業ファイル構造を持っている必要があることを意味します。そうしないと、メイン プロジェクトを開こうとしたときにエラーが発生します。

  2. 共通プロジェクトが複数のプロジェクト (たとえば、A と B の 2 つ) によって参照されており、プロジェクト A で作業している開発者がタスクの一部として共通プロジェクトに変更を加える必要があるというシナリオでは、その開発者が知る方法はありません。彼らが行った変更により、実際にプロジェクトBをチェックアウトしてコンパイルすることなくプロジェクトBが壊れる場合。より多くのプロジェクトが共通プロジェクトを参照するにつれて、これが発生するリスクは管理不能になるまで増加します。

繰り返しますが、他の人が言ったように、これを行う「正しい」方法はありません。ただし、私が取ったアプローチは次のとおりです。

  1. Cruise Control などの継続的インテグレーションを使用して、プロジェクトのビルドを管理し、共通プロジェクトをスタンドアロン プロジェクトとしてサーバーに配置します。

  2. ソース管理下にディレクトリを作成して、ビルドされた共通 DLL を格納します。ビルド マシンでこのディレクトリをチェックアウトすると、共通プロジェクトがビルドされるたびに、出力 DLL が DLL フォルダーにコピーされ、これらの変更がソース管理にコミットされます。

  3. すべての開発者のコ​​ンピューターとビルド サーバーで環境変数を使用して、共通の DLL フォルダーの場所を制御し、ハードコードされたパスではなく、その変数を使用して DLL を参照します。(つまり、C:\Source\MyCommonProjectDLLS\Common.dll ではなく、変数 'MyCommonLocation' を C:\Source\MyCommonProjectDLLS に設定して $(MyCommonLocation)\Common.dll を使用します)

  4. 共通 DLL を参照するプロジェクトの場合、そのプロジェクトのビルド サーバーに CI トリガーを設定して、共通 DLL フォルダーを監視します。変更がコミットされるたびに、ビルド サーバーはすべての使用プロジェクトをビルドする必要があります。

これにより、他のプロジェクトの重大な変更をコミットしているかどうかがすぐにわかります。唯一の欠点は、このモデルでは、使用するプロジェクトが、作成されるとすぐに共通 DLL への更新を強制されることです。別の方法として、共通 DLL をビルド時にソース管理リビジョンからバージョン管理し、各バージョンを共通 DLL フォルダーの下の独自のサブディレクトリに配置する方法があります。したがって、次のようになります。

一般的な DLL
-1.0.0.1234
-1.0.0.1235
-1.0.0.1236

等々。この利点は、コードの新しいバージョンを参照するだけで、各プロジェクトが共通 DLL を更新するタイミングを選択できることです。ただし、これは一部のプロジェクトが必要以上に古いバージョンの共通コードを残されていることを意味するため、両方の方法をカットします。これにより、最終的にそれらの変更を導入するときに関連する作業が増加する可能性があります。

于 2012-12-28T14:59:33.887 に答える
5

はい。

ハード ドライブのどこからでもプロジェクトをソリューションに追加できます。共有コードをクラス ライブラリに入れ、それを 3 つのプロジェクトに追加します。

于 2012-12-28T14:22:47.420 に答える
4

Microsoft は現在、VS に組み込まれているオープン ソース プロジェクト (NuGet と呼ばれる) をサポートしています。共有プロジェクトを nuget ファイルとして出力し、他のプロジェクトで使用することができます。

ビルド時に、パッケージで指定したすべてのファイルを実際にデプロイします。

これが、現在 .Net が依存関係をサポートする方法です。EF のようなものでさえ、NuGet パッケージを通じて提供されることに気付くでしょう。MyGet.org のような場所で無料でホストすることもできます。私はこれを使用していますが、非常にうまく機能します。

http://nuget.org/

于 2012-12-28T14:25:12.520 に答える
2

これを実現するためにgit サブモジュールを使用します。

  1. ソリューション間で共有するモジュール (プロジェクト) ごとに新しい git リポジトリを作成します。通常、そのプロジェクトの単体テストも別のプロジェクトに含めますが、同じ git リポジトリに含めます。
  2. 共有コードを使用するソリューションの git リポジトリにサブモジュールを追加します。サブモジュールを追加すると、外部リポジトリの特定のコミットへのリンクが作成されます。サブモジュールのコードが更新されると、更新を親ソリューションにプルできるようになります。これは、サブモジュール コミットへの参照を更新することと本質的に同じです。SourceTreeのようなアプリを使用すると、プロセスを簡単に視覚化できることがわかりました。
  3. サブモジュールを追加して最新のコミットをプルすると、親ソリューション フォルダー内に共有プロジェクトのコピーが作成されます。ソリューションを右クリックし、[既存のプロジェクトを追加] を選択して、プロジェクトを親 Visual Studio ソリューションにインポートします。
  4. プロジェクトを右クリックして [参照の追加] を選択し、[ソリューション] タブで共有プロジェクトを見つけて、それを使用する他のプロジェクトに共有プロジェクトへの参照を追加します。

共有プロジェクトがソリューションに含まれるようになったので、変更をサブモジュールにプッシュおよびプルできるようになり、これらの変更は自動的にソリューションに組み込まれます。サブモジュールを参照する他の git リポジトリの変更も確認できます。

于 2017-01-05T23:11:23.790 に答える
0

はい、共有する必要があるコードを別のクラス ライブラリ プロジェクトに配置してビルドし、このビルドから作成された DLL を他のプロジェクトで参照します。

于 2012-12-28T14:40:20.303 に答える
-1

共通部分を別のプロジェクト ライブラリに抽出し、このプロジェクトの参照をすべてのソリューション/依存プロジェクトに追加することをお勧めします。

それ以外の場合は、コード/ファイル/アイテムを Link として追加できます。

于 2012-12-28T14:23:19.633 に答える