0

単一の SharePoint インスタンスによって使用される同じ GAC に展開されている (はるかに多くの) 2 つの SharePoint パッケージによって共有/使用される Common.dll があります。共有アセンブリは、製品の配置から製品の配置へと進化し、それ自体が製品として扱われることはありません。それ自体はリリースされません。他の SharePoint 製品/パッケージのコンテキストでのみ進化します。

共通アセンブリは、主に再利用性の高いコードの単なるリポジトリです。これは、開発者の小規模な社内チームによってのみ使用されます。

分岐/マージにより、開発者の都合に合わせて、さまざまな製品が Common.dll の最新バージョンを使用できるようになります。各製品の開発作業では、Common.dll の新しいバージョンを採用するリスクがスケジュールされています。

私が必要としているのは、これらのアセンブリを製品から製品へ、つまり SharePoint パッケージから SharePoint パッケージへと分離して動作させることです。

しかし、それは起こっていません。代わりに、展開するたびに、Common.dll が GAC で上書きされ、Common.dll を使用するすべての製品がこの最新バージョンの Common.dll の動作を受け取るようになります。その動作の内容によっては、しばらくデプロイされていない製品が破損する可能性があります。

その「サプライズ！」展開を防ごうとしているのです。Common.dll を公的な製品のように扱う必要がない可能性があり、重大な変更などを慎重に回避する必要があります。

さまざまな SharePoint パッケージを単一の SharePoint インスタンスの GAC に展開するときに、共通アセンブリの個別のバージョンを保持するために使用する手法は何ですか?

4

2 に答える 2

0

このコマンドは、共通アセンブリの Visual Studio プロジェクトのビルド前イベントで使用します。

if not "$(SolutionName)" == "ABC" if not "$(TargetFileName)" == "$(ProjectName).$(SolutionName).dll" exit 1

このビルド前のコマンドは、共通のアセンブリがさまざまな製品で使用されるため、変更する必要はありません。「ABC」を共通アセンブリのソリューション ファイルの名前に置き換えると、次のようになります。

独自のソリューションで共通アセンブリをコンパイルする場合 (これはまれですが、起こります)、考慮すべきことは何もありません。それ以外の場合は、使用する製品の Visual Studio ソリューション ファイル名に従って共通アセンブリの名前を変更していない限り、ビルドは失敗します。

ビルドの失敗を避けるために、(共通アセンブリ プロジェクトのプロパティ ページを介して) 使用する製品のコードベースに分岐した後で、共通アセンブリの名前を変更します。共通アセンブリのプロジェクト名はソリューション エクスプローラーで変更されず、プロパティ ページで既定の名前空間も変更されません。「アセンブリ名」のみが変更されます。そのため、製品固有の変更が加えられた場合を除き、共通コードの維持と使用は常に慣れているように感じられます。ソリューション エクスプローラーと名前空間は、開発している製品に関係なく同じままです。

名前を変更すると、共通アセンブリのプロジェクト ファイル内の 1 行が変更されます。これにより、トランクにマージし直すとき (および/または後でトランクから他の製品にマージするとき) に摩擦が生じます。

共通のプロジェクト ファイルが、ProductA のアセンブリに名前を付けたまま、ProductB のコードベースに侵入した場合、ビルド前のコマンドによって、ProductB でのコンパイルが妨げられます。この場合、開発者はコンパイルを許可するために "アセンブリ名" を簡単に変更できます。この摩擦の機会は、マージすればするほど増加します。

共通アセンブリは、新しい SharePoint 製品が GAC に到着するたびに、GAC で一意の名前 (およびインスタンス) を取得します。さまざまな製品が共通のアセンブリを使用、展開、および展開でき、展開時に他の製品/パッケージが突然破損する心配がありません。

于 2012-04-18T20:47:46.683 に答える