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

14

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

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

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

sql-server c# sql-clr

— Соломон Руцкий
источник

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:

Предпочитайте регистрировать сборку как SAFE, только в исключительных случаях вы должны использовать EXTERNAL_ACCESSили UNSAFE.
Не ожидайте, что сможете делать все, что можете, в CLR с полным доверием (т. Е. Не в CLR, размещенном на Sql Server) - SQLCLR - это среда выполнения с песочницей.
Не пытайтесь загружать сборки динамически, так как Assembly.Load()это преднамеренно ограничено.
Возможно, вам придется убедиться, что сторонняя библиотека подписана открытым ключом, если вы планируете ее использовать UNSAFE.
Выполнение кода выполняется в контексте идентификации службы, на которой запущен Sql Server (я думаю!)
Доступ к базе данных из размещенной сборки (например, через 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 сохраняется в общей папке, а база данных обновляется в соответствии с его местоположением и типом.

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

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

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

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

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

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

— MikeTeeVee
источник