2011-12-15 185 views
5

我有一個龐大的C/C++函數庫,需要從SQL Server 2008調用。 我已經編寫了一個C#適配器類,它從Win32 DLL中加載這些函數與DllImport並將它們暴露給.Net代碼。這在大多數.Net應用程序中完美地工作。
現在,我試圖使用與SQL Server CLR相同的技術。我創建了一組調用適配器類的CLR函數和存儲過程。這不會在System.BadImageFormatException中嘗試加載非託管DLL結果。
我可以使用擴展存儲過程來做到這一點,但該方法已棄用,並且可能會在任何新版本的SQL Server中停用。
從CLR存儲過程中調用非託管函數的正確方法是什麼?我猜這應該是在進程外完成的。從SQL Server 2008調用非託管C/C++ DLL函數


我想讓我存儲的proc調用一個暴露這些函數的Web服務。這聽起來像個好主意,但到目前爲止,我遇到了部署使Web服務調用的SQLCLR程序集的問題。我無法加載System.ServiceModel.dll程序集version=3.0.0.0,它依賴於System.Web.dll程序集版本2.0.0.0

加載System.Web集會給了我以下錯誤:

Assembly 'System.Web' references assembly 'system.web, version=2.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.', which is not present in the current database. SQL Server attempted to locate and automatically load the referenced assembly from the same location where referring assembly came from, but that operation has failed (reason: version, culture or public key mismatch). Please load the referenced assembly into the current database and retry your request.

我已經找到了部署System.Web裝配的問題的解決方案。應該從C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll部署,而不是從C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Web.dll部署它。然後所有其他所需的程序集也會部署。

組件的部署順序列表:

  • C:\ WINDOWS \ Microsoft.NET \框架\ 3.0 \ Windows通訊基礎\ SMdiagnostics.dll
  • C:\ WINDOWS \ Microsoft.NET \ Framework64 \ v2.0.50727 \ System.Web.dll
  • C:\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ System.Messaging.dll
  • C:\ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.dll
  • C:\ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.Selectors.dll
  • C:\ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation \ Microsoft.Transactions .Bridge.dll
+0

您是否試圖將32位非託管dll加載到64位服務器中? – GSerg 2011-12-15 22:47:46

+0

作爲一個側面引用,[這可能是在進程外](http://stackoverflow.com/questions/752357/sql-server-2008-how-crash-safe-is-a-clr-stored- procedure-that-loads-unmanaged-l),但我確定這不是必需的。 – GSerg 2011-12-15 22:51:12

回答

1

相關討論在這裏:MSDN - Unmanaged code in SQL CLR。我懷疑這是由於DLL是如何被引擎加載的。他們提出了一系列選項,包括將代碼託管在另一服務中的sql服務器之外,並使用WCF或COM訪問代碼。最終的選擇是或許將您的代碼重新編譯爲純託管的C++,但這可能不適用於遺留代碼。

Understanding CLR Integration in SQL Server 2005提供了關於過程如何工作的更多信息。

To further restrict the code that is allowed to exist and execute inside SQL Server each assembly must be registered with a set of permissions. Three pre-defined sets are available to use; SAFE, EXTERNAL_ACCESS and UNSAFE ...

您還應該查看CLR Integration Security,並且detemrine信任級別需要爲你執行代碼,以及您是否可以對CLR過程中訪問使用的代碼反正。