Создайте проект Visual Studio без доступа к ссылочным DLL

Question

У меня есть проект, который имеет набор двоичных зависимостей (сборные DLL, для которых у меня нет исходного кода). Во время выполнения эти зависимости требуются предварительно установленные на машине, и во время компиляции они требуются в исходном дереве, e, g в папке lib. Поскольку я также создаю исходный код для этой программы, я бы хотел включить простой процесс загрузки и сборки. К сожалению, я не могу распространять DLL, и это усложняет ситуацию, поскольку VS не связывает проект без доступа к ссылочным DLL.

Есть ли все-таки, чтобы этот проект был построен и связан в отсутствие реальных ссылочных библиотек DLL?

Может быть, это способ сказать ВС, чтобы связать с автоматически созданным заглушкой dll, чтобы он мог восстановить без оригинала? Может быть, есть сторонний инструмент, который это сделает? Какие-либо подсказки или рекомендации в этой области?

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

Answer 1

Может быть, один из этих идей поможет вам решить эту проблему:

• Dérivé интерфейсов из всех классов в 3-й партии библиотеки DLL. Поместите эти интерфейсы в собственный проект (такое же решение) и добавьте ссылку на эту сборку интерфейса. Также добавьте EventHandler в AppDomain.AssemblyResolve и попытайтесь найти и загрузить сборки во время выполнения. (Кредиты идут в НГ)
  • В зависимости от того, насколько велики библиотеки DLL и как часто происходят изменения в публичной части, это может вызвать настоящую боль.
• Предоставьте файл readme.txt, в котором объясняется, как получить необходимые сборки и где пользователь должен поместить их относительно пути к проекту. Обычно VS достаточно умен, чтобы удалить восклицательный знак сразу после того, как вы поместили сборку в нужное место, где проект ссылается на нее (возможно, вам нужно нажать обновление в обозревателе решений). (Кредиты отправляются в Пол)
  • Don Не забудьте добавить readme.txt и к своему решению, щелкнув правой кнопкой мыши на своем решении и выберите «Добавить -> Существующий элемент». В этом случае он займет довольно заметное место в visual studio Solution Explorer, и пользователь может прочитать его с двойным щелчком.
• Создайте еще один проект в своем решении, который может автоматически загрузить все необходимые DLL и поместить их в нужное место. Возможно, он должен проверить заранее, нужны ли эти необходимые файлы, прежде чем они начнут загружаться. Задайте Зависимости проектов вашего исходного проекта, чтобы он зависел от этого. Поэтому он всегда будет построен до вашего первоначального. Затем запустите этот инструмент помощника загрузки в событии предварительной сборки вашего исходного проекта и не забудьте выйти из вашей программы с помощью значения int. 0 означает успех, любую другую ошибку, и поэтому Visual Studio знает, был ли ваш инструмент успешным и останавливает процесс компиляции, прежде чем висит на отсутствующих DLL.
  • Возможно, автоматическая загрузка файлов практически невозможна, поэтому вам необходимо войти в систему на веб-странице или использовать файлы cookie, flash, captcha и т. Д., Которые невозможно автоматизировать с помощью инструмента.

Answer 2

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

Answer 3

Довольно радикальная возможность заключается в использовании разделенного шаблона интерфейса и программной загрузки DLL во время выполнения.

Answer 4

Я бы предпочел, чтобы зависимость от compiletime не смогла построить, чем ошибка времени выполнения, которая может занять некоторое время, чтобы отследить.

Вставьте файл Readme.txt в свое решение и четко укажите, что такое зависимости, где их можно получить и что с ними делать.

Answer 5

Всем добрый совет выше, согласился. При этом, может быть, существует допустимый сценарий, когда внешние DLL вообще не нужны? Итак, вот что вы делаете. Вы их обертываете и изолируете. (Его более высокий уровень абстракции, чем создание интерфейсов, поэтому немного легче поддерживать).

В Visual Studio, если вы не перекомпилируете конкретные проекты VS, которые ссылаются на внешние DLL, вы можете уйти с компиляцией остальных проектов VS Solution, не имея этих DLL-файлов. Таким образом, если вы каким-то образом оберните внешние библиотеки DLL своими собственными DLL, а затем распределите эти обертки только как двоичные, человеку, использующему исходный код, не потребуется внешняя библиотека DLL для компиляции основного решения.

Соображения: 1. Дополнительная работа по выделению кода оболочки в изолированные проекты. 2. Другие проекты VS должны добавлять ссылки на ваши DLL-файлы обертки как ссылку «Файловая система» в папку «LIB», а не «Ссылки на проект». 3. Конфигурации VS-решения должны отключать компиляцию для DLL-обертки. При необходимости следует добавить новую конфигурацию, чтобы явно их перекомпилировать. 4. Определение VS-проекта для каждой из Wrapper DLL должно включать событие post-build, чтобы скопировать их в ожидаемое местоположение папки LIB. 5. Во время выполнения внешние библиотеки DLL должны присутствовать в каталоге bin приложения или в GAC компьютера или иным образом явно загружаться. ПРИМЕЧАНИЕ. Если они отсутствуют, это происходит только тогда, когда они фактически вызывают во время выполнения, что их отсутствие приведет к ошибке выполнения. т. е. вам не нужно иметь их, если код не вызывает их в общей ситуации. 6. Во время выполнения вы можете поймать ошибки при загрузке внешних DLL и представить пользователю довольно сообщение об ошибке: «Для того, чтобы пользователь мог эту функцию, установите следующий продукт: xyz». Что лучше, чем отображение «AssemblyLoadException ... используйте FusionLogViewer ... и т. Д.» 7. При запуске приложения вы можете протестировать и обнаружить отсутствующие DLL, а затем отключить определенные функции, зависящие от них.

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