Автоматизированное развертывание смешанного решения SSIS / DLL

Question

В настоящее время у нас есть решение, разработанное с использованием SSIS / C #. Пакет служб SSIS (помимо прочего) имеет задачу сценария, которая использует логику, разработанную в библиотеках классов. Эта функция должна оставаться отдельной от пакета служб SSIS.

Поскольку мы используем пакет служб SSIS, я понимаю, что скомпилированные библиотеки DLL необходимо развернуть в GAC, а затем ссылаться на них из задачи сценария. Однако это создает для нас проблему развертывания.

Наш инструмент автоматического развертывания (справедливо) автоматически увеличивает номера версий DLL, которые затем публикуются в GAC. Однако это нарушает пакет служб SSIS, поскольку он пытается получить доступ к библиотекам DLL на основе номера версии, которую они опубликовали на компьютере разработчика GAC как.

Единственное решение, которое у нас есть, - это получить скомпилированные библиотеки DLL, вручную изменить задачу сценария пакета служб SSIS, а затем опубликовать пакет.

Кажется, должен быть лучший способ сделать это - кто-нибудь сталкивался с этой проблемой и придумал лучшее решение? Или есть что-то фундаментальное в нашем подходе, который мы должны изменить (помимо устранения необходимости в DLL)?

Спасибо!

Answer 1

Ну, после долгих исследований я так и не нашел удовлетворительного решения для этого. В конце концов, самое близкое, что я мог получить, - это решение, в котором я загружал свои ссылки динамически:

    Dim rsAssembly As Assembly = Assembly.LoadFile("path from config file")
    Dim rsType As Type = rsAssembly.GetType("class name from config file")
    Dim obj As Object = Activator.CreateInstance(rsType)

Это позволило мне создать нужный мне объект (хотя стоит отметить, что любые другие зависимые ссылки также должны динамически загружаться или быть частью GAC, хотя бы без зависимости от номера версии).

Размещено здесь для будущих искателей, но если кто-нибудь придумает что-то лучше, мне все равно было бы очень любопытно узнать, как вы решили это - напишите здесь, и я предоставлю вам ответ :)

Answer 2

В моем случае, просто позвонить Assembly.LoadFile не сработало. Что сработало, так это подход:

Вызовите это в конструкторе класса:

AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);

А затем используйте этот метод со всеми необходимыми dll:

 private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
 {
     if (args.Name.Contains("libName.dll"))
         return Assembly.LoadFile(System.IO.Path.Combine(_libraryFolder, "libName.dll"));

     if (args.Name.Contains("libName2.dll"))
         return Assembly.LoadFile(System.IO.Path.Combine(_libraryFolder, "libName2.dll"));

     return null;
 }

Если их много, вы можете реорганизовать это с List<string>.

Answer 3

Я заметил аналогичные проблемы с нашим миксом SSIS / C #. Мы также полагаемся на внешнюю (для SSIS) dll. В нашем случае DLL нужно было скопировать в каталог 100 / DTS / Binn, чтобы позволить пакету SSIS работать из Visual Studio, однако, когда мы пытаемся запустить пакет с помощью утилиты выполнения пакета SQL, мы получаем ошибку, связанную с тем, что файл не найден Кажется, это не указывает на проблему с версией, а на разницу в PATH между Visual Studio и служебной программой выполнения пакетов. Даже запуск пакета без отладки из Visual Studio работает. Я собираюсь посмотреть на проблему с версией, чтобы выяснить, не является ли это основной жалобой в нашей системе, но по памяти я думаю, что это была ошибка типа "файл не найден", который затронул нас. Мы используем MSSQL 2008, если это имеет значение.

Answer 4

Вы абсолютно уверены, что эти общие библиотеки DLL должны быть развернуты в GAC? Если они находятся в той же папке, что и пакет служб SSIS, они должны быть обнаружены платформой без необходимости добавлять их в GAC.

Нет ли способа обновить систему сборки, чтобы избежать изменения номера версии? Если код этих сборок не меняется, обновлять номер версии не нужно.

Если вы не можете избежать увеличения версии, другой альтернативой является создание файла политики вместе с общими сборками и использование его для «перенаправления» пакета служб SSIS на новую версию с каждой сборкой.