Ссылки на библиотеки DLL в ASP.NET без \ Bin или GAC

У меня есть проект ASP.NET в системе управления версиями (Subversion). По разным причинам я не хочу добавлять каталог \ Bin или его содержимое в систему управления версиями, поэтому он игнорируется svn :. Библиотеки DLL загружаются сюда во время сборки Visual Studio, и я могу начать с чистого каталога и / или удалить все содержимое этого каталога и все равно получить успешную сборку.

Я могу использовать код для включения в проект двумя способами:

  1. В элементе Web.config //configuration/configSections/system.web/compilation/assemblies. Таким образом я могу <add> любую DLL, находящуюся в GAC. Я делаю это для всех системных dll.
  2. В решении VS есть параметр в Project / ProjectSection / ProjectReferences, который позволяет мне указать включенные ссылки на другие проекты в решении.

(Обратите внимание, что это отличается от не веб-проектов, где все ссылки на внешние зависимости хранятся в файле проекта. Для веб-проектов VS нет файла проекта, поэтому их нужно хранить где-то еще.)

Теперь у меня есть скомпилированная сторонняя DLL, которую я хотел бы включить в проект. К сожалению, ни один из найденных мной вариантов ссылок не работает для меня:

  1. Ссылка через web.config / system.web / compilation / assemblies не работает, если DLL не существует в GAC; вы не можете использовать путь к файлу. Я действительно хотел бы избежать зависимости от GAC, поскольку это будет означать дополнительный шаг, чтобы проект работал на каждой целевой машине.
  2. Я не нашел способа включить ссылку на файл в решение, как это можно сделать со ссылками на проекты.
  3. Каждый раз, когда я добавляю ссылку на файл с помощью диалогового окна VS «Добавить ссылку», он просто копирует DLL в каталог \ Bin. Для меня это не сработает, поскольку мой каталог \ Bin не сохраняется в разных системах.

Есть ли другой способ сделать ссылку на файл DLL и сохранить его?


person Craig Walker    schedule 13.01.2010    source источник


Ответы (5)


Если вы занимаетесь какой-либо серьезной разработкой, я бы порекомендовал перейти от проекта веб-сайта к веб-проекту, поскольку это позволяет вам управлять зависимостями такого рода одинаково во всем решении.

Однако, предполагая, что вы не можете этого сделать, поместите все сборки, на которые вам нужно ссылаться из веб-проекта, в какую-нибудь папку (например, lib \ web) и добавьте событие предварительной сборки в свой веб-проект, которое копирует содержимое этой папки. в папку bin веб-каталога. Теперь всякий раз, когда вы хотите добавить зависимость к своему веб-проекту, вы можете поместить ее в папку lib \ web и добавить ссылку. При каждой сборке все сборки, на которые есть ссылки, будут скопированы в папку, чтобы вы могли удалить папку bin или выполнить чистую проверку без каких-либо проблем.

person Neal    schedule 15.01.2010
comment
Предлагаемое вами решение не работает: мы не можем добавить событие предварительной сборки на веб-сайт. - person remi bourgarel; 04.08.2011

Технически на шаге 3 происходит еще кое-что. Visual Studio копирует DLL в каталог \ Bin и добавляет файл name.dll.refresh, содержащий путь к исходной DLL. В SourceSafe файл .refresh находится под контролем версий, поэтому при настройке новой системы и получении последнего кода из SourceSafe Visual Studio может найти и скопировать DLL из указанного места. Вы должны иметь возможность поместить файл .refresh в svn, и все будет работать.

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

person Jason Berkan    schedule 13.01.2010
comment
Я задумался об этом. Однако, чтобы получить .refresh в SVN, мне нужно иметь \ bin, а если у меня есть \ bin, я мог бы просто скопировать туда DLL. - person Craig Walker; 14.01.2010
comment
Поправьте меня, если я ошибаюсь, но даже с \ Common в решении вам все равно придется вручную копировать DLL и / или .refresh в \ Bin, верно? - person Craig Walker; 14.01.2010
comment
.Refresh создается автоматически, когда вы добавляете DLL с помощью функции «Добавить ссылку». Пока вы помещаете его в систему управления версиями и имеете DLL в одном месте на всех машинах, все работает. Другие машины загружают .refresh из системы управления версиями и во время сборки копируют DLL из указанного места. Преимущество помещения .refresh в систему управления версиями вместо библиотеки DLL состоит в том, что файл .refresh не затрагивается во время сборки. DLL есть, что приводит к ненужной проверке при каждой сборке. - person Jason Berkan; 14.01.2010

Единственный способ, о котором я до сих пор думал, - это заставить мой сценарий сборки NAnt копировать DLL из внешнего (версионного) каталога lib в каталог \ Bin перед сборкой. Мне это не очень нравится, потому что он вводит зависимость процесса за пределами Visual Studio: разработчики должны убедиться, что библиотека скопирована, прежде чем пытаться создать внутри VS.

person Craig Walker    schedule 13.01.2010

Я сохраняю сторонние сборки без исходного кода в системе управления версиями. В их собственном каталоге вне проекта - `C: \ Projects \ 3rdPartyAssemblies '. Таким образом, любые проекты / разработчики, которым они нужны, могут ссылаться на них.

person Shawn    schedule 13.01.2010
comment
Но как сделать так, чтобы ссылка на DLL была прикреплена к проекту? В этом суть моего вопроса. - person Craig Walker; 14.01.2010
comment
Извините, я не уверен, что понимаю вас. Вы можете включить ссылку на файл так же, как и ссылку на проект, выбрав вкладку обзора. Он копирует его в каталог bin, но по-прежнему сохраняет ссылку. - person Shawn; 14.01.2010
comment
На самом деле, в моем тестировании он не поддерживает ссылку за пределами наличия файла в каталоге \ bin. Если вы закроете решение и удалите DLL / .refresh, то при повторном открытии решения ссылка исчезнет из диалогового окна. В отличие от ссылок на проекты или GAC, ссылки на файлы поддерживаются только при наличии файла в \ Bin - если нет другого способа сделать это, о чем я прошу. - person Craig Walker; 14.01.2010
comment
Я понимаю. Это проект веб-приложения ASP.NET или просто веб-сайт ASP.NET? Потому что я создал новый проект веб-приложения, добавил ссылку на внешнюю dll, использовал dll в коде, построил, удалил каталог bin, снова запустил, и все заработало. - person Shawn; 15.01.2010

Ссылки на проекты хранятся в файле .csproj или .vbproj, который должен находиться в системе контроля версий. Файл .refresh совершенно не важен и является вспомогательным файлом для студии. Если вы создаете каталог, локальный для проекта или решения, и храните все скомпилированные ссылки, которых еще нет в GAC, в этом каталоге, вы можете затем добавить этот каталог в систему управления версиями и ссылаться непосредственно оттуда. Таким образом, все разработчики гарантированно будут иметь самую последнюю копию (из системы контроля версий) .dll при выполнении следующей компиляции, и это никогда не повлияет на / bin.

Убедите ваших разработчиков «получить последнюю версию» ... в этом вы сами по себе. Я так и не понял.

Может быть, еще одна памятка.

person Joel Etherton    schedule 14.01.2010
comment
На веб-сайтах нет файлов .csproj или .vbproj, поэтому используется файл .refresh. - person Jason Berkan; 14.01.2010
comment
Вы правы, сэр. Я оговорился. Ссылки для проекта веб-сайта фактически хранятся под ключом ProjectReferences в файле .sln (который веб-сайт должен требовать, но не может). Вупс. - person Joel Etherton; 14.01.2010