データベースのリバースエンジニアリングの中には、私自身の質問に対する答えがあります。このプロセスは私にとってはうまくいったが、それが誰にとってもうまくいくとは保証できない。
プラグイン登録ツールを使用してプラグインアセンブリを置き換えると、3つのことが行われます。
1)そのプラグインのPluginAssemblyBaseレコードのOverwriteTime列が変更されます。 2)追加したばかりのプラグインのアセンブリに対して、新しいPluginAssemblyBaseレコードが追加されます。 3)DependencyNodeBaseレコードのTopSolutionId列のレコードがプラグイン用に変更されます。
このため反転処理は、次のSQLクエリを使用して行った:
BEGIN TRANSACTION
DELETE dbo.PluginAssemblyBase
WHERE PluginAssemblyIdUnique <> @originalPluginAssemblyIdUnique and Name = @assemblyName and OverwriteTime = 0
UPDATE dbo.PluginAssemblyBase SET
OverwriteTime='1900-01-01 00:00:00.000'
WHERE PluginAssemblyIdUnique = @originalPluginAssemblyIdUnique
UPDATE dbo.DependencyNodeBase SET
TopSolutionId = @ManagedSolutionId
WHERE Objectid = @pluginAssemblyId
COMMIT TRANSACTION
このスクリプトは、他の人が使用することができますが、変数の設定に加えて、あなたがそうそこにいくつかの検証を追加することもできます間違ったシナリオでは使用されないことを示します。
質問してもらえない場合は、PluginAssemblyテーブルの観点から見てどうですか?管理ソリューションのインポートを実行すると、管理対象行と非管理対象行の両方が削除されますか?または、PluginRegistrationToolを使用してプラグインをアップロードする行為は、そのアセンブリ名のインスタンスを1つだけテーブルに保持しますか? – Jason
管理されていないバージョンは、タイプに関係なく管理対象コンポーネントの上に決して置かれません。すべてのアンマネージドコンポーネントがデフォルトソリューションにマージされます。ロールバックすることはできません。 –
@ArunVinoth私はあなたのコメントが間違っていると確信しています。デフォルトソリューションのアンマネージドコンポーネントは、それらのコンポーネントのアンマネージバージョンが公開されている場合、管理対象コンポーネントがUXに適用されないように適用されます。これは、私が複数のソース、例えば、複数形、個人的な経験などから訓練されたものです。あなたはどのソース資料から作業していますか?レビューするのは面白いだろう。 – Jason