DLL стороннего производителя в SQL Server CLR

14

Мне нужно использовать сторонние библиотеки DLL в коде триггера C # в SQL Server CLR

Но когда я пытаюсь добавить ссылку, он просто показывает некоторые библиотеки DLL из SQL Server.

Как я могу добавить свою стороннюю DLL на SQL Server?

Соломон Руцкий
источник
2
Точно так же, как вы добавляете какие-либо сборки SQL CLR ?

Ответы:

14

Вы можете добавлять ссылки только на те сборки, которые были зарегистрированы на Sql Server. Если они не зарегистрированы, они не будут отображаться в диалоговом окне Добавить ссылки.

Есть несколько шагов, которые вам нужно сделать, чтобы зарегистрировать DLL, во-первых, вам нужно перенастроить базу данных:

ALTER DATABASE [MyDatabase] SET TRUSTWORTHY ON;
sp_configure 'clr enabled', 1;
RECONFIGURE;

Как только это будет сделано, Sql Server будет включен CLR. Далее вам нужно зарегистрировать вашу сборку:

CREATE ASSEMBLY [MyAssembly] AUTHORIZATION [MyUser]
FROM 'C:\CLR\MyAssembly.dll'
WITH PERMISSION_SET = SAFE

Если последний скрипт выполняется правильно, сборка теперь зарегистрирована и появится в диалоговом окне «Добавить ссылки».

Тем не менее, вам нужно учитывать безопасность приложения в конфигурации CLR Sql Server:

  1. Предпочитайте регистрировать сборку как SAFE, только в исключительных случаях вы должны использовать EXTERNAL_ACCESSили UNSAFE.
  2. Не ожидайте, что сможете делать все, что можете, в CLR с полным доверием (т. Е. Не в CLR, размещенном на Sql Server) - SQLCLR - это среда выполнения с песочницей.
  3. Не пытайтесь загружать сборки динамически, так как Assembly.Load()это преднамеренно ограничено.
  4. Возможно, вам придется убедиться, что сторонняя библиотека подписана открытым ключом, если вы планируете ее использовать UNSAFE.
  5. Выполнение кода выполняется в контексте идентификации службы, на которой запущен Sql Server (я думаю!)
  6. Доступ к базе данных из размещенной сборки (например, через context connection = true;) выполняется в контексте подключенного пользователя, поэтому вам необходимо убедиться, что вы знаете, какой доступ имеет эта библиотека к вашим данным.
Мэтью Эбботт
источник
в 4 выше вы пишете, вы должны подписать сборку. Я получил эту часть и смог сделать это с помощью самоподписанных инструкций здесь: geekswithblogs.net/ktegels/archive/2006/02/16/… Но как установить сертификат, когда у вас нет закрытого ключа, то есть когда сборка была создана и подписана доверенной третьей стороной? Насколько я могу судить по ссылке выше, создание сертификата требует наличия закрытого ключа. Это, кажется, делает это невозможным?
ХорхеСандовал
2
Кроме того, маркировка БД как заслуживающей доверия является рискованной (и необязательной для установки «Безопасной» сборки). Надежность - это один из способов подписывать сборки для внешних / небезопасных разрешений, но это не рекомендуется, поскольку любая установленная сборка CLR будет доверенной ...
JorgeSandoval,
5

Я предполагаю, что вы спрашиваете об альтернативах установке сборок SQL CLR из Visual Studio.

Наличие кода в Visual Studio не требуется.

Развертывание объектов базы данных CLR на MSDN детализирует параметры, включая операторы SQL и сценарии развертывания.

Одед
источник
1

Я использую очень большую стороннюю DLL, которая берет веб-страницу и преобразует ее в PDF.

Файл PDF сохраняется в общей папке, а база данных обновляется в соответствии с его местоположением и типом.

Это трехэтапный процесс:

  1. Создайте консольное приложение, которое использует стороннюю DLL для создания PDF, примет URL и FilePath в качестве параметров и возвращает размер PDF и количество страниц.

  2. Создайте хранимую процедуру CLR, которая затем вызывает консольное приложение на сервере.

  3. Я оборачиваю все это в одну хранимую процедуру, которая вызывает приложение CLR для создания PDF, а затем записываю метаданные об этом в базу данных.

Я понимаю, что это не идеально, и вы ни в коем случае не должны делать что-то настолько безумное внутри спускового крючка!

Я упомяну это здесь только для тех, у кого есть вопросы об использовании сторонних DLL в их CLR.

Я надеюсь, что если вы откроете консоль cmd.exe для запуска сторонней библиотеки DLL, вместо запуска всего внутрипроцессного в случае сбоя, это не окажет отрицательного влияния на SQL Server. Это то, что я надеюсь.

Пожалуйста, прокомментируйте, если это действительно плохой подход и почему.

MikeTeeVee
источник