В настоящее время я борется с проблемами развертывания, вызванными Microsoft.SqlServer.Types и связанной с ним неуправляемой библиотекой, SqlServerSpatial110.dll - как для Microsoft SQL Server 2012. Проблемы тривиально легко решить, просто типичные проблемы с DLL, но я стараюсь чтобы выбрать идеальный способ справиться с этими зависимостями.
Во-первых, я должен заявить, что не согласен с популярным мнением о том, что ручное развертывание любой библиотеки (обычно путем копирования их в выходной каталог проекта или, что ужасно, в System32) является правильным. Microsoft предоставляет распространяемые MSI-инсталляторы для этих файлов, и эти установщики помещают файлы в системные местоположения. Кажется очевидным, что они хотят, чтобы мы зависели от того, какие распространяемые компоненты устанавливались отдельно или как часть проверенных и проверенных механизмов зависимостей, встроенных в MSI.
Во время публикации последняя версия этих распространяемых материалов может быть загружена с помощью: http://www.microsoft.com/en-gb/download/details.aspx?id=43339
Для SqlServerSpatial110.dll проблема не возникает. Установщики MSI (специфичные для платформы) переносят файл в Windows\System32 или Windows\SysWOW64, как это уместно, и все хорошо.
Библиотека управляемых оберток Microsoft.SqlServer.Types.dll более запутанна.
Мне кажется, что файл упал в глобальный кэш сборок - после запуска MSI на моей машине я вижу, что он находится в C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.Types\11.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Types.dll, и этот файл имеет правильную версию и измененную дату.
Как ни странно, я не вижу его в справочном браузере Visual Studio или в проводнике Windows напрямую - только в моем очень старомодном инструменте поиска файловой системы Mythicsoft. Почему я не вижу этого?
Поскольку файл находится почти в GAC, я бы предположил, что проекты, ссылающиеся на него, должны не создавать локальную копию этого файла - они должны полагаться на то, что они находятся в целевой системе. Я протестировал это предположение, и он сработал:
- Вручную скопируйте
Microsoft.SqlServer.Types.dllиз своего местоположения вC:\Windows\assembly\GAC_MSIL - Добавьте ссылку на копию.
- Убедитесь, что ссылка
Copy Localустановлена наFalse - Создайте проект и убедитесь, что
Microsoft.SqlServer.Types.dllопределенно не присутствует в выводе. - Проект тестирования... нет проблем!
Итак, если сборку можно решить из GAC во время выполнения, чтобы удовлетворить эту зависимость, почему она не отображается в справочном браузере при добавлении ссылки? Зачем мне копировать его из GAC и ссылаться на копию?
На мой взгляд, идеальный рабочий поток будет следующим:
- Установите распространяемые MSI на машинах разработки.
- Убедитесь, что распространяемое приложение установлено на целевых компьютерах, указав его как зависимость MSI, если ваш продукт развернут через MSI или вручную его установит, если вы используете развертывание "xcopy".
- Ссылка
Microsoft.SqlServer.Typesиз GAC с использованием справочного браузера, как и любая библиотека фреймворка. (Copy Localпо умолчанию будет установленоFalse.) - Во время выполнения,
Microsoft.SqlServer.Types(агностика платформы) будет устранена из GAC, и соответствующая копия неуправляемой библиотеки будет загружена из системного местоположения в зависимости от архитектуры процесса. - Не беспокойтесь!
Ясно, что шаг 3 не выполняется. Я что-то упускаю? Возможно, я неправильно понимаю сам GAC - это будет не первый раз. Почему Microsoft сделала это так? Могу ли я приблизиться к своему идеальному рабочему потоку?
Возможно, существует совершенно другой способ управления этой зависимостью - то, о чем я явно не думал. Если так, то, что это? Как вы справляетесь с этим?
