К GAC, или не к GAC?
У меня есть уровень доступа к данным (DAL), который записан в ASP.NET 3.5 и использует шаблоны Microsoft и библиотеки методов (в дальнейшем именуемый P&P) для выполнения его доступа к данным. Я установил P&P, и он находится в моем GAC, таким образом, логически, мой DAL ссылается на него в GAC. Поэтому библиотеки P&P никогда не раскрываются к папке мусорного ведра моего DAL.
Я использую этот проект DAL по крайней мере в пяти (больше, чем тот даже, но я слишком ленив, чтобы попытаться считать их всех), различные веб-сайты. И это все работало просто великолепно для меня, потому что я - единственный разработчик, который работает над этими веб-сайтами.
Но, теперь у меня есть другие разработчики, которые собираются работать над некоторыми из этих веб-сайтов.
Проблема: если разработчик раскроет проект DAL от нашего репозитория кода, то он не создаст для них, если им не установят библиотеки P&P.
Мой вопрос: я должен ожидать, что разработчики установят библиотеки P&P, или я должен просто вывести их в папке мусорного ведра и быть сделан с нею?
Я понимаю, что дамп их в папку мусорного ведра является, вероятно, самым легким способом иметь дело с проблемой, но я никогда не был большим поклонником папки мусорного ведра, если я могу сослаться на них в GAC вместо этого.
3 ответа
Это во многом стилистическое предпочтение вашей конкретной рабочей группы. Я предпочитаю упаковывать веб-сайты так же, как я упаковываю клиентские приложения: со всеми необходимыми двоичными файлами, отличными от .NET-framework, в папке bin, работая с предположением, что на любой машине, на которую они копируются / устанавливаются, не будет ничего в GAC. Моя команда на работе хранит наши сторонние сборки в системе управления версиями в виде двоичных файлов и помечает их как ссылочные зависимости, чтобы все работали на одной странице с одними и теми же двоичными файлами, и нам никогда не приходилось беспокоиться о различиях в установке между машинами разработчиков.
GAC может быть удобным механизмом экономии места, но я предпочитаю согласованность между средами разработчика, обеспечиваемую «встраиванием» файлов.
Я думаю, вам следует дать им возможность сделать и то, и другое.
Для ленивых предоставьте библиотеки DLL pp, а также подписанную DLL DAL. Чтобы более опытные пользователи могли его создать, просто убедитесь, что они знают, что им нужен P&P, и что любые изменения в DLL необходимо будет вносить.
Я всегда предпочитаю, чтобы разделяемые библиотеки были изолированы, особенно на стороне сервера. Для клиентов я обычно предпочитаю упаковывать в корзину.
В прошлом я работал над проектами с зависимостями GAC, и это всегда запутывало и затрудняло правильную настройку проектов, вызывая всевозможные задержки при начале работы. Это может стать еще большей проблемой, когда вы разрабатываете новые версии DAL. Возможно, это хорошо работало, когда вы были одиночкой, но я бы действительно подумал о мусорной корзине теперь, когда у вас большая команда.