2011-12-15 179 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过程中访问使用的代码反正。