Вызов, который использует DLL с агентом SQL Server, требует, чтобы DLL была установлена ​​на вызывающем компьютере, а не на компьютере, на котором установлен пакет - PullRequest
1 голос
/ 10 сентября 2009

У нас есть пакет служб SSIS 2005, который установлен на центральном сервере и вызывается из нескольких мест. Этот пакет использует задачу сценария для вызова библиотеки .NET DLL, которую я написал на c # и установил в GAC на центральном сервере. Когда я вызываю пакет служб SSIS с того сервера, на котором установлен пакет, все в порядке.

Когда я вызываю пакет с удаленного сервера с помощью агента SQL Server, задание не выполняется, сообщая, что не может найти DLL.

Просто чтобы проверить, что происходит, я установил dll на удаленный сервер, и пакет успешно выполнен. Таким образом, получается, что, хотя пакет установлен на одном компьютере, при вызове с другого с использованием функции SQL Server он фактически выполняется на вызывающем компьютере, и именно вызывающий компьютер должен удовлетворять всем зависимостям.

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

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

1 Ответ

1 голос
/ 10 сентября 2009

К сожалению, вам придется изменить свой дизайн, поскольку хранилище пакетов служб SSIS - это просто хранилище. Выполнение всегда происходит на компьютере, с которого вызывается пакет, и все ссылки обрабатываются как относящиеся к этому компьютеру.

Один из вариантов - добавить задачу в пакет служб SSIS, который копирует и регистрирует DLL в GAC вызывающей машины, но если у вас нет контроля над некоторыми из исполняющих машин, нет гарантии, что исполняющий агент SQL учетная запись будет иметь достаточные права для регистрации DLL.

Другим решением будет преобразование кода DLL в задачу сценария внутри пакета служб SSIS. Это будет означать преобразование кода из C # в VB, и может быть нетривиальным в зависимости от деталей вашего кода.

Без более подробной информации о назначении пакета и функциональности библиотеки DLL сложно оценить другие альтернативы, но вы могли бы подумать, можно ли параметризировать пакет, чтобы он всегда запускался с сервера хранения.

...