2011-12-01 17 views
0

私は社内で使用するためのWebアプリケーションを作成しています。 Person、EmailAddressなどの抽象クラスを含む "General.dll"クラスライブラリを1つ作成し、Employee:Person、EmployeeEmailAddress:EmailAddressなどのクラスを含む "EmployeeManagement.dll"を作成しました。どのように相互に参照するクラスライブラリを効果的に管理できますか?

My EmployeeManagement.dllが参照して、General.dllに依存しています。

私のWebアプリケーションはEmployeeManagement.dllを参照します。

どのようにしてカスケード変更を効果的に追跡できますか?たとえば、私がGeneral.dllを変更した場合、そのクラスライブラリを新しいGeneral.dllに再コンパイルし、それを使用する他のすべてのクラスライブラリで新しいGeneral.dllを参照することを忘れないでください。それらのライブラリは再コンパイルする必要がありますし、Webアプリケーションのリファレンスも同様に更新することを忘れてはいけません。これを処理するツールや効率的な方法が必要です。任意のヒント?

+1

Visual Studioのすべてのプロジェクトが1つのソリューションに含まれているわけではありませんか? –

+0

ありがとうございます。 General.dllのように使用する必要がありますが、別のソリューションの一部である無関係な将来のプロジェクトがあれば、私の主な関心事/不明確です。私は、そのソリューションのために別々のGeneral.dllを作成することができましたが、会社全体でどこでもコードを繰り返さないという最大の効率を目指しています。誰かが立ち上がり、「私は抽象クラスの一般的なクラスライブラリを持っていたらいいのに...」と言うと、「一般的なリポジトリのファイルを手に入れてこのWebアプリケーション。 – CptSupermrkt

答えて

2

まず、すべてのプロジェクトをVisual Studioの同じソリューションに追加すると、変更を加えたときに依存関係に基づいて自動的に適切な再構築が行われます。

また、開発中に、特定のバージョンのアセンブリへの参照を追加したくない場合もあります(これは、[参照の追加]を選択したときのデフォルトです)。このようにして、General.dllの変更は自動的に次のビルドで参照する他のプロジェクトにカスケードされます。


編集OP

からアップデートした後は、さまざまなソリューションのプロジェクトを再利用するのは非常に自由です。したがって、正確にはGeneral.dllのコードベースを1つしか持たず、必要なソリューションにそのプロジェクトを含めることができます。そのような場合は、General.dllを変更する際に、それを含むプロジェクトが破損しないように注意する必要があります(ここでは、継続的な統合ユーティリティが役立ちます)。

+2

"Projects"への参照を追加して、DLLバイナリを削除しないように注意してください。また、プロジェクトの依存関係を管理して、この自動構築を修復(または破損)する方法もあります。 –

+0

その情報をありがとう!私はちょっとぼんやりとした部分を詳述したオリジナルの質問にコメントをしました。 – CptSupermrkt

+0

@CptSupermrktコメントの後に更新されました –

関連する問題