2

さて、これがシナリオです。

プロジェクトAには、そのために開発されたクラスライブラリがあります（これをMyLibと呼びます）。MyLibのバージョン1でプロジェクトA（社内プロジェクト）をリリースします。

プロジェクトBで開発を開始しましたが、既存のタイプに対するいくつかの最適化を含めて、MyLibをバージョン2に拡張します。

Mylib2をプロジェクトAとプロジェクトBの両方にリリースした場合、タイプの変更をサポートするためにプロジェクトAを再コンパイルする必要がありますが、これに対する解決策が試されて真実である人はいますか？

4

7 に答える 7

4

アセンブリのリダイレクトを試して、プロジェクト A に新しいバージョンのライブラリを読み込ませることができます。これには、アプリケーションが実行されているすべてのマシンの構成にリダイレクト情報を追加する必要がありますが、再コンパイルする必要はありません。これは、アプリケーション構成ファイルまたはマシン レベルで行うことができます。

ファイルがどのように見えるかのその記事の例:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="myAssembly"
          publicKeyToken="32ab4ba45e0a69a1"
          culture="en-us" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

もちろん、新しいバージョンで元のライブラリとの互換性を壊した場合、これは機能しません。

于 2009-07-20T21:33:54.877 に答える
3

@Steven のアセンブリ リダイレクトの方向性が気に入らず、プロジェクト A を再コンパイルしたくない場合は、異なるバージョンの MyLib を各プロジェクトに非公開でデプロイできます。
プロジェクト A は引き続きバージョン 1 を使用し、プロジェクト B はバージョン 2 を使用します。MyLib dll を各プロジェクトのフォルダー (またはサブフォルダー) に配置すると、各プロジェクトがそれぞれのローカル バージョンを自動的に取得するか、GAC で厳密な名前を付けて、コンパイルした特定のバージョンを各プロジェクトに取得させることができます。
これは実際にはデフォルトの動作であり、これを実現するために複雑なことを行う必要はありません。

于 2009-07-26T19:34:08.823 に答える
3

MyLib に厳密な名前を付けて、 GAC にインストールします。GAC は、同じアセンブリの複数のバージョンを持つことができます。MyLib のバージョン 1 (バージョン 2 だけでなく) に厳密な名前を付ける必要があります。

プロジェクト A は MyLib のバージョン 1 を必要としており、GAC でそれを見つけます。プロジェクト B は MyLib のバージョン 2 を必要としており、GAC でそれを見つけます。誰もが満足しており、異なるバージョンの MyLib の 30 のコピーを、それらを使用するアセンブリの同じディレクトリに保持して、DLL 地獄を再作成する必要はありません。

AviD が GAC についても言及していたことは知っていますが、実行可能ファイルのプライベート コピーに代わるものとしてです。それは避けるべきだと思います。

于 2009-07-29T16:51:58.617 に答える
1

私の提案: 継続的インテグレーション。

CruiseControl.NET のようなツールを使用すると、存在するすべてのプロジェクト/ソリューションの再構築を行うことができます。1 つの出力 (.dll) を Source CONtrol にアップロードして他のプロジェクトで使用し、毎回単体テストを実行することもできます。ソリューションAで使用されるプロジェクトの追加/編集が、そのプロジェクトを使用してソリューションBを壊さないかどうかを確認できます。ビルドを毎晩自動に設定するか、CruiseControl.NET systray アプリから手動でトリガーすることができます。

于 2009-07-31T09:06:30.380 に答える
0

別のオプションがありますが、最初に他のオプションを真剣に検討する必要があります。

ProjectAはMyLib.dllを参照します。これはたまたまバージョン1です。

MyLibプロジェクトの出力名を調整して、「MyLib.2.dll」を生成します。（新しいプロジェクトを作成することもできますが、それはやり過ぎのように聞こえます。）

MyLibとProjectBを再構築します。ProjectBはMyLib.2.dllを参照するようになり、ProjectAとMyLib.dllは完全に影響を受けなくなります。

于 2009-07-29T16:58:19.147 に答える
0

あなたの質問は非常に一般的です。何を達成したいですか？プロジェクト A は、lib のバージョン 2 または古いバージョンを使用する必要がありますか?

A がバージョン 1 を使用する必要がある場合は、厳密な名前付けまたはプライベート デプロイによって問題が解決するはずです。しかし、あなたはその質問をしていなかったと思います。

A がバージョン 2 を使用する必要がある場合、解決策は変更によって異なります。アセンブリのインターフェイスが変更されていない場合 (内部アルゴリズムのみ)、A は再コンパイルせずに V2 で動作するはずです。インターフェースが変更された場合、とにかくプロジェクト A を調整する必要があり、一般的な解決策はありません。

必要な変更を小さくして管理しやすくすることは、オブジェクト/インターフェースの優れた設計の問題です。しかし、それを行う方法は、オブジェクトと必要な変更に関する詳細なしでは答えられません。

于 2009-07-31T12:45:25.383 に答える
0

Subversion のようなバージョン管理 (ブランチとタグの使用) にすべてのコードを配置し、ビルド プロセスを自動化します。FinalBuilderを使用しています。

ライブラリを制御できるため、リリース ブランチ パターンをお勧めします。

于 2009-07-31T13:07:49.867 に答える