Разработайте Проект Visual Studio без доступа к dlls, на который ссылаются,
У меня есть проект, который имеет ряд двоичных зависимостей (блок dlls, для которого я делаю не имеют исходный код). Во времени выполнения те зависимости требуются предварительно установленные на машине, и во время компиляции они требуются в исходном дереве, e, g в папке lib. Поскольку я также делаю исходный код доступным для этой программы, я хотел бы включить простую загрузку и опыт сборки для нее. К сожалению, я не могу перераспределить dlls, и это усложняет вещи, начиная со ссылки привычки VS проект без доступа к dlls, на который ссылаются.
Там должен так или иначе позволить этому проекту быть созданным и связанным в отсутствие реального dlls, на который ссылаются?
Возможно, существует способ сказать VS связываться против автоматического сгенерированного тупика dll, так, чтобы он мог восстановить без оригинала? Возможно, существует сторонний инструмент, который сделает это? Какие-либо подсказки или лучшие практики вообще в этой области?
Я понимаю, что у человека должен быть доступ к dlls для выполнения кода, таким образом, он имеет смысл, что он мог добавить их к процессу сборки, но я просто пытаюсь сохранить их боль сбора всего dlls и размещения их в папке lib вручную.
5 ответов
Возможно, одна из этих идей поможет вам решить проблему:
- Получите интерфейсы из всех классов в сторонних dll. Поместите эти интерфейсы в собственный проект (то же решение) и добавьте ссылку на эту сборку интерфейса. Также добавьте обработчик событий в AppDomain.AssemblyResolve и попробуйте найти и загрузить сборки во время выполнения. (Кредиты принадлежат NG)
- В зависимости от того, насколько велики библиотеки DLL и как часто вносятся изменения в общедоступную часть, это может стать настоящей проблемой.
- Предоставьте файл readme.txt, в котором вы объясняете, как получить необходимые сборки и куда пользователь должен поместить их относительно пути к проекту. Обычно VS достаточно умен, чтобы удалить восклицательный знак сразу после того, как вы поместите сборку в нужное место, откуда проект ссылается на нее (возможно, вам придется нажать кнопку обновления в обозревателе решений) (Благодарности принадлежат Полу)
{ {1}}
- Не забудьте также добавить файл readme.txt в свое решение , щелкнув правой кнопкой мыши свое решение и выбрав «Добавить -> Существующий элемент». В этом случае он займет довольно заметное место в обозревателе решений Visual Studio, и пользователь сможет прочитать его двойным щелчком.
- Создайте в своем решении еще один проект, который сможет автоматически загружать все необходимые библиотеки DLL и размещать их в нужном месте. Возможно, ему следует заранее проверить, есть ли эти необходимые файлы, прежде чем он начнет загрузку. Установите Project Dependencies вашего исходного проекта, чтобы он зависел от этого. Так что он всегда будет построен раньше вашего оригинального.Затем запустите этот вспомогательный инструмент загрузки в событии предварительной сборки исходного проекта и не забудьте выйти из программы со значением int. 0 означает успех, любая другая ошибка, и поэтому Visual Studio знает, успешно ли работал ваш инструмент, и останавливает процесс компиляции, прежде чем зависнет на отсутствующих dll.
- Возможно, автоматическая загрузка практически невозможна файлы, потому что вам нужен вход на веб-страницу или используются файлы cookie, flash, captcha и т. д., что не может быть автоматизировано с помощью инструмента.
Согласен со всеми приведенными выше хорошими советами. При этом, может быть, есть допустимый сценарий, когда внешние DLL обычно не нужны? Итак, вот что вы делаете. Вы их оборачиваете и изолируете. (Это более высокий уровень абстракции, чем создание интерфейсов, поэтому его немного проще поддерживать).
В Visual Studio, если вы не перекомпилируете определенные проекты VS, которые ссылаются на внешние библиотеки DLL, вы можете уйти с компиляцией остальных проектов решений VS, не имея под рукой этих DLL. Таким образом, если вы каким-то образом обернете внешнюю DLL своей собственной DLL, а затем распространите эти оболочки только как двоичные, человеку, разделяющему ваш исходный код, не потребуется внешняя DLL для компиляции основного решения.
Соображения : 1. Дополнительная работа по разделению кода оболочки на отдельные проекты. 2. Другие проекты VS должны добавлять ссылки на DLL-оболочки вашей оболочки как ссылки «Файловая система» на папку «LIB», а не «Ссылки на проекты». 3. Конфигурации VS Solution должны отключать компиляцию для DLL-оболочки. При необходимости следует добавить новую конфигурацию, чтобы явно перекомпилировать их. 4.Определение VS Project для каждой библиотеки DLL Wrapper должно включать событие после сборки, чтобы скопировать их в ожидаемую папку «LIB». 5. Во время выполнения внешняя библиотека DLL должна присутствовать в каталоге bin приложения или в глобальном кэше компьютера, либо быть загружена иным образом. ПРИМЕЧАНИЕ. Если они отсутствуют, их отсутствие приведет к ошибке выполнения только тогда, когда они действительно вызываются во время выполнения. т.е. вам не нужно их иметь, если код не вызывает их в общей ситуации. 6. Во время выполнения вы можете отловить ошибки при загрузке внешней библиотеки DLL и представить пользователю красивое сообщение об ошибке: «Чтобы использовать эту функцию, установите следующий продукт: xyz». Это лучше, чем отображение «AssemblyLoadException ... используйте FusionLogViewer ... и т. Д.» 7. При запуске приложения вы можете протестировать и обнаружить отсутствующие библиотеки DLL, а затем отключить определенные функции, которые от них зависят.
Например: согласно этому шаблону у меня могло бы быть приложение, которое интегрируется с Microsoft CRM и SAP, но только для определенной функции, то есть импорта / экспорта.
Во время разработки, если разработчику никогда не понадобится менять оболочку, он сможет перекомпилировать без этих внешних DLL.
Во время выполнения, если пользователь никогда не вызовет эту функцию, приложение никогда не будет вызывать оболочку, поэтому внешние библиотеки DLL не нужны.
Тогда избавьте их от необходимости собирать все сборки и поместите их в папку lib самостоятельно. Затем зафиксируйте их вместе с исходным кодом в репозитории. Таким образом, люди, проверяющие код из репозитория, также получат все, что необходимо для компиляции проекта.
Я бы предпочел, чтобы зависимость времени компиляции приводила к сбою моей сборки, чем ошибка времени выполнения, на отслеживание которой может потребоваться некоторое время.
Поместите файл Readme.txt в свое решение и подробно объясните, что это за зависимости, где их взять и что с ними делать.
Достаточно радикальной возможностью было бы использовать разделенный шаблон интерфейса и программно загружать библиотеки DLL во время выполнения.