Как лучше всего включить ссылки на мои собственные сборки в шаблон проекта?

Мы разработали библиотеку на C#, и теперь я хочу создать шаблон проекта, чтобы помочь правильно использовать библиотеку.

Я хочу, чтобы новые проекты включали ссылку на сборку библиотеки, но предпочел бы не развертывать сборку в GAC или не зависеть от сборки, находящейся в каком-то определенном месте.

Я думаю о том, чтобы включить .dll в ZIP-файл шаблона проекта. Это означает, что он окажется где-то в папке проекта новых проектов. Возможно, в папке с именем Lib. Тогда справочная подсказка в файле проекта может указывать на эту папку. Это хорошая идея? С какими проблемами я могу столкнуться в дороге?

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


visual-studio-2010 project-template visual-studio-templates
person Tor Haugen    schedule 12.08.2010    source источник
comment
Ответ в некоторой степени зависит от того, как вы планируете развертывать свои шаблоны. Вы используете VSIX? Используете ли вы MSI (установщик Windows) или другую технологию развертывания общего назначения? Вы планировали просто распространять zip-файл и предоставлять инструкции по ручной установке?   -  person Aaron Marten    schedule 20.02.2011

Ответы (1)


arrow_upward
3
arrow_downward

Мне приходилось решать эту проблему в прошлом. В одном случае это была библиотека ведения журналов, которая была установлена ​​в GAC, что означало, что элементу Reference просто требовалось имя сборки. В другом случае мы установили библиотеку в файловую систему, создали раздел реестра, который содержал расположение (на случай, если пользователь поумнел и изменил место установки на нас) и использовали файл мастер шаблонов проектов, чтобы найти раздел реестра и заполнить заменяющий элемент, чтобы иметь правильное расположение в HintPath ссылки. (Примечание: подход мастера шаблонов требует, чтобы вы установили сборку своего мастера в GAC, чего, похоже, вы пытаетесь избежать...)

Если вы не хотите, чтобы ваша библиотека была установлена ​​ни в GAC, ни в определенном месте, подход с включением сборки в проект — практически единственный оставшийся вариант. С положительной стороны, развертывание вашего шаблона проекта довольно простое, и вам не нужно возиться с GAC, пользовательскими мастерами и т. д. С отрицательной стороны, если вы когда-нибудь создадите новую версию своей библиотеки, вашим пользователям понадобится для обновления копии библиотеки каждого проекта.

person Andy Hopper    schedule 25.02.2011
comment
Каковы последствия установки в GAC? каковы причины избегать этого? - person lysergic-acid; 11.05.2011
comment
Основной вывод заключается в том, что выигрывает копия сборки, установленная в GAC. То есть у вас может быть обновленная копия в папке вашего приложения, но пока строгое имя совпадает, среда выполнения будет предпочтительно загружать копию из GAC. Примерно аналогичный пример: путь к сборке, созданной GAC, является первой записью в вашей переменной PATH, и вы выполнили вызов LoadLibrary. Это может привести к странному поведению, когда вы пытаетесь обновить свои двоичные файлы, а поведение загадочным образом не меняется. - person Andy Hopper; 15.06.2011
comment
Кроме того, хотя это и не является проблемой GAC, использование строгих имен означает, что вашей сборке теперь требуется сборка, совпадающая со строгим именем, для которого она была скомпилирована; вам придется либо перекомпилировать, либо зарегистрировать политику издателя, которая перенаправляет привязки к более новой версии. - person Andy Hopper; 15.06.2011