Ссылочный DLLs в ASP.NET без \Bin или GAC
У меня есть проект ASP.NET при управлении исходным кодом (Подверсия). По различным причинам я не хочу добавлять \Bin каталог или его содержание к управлению исходным кодом, таким образом, у меня есть он svn:ignored. DLLs загружаются в здесь во время сборки Visual Studio, и я могу запустить с чистого каталога и/или удалить все содержание этого каталога и все еще иметь успешную сборку.
Существует два способа, которыми я ссылаюсь на код для включения в проект:
- В элементе Web.config//configuration/configSections/system.web/compilation/assemblies. Я могу
- В Решении VS существует установка в Project/ProjectSection/ProjectReferences, который позволяет мне указать включенные ссылки на другие проекты в решении.
(Обратите внимание, что это отличается, чем невеб-проекты, где все ссылки на внешние зависимости хранятся в файле проекта. Нет никакого файла проекта для веб-проектов VS, таким образом, они должны быть сохранены где-то в другом месте.)
Теперь у меня есть сторонний скомпилированный DLL, который я хотел бы включать в проект. К сожалению, ни одна из опций ссылки, которые я нашел, кажется, не работает на меня:
- Ссылка через web.config/system.web/compilation/assemblies не работает, если DLL не существует в GAC; Вы не можете использовать путь к файлу. Я действительно хотел бы избежать зависимости GAC, поскольку это будет означать дополнительный шаг делать работу проекта над каждой целевой машиной.
- Я не нашел способ включать ссылку на файл в решение как, я могу сделать со ссылками проекта.
- Любое время я добавляю ссылку на файл с помощью VS, "Добавляют Ссылочное" диалоговое окно, это просто, копирует DLL в \Bin каталог. Это не будет работать на меня, поскольку мой \Bin каталог не является персистентным через системы.
Есть ли иначе, я могу сделать ссылку на файл DLL и иметь его палка?
5 ответов
Если вы делаете какой-либо серьезное развитие, я бы порекомендовал мигрировать из проекта веб-сайта и веб-проекту, поскольку это позволяет вам управлять этими видами зависимостей таким же образом Весь раствор.
Тем не менее, предполагая, что вы не можете сделать это, поместите все собрания, которые вам нужно иметь ссылку на веб-проекте в папку где-то (например, lib \ Web) и добавить событие предварительного сборки в свой веб-проект, который копирует контент этой папки в папку Bin веб-каталога. Теперь, когда вы хотите добавить зависимость в свой веб-проект, вы можете бросить его в папку lib \ Web и добавить ссылку. Всякий раз, когда вы создаете, все ссылочные сборки будут скопированы в папку, чтобы вы могли удалить папку Bin или сделать чистую оформление заказа и не иметь никакой проблемы.
Технически, на шаге 3 немного больше случается. Visual Studio копирует DLL в свой каталог \ bin и добавляет файл name.dll.refresh, который содержит путь к исходной DLL. С помощью Sourcesafe файл .refresh находится под контролем версии, чтобы при установке новой системы и получите последний код из SourceSafe, Visual Studio можно найти и скопировать DLL из указанного местоположения. Вы должны быть в состоянии поставить файл .refresh в SVN и иметь все работать.
Кроме того, я, как правило, создаю \ Common Directory выше моего каталога проекта, который находится в том случае, если я помещаю DLL, и я включаю в себя этот каталог в решении (и контроль источника), так что каждая версия моего проекта в исходном управлении имеет правильные dlls.
Я эконому 3-й партийные сборки без исходного кода в контроле источника. В своем каталоге за пределами проекта - «C: \ projects \ 3rdpartyassemblies» таким образом какие-либо проекты / разработчики, которые им нужны, могут ссылаться на них.
Единственный способ, о котором я думал до сих пор, - это чтобы мой сценарий NAnt build script скопировал DLL из внешнего (версированного) lib каталога в каталог \Bin перед сборкой. Мне это не очень нравится, так как это вводит зависимость от процесса, которая находится вне Visual Studio: разработчики должны убедиться, что библиотека скопирована, прежде чем пытаться собраться внутри VS.
Ссылки на проект хранятся в файле .csproj или .vbproj, который должен быть под контролем источника. Файл .refresh совершенно неактуальен и является только файлом помощи для студии. Если вы создадите локальный каталог для проекта или решения и сохраните в этом каталоге все скомпилированные ссылки, которые еще не находятся в GAC, то вы можете добавить этот каталог в управление исходными текстами и ссылки непосредственно оттуда. Таким образом, все разработчики гарантированно получат самую последнюю копию (из управления исходным кодом) .dll при следующей компиляции, и это никогда не повлияет на /bin.
Заставляя ваших разработчиков "Получить последнюю версию" ... вы сами по себе для этого. Я до сих пор не разобрался.
Может быть, еще одна записка.