Для GAC или не для GAC?

Question

У меня есть уровень доступа к данным (DAL), который написан на ASP.NET 3.5 и использует библиотеки шаблонов и практик Microsoft (в дальнейшем именуемые P & P) для обеспечения доступа к данным. Я установил P & P, и он находится в моем GAC, поэтому, логически, мой DAL ссылается на него в GAC . Поэтому библиотеки P & P никогда не загружаются в папку bin моего DAL.

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

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

Проблема: , если разработчик извлекает проект DAL из нашего хранилища кода, он не будет собираться для них, если у них не установлены библиотеки P & P. ​​

Мой вопрос: Должен ли я ожидать, что разработчики установят библиотеки P & P, или я должен просто выбросить их в папку bin и покончить с этим?

Я понимаю, что сброс их в папку bin, вероятно, самый простой способ справиться с проблемой, но я никогда не был большим поклонником папки bin, если бы вместо этого мог ссылаться на них в GAC.

Answer 1

Это в значительной степени стилистическое предпочтение вашей конкретной рабочей группы.Я предпочитаю упаковывать веб-сайты так же, как упаковываю клиентские приложения: со всеми необходимыми бинарными файлами, не относящимися к .NET, в папке bin, исходя из того, что на любой машине, на которую они копируются / устанавливаются, ничего не будетGAC.Моя команда на работе держит наши сторонние сборки проверенными в исходном коде как двоичные файлы и помеченными как ссылочные зависимости, чтобы все работали на одной странице с одними и теми же двоичными файлами, и нам никогда не приходилось беспокоиться о различиях в установке между машинами разработчиков.*

GAC может быть удобным механизмом экономии места, но я предпочитаю согласованность между средами разработчика, обеспечиваемую "встраиванием" файлов.

Answer 2

Работая над проектами с зависимостями GAC в прошлом, всегда было запутанно и сложно правильно настраивать проекты, вызывая всевозможные задержки, только начинающие работу. Это может стать более серьезной проблемой при разработке новых версий DAL. Возможно, это хорошо сработало, когда вы работаете в одиночку, но я бы действительно рассмотрел дамп бен сейчас, когда у вас большая команда.

Answer 3

Я думаю, вы должны дать им возможность сделать оба.

Для ленивых предоставляют pp DLL, а также подписанную DAL DLL. Для более опытных, позволяющих им построить его, просто убедитесь, что они знают, что им нужен P & P, и что любые изменения в DLL должны быть защищены.

Я всегда предпочитаю, чтобы разделяемые библиотеки были защищены, особенно на стороне сервера. Для клиентов я обычно люблю упаковывать в мусорное ведро.