SQL Serverからアセンブリを削除せずにCLRアセンブリを更新する方法

SQL Server（2008 R2）でアセンブリを削除して再作成することなく、CLR関数（またはプロシージャ）アセンブリdllを更新するにはどうすればよいですか？

（たとえば、新しい関数を追加するために）アセンブリを更新した場合、SQL Serverはアセンブリを削除するまで更新されたdllを受け入れません。

DROP ASSEMBLY CLRFunctions

Msg 6590, Level 16, State 1, Line 1
DROP ASSEMBLY failed because 'CLRFunctions' is referenced by object 'NormalizeString'.

しかし、アセンブリを削除する前に、最初にアセンブリを参照するすべての関数を削除する必要があります。

DROP FUNCTION NormalizeString
DROP FUNCTION RemoveDiacritics
DROP FUNCTION RemoveCombiningDiacritics
DROP FUNCTION CombineLigatures
....
DROP FUNCTION PseudolocalizeArabic

そして、私はアセンブリをドロップすることができます：

DROP ASSEMBLY CLRFunctions

次に、アセンブリを「作成」する必要があります。

CREATE ASSEMBLY CLRFunctions FROM 'c:\foos\CLRFunctions.dll';

そして今、私はそれらを削除する前に登録されたすべてのUDFの宣言を捜さなければなりません。

私はむしろアセンブリを更新し、SQL Serverにそれを使い始めさせたいです。

更新：ランダムにDBCC FREEPROCCACHE「再コンパイル」を試みましたが、SQL Serverは引き続き古いコードを使用します。

更新：アセンブリdllを削除しましたがCLRFunctions.dll、SQL Serverはコードを実行できます（不可能なはずのコードなし）。

探していると思いますalter assembly。BOLから：

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

同じページにある例の1つは、そのトリックを実行するようです。

ALTER ASSEMBLY ComplexNumber 
FROM 'C:\Program Files\Microsoft SQL Server\90\Tools\Samples\1033\Engine\Programmability\CLR\UserDefinedDataType\CS\ComplexNumber\obj\Debug\ComplexNumber.dll' 

Ben Thulの答えに追加するために、これはSQL Server Management StudioのGUIを介してリモートでかなり簡単に実現できます。

1. データベースのオブジェクトエクスプローラ->プログラマビリティで、アセンブリを右クリックし、「新しいアセンブリ...」を選択します。

2. 更新されたDLLを参照します。

3. [OK]をクリックする代わりに（同じ名前のアセンブリが既に存在するため失敗します）、[新しいアセンブリ]ウィンドウの上部にある[スクリプト]をクリックします。
    
   「CREATE ASSEMBLY」行に続いて、選択したDLLである巨大なblobを含むSQLクエリにドロップされます。

4. 「作成」を「変更」に変更してから実行してください！

スクリプトは、実行前に削除する必要がある「AUTHORIZATION」行も作成しました。あなたの走行距離は異なる場合があります。

これが、サーバーへのファイルシステムアクセスなしで、他の誰かに役立つことを願っています。

MicrosoftがいつかSSMSでこれをファーストクラスの操作にすることを願っていますが、そうなるまでこれはかなり簡単な回避策です。

Stackoverflowの答えにヒントを見つけました：

ALTER ASSEMBLY CLRFunctions FROM 'c:\foos\CLRFunctions.dll';