Вызов неуправляемых функций C / C ++ DLL из SQL Server 2008 - PullRequest
Новая
       44

Вызов неуправляемых функций C / C ++ DLL из SQL Server 2008

5 голосов
/ 16 декабря 2011

У меня есть обширная библиотека функций C / C ++, которую нужно вызывать из SQL Server 2008. Я написал класс адаптера C #, который загружает эти функции из Win32 DLL с DllImport и предоставляет их .Net-коду. Это прекрасно работает в большинстве приложений .Net.
Теперь я пытался использовать ту же технику с SQL Server CLR. Я создаю набор функций CLR и хранимых процедур, которые вызывают класс адаптера. Это не работает, поскольку попытка загрузить неуправляемую DLL приводит к System.BadImageFormatException.
Я могу сделать это с помощью расширенных хранимых процедур, но этот метод устарел и может быть прекращен в любом новом выпуске SQL Server.
Каков будет правильный способ вызова неуправляемых функций из хранимой процедуры CLR? Я думаю, что это должно быть сделано вне процесса.

Я пытаюсь заставить мой хранимый процесс вызывать веб-сервис, который предоставляет эти функции. Это звучит как хорошая идея, но до сих пор у меня возникают проблемы с развертыванием сборки SQLCLR, которая выполняет вызов веб-службы. Я не могу загрузить System.ServiceModel.dll сборку version=3.0.0.0, которая зависит от System.Web.dll версии сборки 2.0.0.0.

Загрузка System.Web сборка выдает мне следующую ошибку:

Сборка 'System.Web' ссылается на сборку 'system.web, версия = 2.0.0.0, культура = нейтральная, publickeytoken = b03f5f7f11d50a3a.', Которой нет в текущей базе данных. SQL Server попытался найти и автоматически загрузить указанную сборку из того же места, откуда пришла ссылающаяся сборка, но эта операция завершилась неудачно (причина: несовпадение версии, языка или открытого ключа). Загрузите указанную сборку в текущую базу данных и повторите ваш запрос.

Я нашел решение проблемы развертывания System.Web сборки. Вместо того, чтобы развертывать его с C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Web.dll, его следует развертывать с C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll. Затем будут развернуты все остальные необходимые сборки.

Список сборок в порядке развертывания:

  • 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 \ Справочные сборки \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.dll
  • C: \ Program Files \ Справочные сборки \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.Selectors.dll
  • C: \ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation \ Microsoft.Transactions.Bridge.dll

1 Ответ

1 голос
/ 16 декабря 2011

Интересное обсуждение здесь: MSDN - Неуправляемый код в SQL CLR . Я подозреваю, что это связано с тем, как DLL загружаются движком. Они предоставляют ряд опций, включая размещение кода за пределами сервера SQL в другой службе и доступ к коду с помощью WCF или, возможно, COM. Последний вариант - возможно, перекомпилировать ваш код в чистый управляемый C ++, но это может быть не вариант для унаследованного кода.

Понимание интеграции CLR в SQL Server 2005 предоставляет дополнительную информацию о том, как работает процесс.

Для дальнейшего ограничения кода, который может существовать и выполняться внутри SQL Server каждая сборка должна быть зарегистрирована с набором разрешения. Три предопределенных набора доступны для использования; БЕЗОПАСНЫЙ, EXTERNAL_ACCESS и UNSAFE ...

Вам также следует просмотреть CLR Integration Security и определить уровни доверия, необходимые для исполняемого кода, и сможете ли вы в любом случае получить доступ к использованию кода в процессе CLR.

...