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

Question

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

Существует два способа ссылаться на код для включения в проект:

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

.

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

Может быть, еще одна записка.

Answer 4

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

Answer 5

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