2011-12-15 45 views
5

Tôi có một thư viện rộng lớn các hàm C/C++, cần được gọi từ SQL Server 2008. Tôi đã viết một lớp C# adapter tải các hàm này từ Win32 DLL với DllImport và hiển thị chúng với mã .Net. Điều này hoạt động hoàn toàn tốt trong hầu hết các ứng dụng .Net.
Bây giờ, tôi đã cố gắng sử dụng cùng một kỹ thuật với SQL Server CLR. Tôi tạo một tập các hàm CLR và các thủ tục lưu sẵn, gọi là lớp bộ điều hợp. Điều này không hoạt động như một nỗ lực để tải kết quả DLL không được quản lý trong System.BadImageFormatException.
Tôi có thể làm điều này với các thủ tục được lưu trữ mở rộng, nhưng phương pháp đó không được chấp nhận và có thể bị ngưng trong bất kỳ phiên bản mới nào của SQL Server.
Điều gì sẽ là cách thích hợp để gọi các hàm không được quản lý từ thủ tục lưu sẵn CLR? Tôi đoán rằng điều này nên được thực hiện out-of-process.Gọi hàm không được quản lý C/C++ DLL từ SQL Server 2008


Tôi đang cố gắng làm cho proc được lưu trữ gọi dịch vụ web hiển thị các chức năng này. Điều này nghe có vẻ giống như một ý tưởng hay, nhưng cho đến nay tôi đang gặp vấn đề khi triển khai lắp ráp SQLCLR để thực hiện cuộc gọi dịch vụ Web. Tôi không thể tải System.ServiceModel.dll lắp ráp version=3.0.0.0, có phụ thuộc vào System.Web.dll phiên bản lắp ráp 2.0.0.0.

tải System.Web lắp ráp mang lại cho tôi những lỗi sau:

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.

Tôi đã tìm thấy giải pháp cho vấn đề của việc triển khai System.Web lắp ráp. Thay vì triển khai nó từ C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Web.dll, nó sẽ được triển khai từ C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll. Sau đó, tất cả các hội đồng yêu cầu khác cũng được triển khai.

Danh sách các cụm theo thứ tự triển khai:

  • C: \ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation \ 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 \ Tham chiếu tập hợp \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.dll
  • C: \ Program Files \ Tham chiếu Assemblies \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.Selectors.dll
  • C: \ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation \ Microsoft.Transactions .Bridge.dll
+0

Bạn đang cố tải một dll không được quản lý 32 bit vào máy chủ 64 bit? – GSerg

+0

Là một tham chiếu phụ, [điều này có thể được thực hiện ngoài quy trình] (http://stackoverflow.com/questions/752357/sql-server-2008-how-crash-safe-is-a-clr-stored- thủ tục-tải-không quản lý-l), nhưng tôi chắc chắn nó không phải là một yêu cầu. – GSerg

+0

Vâng, tôi cần phải làm điều đó bất kỳ cách nào có thể. Có, 32-bit không được quản lý, tôi tin rằng máy chủ là 32-bit, nhưng trên hệ điều hành 64-bit. Tôi thấy bài đăng đó. Họ đang sử dụng các thủ tục được lưu trữ mở rộng, không được chấp nhận. – Ramzay

Trả lời

1

Thảo luận xen kẽ tại đây: MSDN - Unmanaged code in SQL CLR. Tôi nghi ngờ đó là do làm thế nào các DLL được nạp bởi động cơ. Họ trình bày một loạt các tùy chọn bao gồm lưu trữ mã bên ngoài máy chủ sql trong một dịch vụ khác và truy cập mã bằng WCF hoặc có lẽ COM. Tùy chọn cuối cùng là có thể biên dịch lại mã của bạn thành C++ được quản lý thuần túy nhưng điều này có thể không phải là một tùy chọn cho mã kế thừa.

Understanding CLR Integration in SQL Server 2005 trình bày thêm thông tin về cách thức hoạt động của quy trình.

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 ...

Bạn cũng nên xem xét CLR Integration Security, và detemrine mức tín nhiệm cần cho mã bạn đang thực hiện và cho dù bạn sẽ có thể truy cập sử dụng các mã trong quá trình CLR anyway.

+0

Cảm ơn. Điều này là thú vị, nhưng thực sự không cung cấp một giải pháp. – Ramzay

Các vấn đề liên quan