ASP.NET и Visual Studio - добавление ссылок на проект в сравнении с DLL-папкой Bin

Question

Я только что начал новую работу вчера, и это только моя вторая работа в ASP.NET. Мы настраивали мой ящик разработчика и имели проблемы с некоторыми сторонними компонентами, такими как Telerik и т. Д. Я заметил, что они установили эти сторонние инструменты, отыскивая файлы DLL, копируя их в корзину и добавляя ссылку на проект, который указывает на файл в BIN. Мне это не кажется нормальной практикой.

У меня сложилось впечатление, что если вы просто сбросите DLL в папку bin, вам не нужно добавлять ссылку, она просто доступна? Причина в том, что на моей последней работе мы использовали несколько библиотек классов, которые мы создали для доступа к данным, и просто удалили библиотеки DLL на любых новых веб-сайтах (не веб-приложениях), которые мы создали. Я не помню, чтобы мне приходилось добавлять ссылку, чтобы она заработала.

Итак, может ли кто-нибудь объяснить, как добавлять сторонние ссылки в ваше веб-приложение? Вы добавляете ссылку, где DLL установлена ​​в системе? Если это так, вы проверяете копировать локальный, чтобы он копировал в корзину? Вы просто копируете dll в корзину и все? Вы копируете dll в корзину, а затем добавляете туда ссылку?

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

Answer 1

Это зависит от того, как настроен ваш проект. Если вы хотите предварительно скомпилировать свой сайт (и заставить Intellisense работать должным образом), у вас должна быть ссылка на Visual Studio. Но все, что упало в папке bin, будет автоматически загружено ASP.NET во время выполнения ... так что можно получить доступ к элементам управления / объектам этой сборки в коде без добавления ссылки на проект.

Для небольших проектов я просто добавляю DLL в корзину и добавляю ссылку. Для более сложных сайтов / проектов у меня есть специальная папка «библиотека» для сторонних надстроек и кода.

Answer 2

Мы контролируем версии наших сторонних сборок, используя Subversion, затем перетаскиваем их через svn: externals в подкаталог рассматриваемого решения или проекта, который затем ссылается на них (и копирует в bin) .

Это дает довольно много преимуществ:

1. Серверы сборки более счастливы, требуют меньшего количества обслуживания и менее хрупки.
2. У нас есть история выпусков, и мы можем явно контролировать управление версиями для каждого решения / проекта, устанавливая номер редакции для каждого svn: external. Например, код транка может использовать последнюю версию Telerik, но ветки выпуска используют старые версии.
3. Мы можем делиться сторонними сборками для разных проектов и быть уверенными, что они используют правильные версии.
4. Мы не полагаемся на то, что разработчики устанавливают или обновляют до нужной версии, однако они могут добавлять и тестировать новые версии, не мешая другим проектам (при условии, что вы явно определили ревизию)
5. Мы можем тестировать новые версии, но легко возвращаемся, если что-то не работает.

Так что немного больше работы по настройке, но я думаю, это того стоит. Обратите внимание, что мы не контролируем версии (svn: ignore) наших каталогов bin и obj, и сторонние сборки находятся в одном и том же хранилище Subversion, на которое ссылается относительный путь.

FWIW: Subversion 1.6.6 исправляет досадную ошибку для файловых svn: externals. Это означает, что вы можете выбрать один или несколько файлов (например, сборок) из каталога вместо того, чтобы тянуть весь каталог вниз.

2013 Обновление

С появлением NuGet рассмотрите возможность размещения собственного фида через локальный сервер, прежде чем использовать svn: externals, просто потому, что он дает вам те же преимущества, плюс он запекается в Visual Studio через Extension Manager и обеспечивает лучшую информацию и метаданные, например, возможность сообщить разработчикам о выходе новой версии.

Единственным предостережением будет размещение вашего канала с использованием сервера Win2008 или выше, так как я столкнулся с некоторыми проблемами с нашим старым сервером Win2003, использующим SSL с аутентификацией Windows для обеспечения безопасности канала. Я полагаю, что это произошло из-за более старой версии IIS, используемой в Win2003, но не смог проверить.

Answer 3

Си очень правильно там. Также: сохраните папку bin для результатов сборки / компиляции. Как сказано, прежде чем использовать папку «библиотека» для ссылки на. Я даже делаю это с devexpress.

Обычно, устанавливая devexpress, он устанавливает свои библиотеки DLL в GAC, и вы можете ссылаться на них так же, как ссылки на стандартные библиотеки DLL .Net. Но для контроля версий гораздо проще использовать папку библиотеки.

Таким образом, вы можете быть уверены, что все используют одну и ту же версию devexpress (ту, которая находится в SourceSafe) для тестирования своего кода, и у вас будет меньше проблем с кодом, который компилируется на вашем компьютере, но не работает другой.

Answer 4

Обычно я просто бросаю их в мусорное ведро, если это не часть чего-то, что не так просто. Например, Sitecore устанавливает себя и имеет несколько папок, которые ему нравится использовать для размещения своего кода, чтобы привести пример чего-то нетривиального.

Answer 5

Я всегда предпочитаю иметь ссылку на проект, а не на ссылку DLL. Ниже приведены основные причины этого.

• Проект, который добавляет ссылку на другой проект, не будет обновлен.
• Любые изменения в упомянутом проекте не отражаются напрямую. Пользователь должен вручную удалить старую ссылку и добавить новую ссылку.