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

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

Есть два способа, которыми я ссылаюсь на код для включения в проект:

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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