4

アセンブリ内にあるCLRストアドプロシージャを作成しました。

ソース管理リポジトリから.netアプリケーションを自動ビルドしてデプロイできるビルドシステムがあります。

2つのものを連携させて、CLRストアドプロシージャをホストするアセンブリを再デプロイできるようにします。

ただし、IISとは異なり、バイナリを置き換えるだけでは機能しないようです。データベースにDROPASSEMBLYを作成する必要があるようです。これを行うには、そのアセンブリを参照するすべてのオブジェクトを削除する必要があります。

これは、ある意味では合理的であるように見えます。つまり、データベースの整合性の観点からは合理的であり、別の意味では不合理です。一般に.NETの依存関係の実行時評価に適用されるJITアプローチです。

それで、バイナリを置き換えてからSQLサーバーにキックを与え、新しいアセンブリがすべての要件を満たしている（つまり、sprocを満たすための適切なパブリック名前空間、タイプ、メソッドなどを持っている）ことを理解できるようにするために何かを行うことは可能ですか？それにバインドされています）。

4

4 に答える 4

6

CLRアセンブリはディスクではなくデータベースに保存されるため、バイナリdllを単純に置き換えることはできません。それらを更新するには、を使用しますALTER ASSEMBLY [assemblyname] FROM 'disklocation'。

于 2009-08-19T18:15:27.143 に答える
3

簡単な答えは「いいえ、このようには機能しません」です。Remusが指摘したように、SQL Serverは、ファイルシステムのどこかにではなく、データベース内にアセンブリを格納します。したがって、サーバーによって監視され、更新されたバイナリを配置する必要がある場所はありません。

更新されたアセンブリをデータベースにアップロードすることは、デプロイメントプロセスの不可欠な部分である必要があります。そして、次のアクションを明示的に実行するためにそれを行う唯一の方法：

  1. アセンブリで定義されているすべてのオブジェクト（つまり、すべての外部SP / UDF /トリガー/タイプ）を削除します
  2. ドロップアセンブリ
  3. アセンブリを作成します-「FROM'disklocation'」（Remusのアドバイスに従いますが、パスはSQL Serverのローカルパスを参照する必要があることに注意してください）または「FROM'binarycontent'」のいずれかを使用します
  4. すべての[外部]オブジェクトを作成します

ステップ1は、実際には一般的な方法でT-SQLに実装できます（したがって、オブジェクトを明示的にリストする必要はありません）。ただし、カスタムツール（アセンブリコンテンツを検出し、すべてのオブジェクトを作成するための適切なT-SQLを生成するためにリフレクションを使用する）を除いて、p.4にはそのような方法はありません。

于 2009-08-19T19:36:09.897 に答える
2

Remusの回答が述べているようALTER ASSEMBLY ...に、アセンブリを更新するために使用できます。

MSDNページからSQLServer2008R2用のALTERASSEMBLY（Transact-SQL） [強調鉱山]：

FROM句が指定されている場合、ALTER ASSEMBLYは、提供されたモジュールの最新のコピーに関してアセンブリを更新します。SQL Serverのインスタンスには、アセンブリに対して既に定義されているCLR関数、ストアドプロシージャ、トリガー、データタイプ、およびユーザー定義の集計関数が存在する可能性があるため、ALTERASSEMBLYステートメントはそれらをアセンブリの最新の実装に再バインドします。この再バインドを実行するには、CLR関数、ストアドプロシージャ、およびトリガーにマップするメソッドが、同じ署名を持つ変更されたアセンブリにまだ存在している必要があります。CLRユーザー定義型およびユーザー定義集計関数を実装するクラスは、ユーザー定義型または集計であるための要件を満たしている必要があります。

したがって、アセンブリを参照する関数やストアドプロシージャなどが変更されていない場合は、アセンブリを更新するだけで済みます。また、そうしても、現在実行中のセッションが中断されることはありません。上記と同じMSDNページから：

ALTER ASSEMBLYは、変更中のアセンブリでコードを実行している現在実行中のセッションを中断しません。現在のセッションは、アセンブリの変更されていないビットを使用して実行を完了します。

ただし、アセンブリとその依存オブジェクトを自動的にかなり簡単に再配置できますが、通常、再配置するには、アセンブリを削除して再作成する必要があります。その場合、最初にアセンブリファイルのバイトを16進数に変換し、関連するCREATE ASSEMBLYステートメントに含めることで、アセンブリをスクリプトに「埋め込む」ことで、アセンブリを展開する方が簡単な場合があります。

于 2014-08-18T15:46:20.897 に答える
0

最後の文を除いて、AlexSが提案したことに同意します。

まず、CLR関数で使用されるデータ型が必ずしもSQLデータ型を決定するわけではないため、リフレクションは実際には機能しません。たとえば、CLR側でSqlStringを使用できますが、SQL側ではNVARCHAR（4000）の代わりにNVARCHAR（50）またはNVARCHAR（MAX）を使用します。

ただし、これを自動化することは可能です。他のストアドプロシージャまたは関数と同じように、ソースコードリポジトリを使用して、CLRコードを指すストアドプロシージャおよび関数の定義を格納する必要があります。したがって、これらの定義をすべて取得し、ステップ4としてすべてのCREATEPROCEDUREステートメントとCREATEFUNCTIONステートメントを実行できます。

また、ステップ1と2は単一のSQLスクリプトにすることができます。

基本的に、このプロセス全体を自動化できます:)。

于 2011-01-22T15:12:34.443 に答える