какие DLL используются в проекте episerver?

Установка episerver помещает сборки episerver в GAC, я вижу их с помощью C: / windows / assembly.

Кроме того, все dll-файлы episerver присутствуют в C: / Program files / Episerver после установки episerver.

Когда я создаю проект episerver через центр развертывания episerver или с помощью Visual Studio 2010 с использованием шаблона episerver, я вижу, что папка bin только что созданного проекта содержит множество episerver-dll, что не очень удивительно. И я предполагаю, что они скопированы из C: / Program files /. Если я открываю проект в Visual Studio, я вижу, что ссылаются именно на эти библиотеки, а не на библиотеки из GAC или из C: / program files / episerver.

Что ж, все это очень сбивает с толку. Почему Episerver помещает библиотеки DLL в gac и не ссылается на них? Как лучше всего обрабатывать ссылки на библиотеки dll episerver для разработки в команде?

Более того, IF episerver будет ссылаться на ddl из GAC, как бы я увидел это в VS. Я имею в виду, каковы были бы свойства ссылки?


setup-project episerver gac
person staccata    schedule 01.04.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

По сути, это все решения по развертыванию эписервера. Я постараюсь ответить на каждый ваш вопрос один за другим:

  1. Помещение dll в GAC полезно, когда вы хотите, чтобы ваши пользователи получали доступ к dll в диалоговом окне справки на вкладке «.NET Framework». Предположим, вы создаете простой проект (не episerver) и хотите добавить dll-файлы episerver. Вместо того, чтобы искать их на жестком диске, вы ссылаетесь на те, которые указаны GAC. Это легко для разработки.
  2. Почему бы не ссылаться на библиотеки DLL GAC? Это упрощает развертывание вашего решения с помощью библиотек DLL. Предположим, вы развертываете свое решение на сервере. На сервере не будет dll-файлов episerver в GAC (да и не должно быть). Таким образом, они, вероятно, устанавливают свойство «copy local = true», чтобы копировать библиотеки DLL в папку вывода, что делает ваше решение переносимым. Кроме того, сборки GAC не являются «ссылочными» - GAC просто содержит копии в случае необходимости, а ссылка добавляется в папку «программные файлы» с библиотеками DLL.
  3. Лучший способ для команды разработчиков - использовать GAC или определить какую-то «стороннюю» («внешнюю») папку в репозитории и поместить туда свои dll (и ссылку оттуда). Первый подход требует установки episerver на каждой машине разработчика, второй занимает некоторое место в вашем репозитории.
  4. Поскольку на сборки GAC нельзя ссылаться (на самом деле они могут быть, но это головная боль), практически нет разницы между результатом - только разные пути.
person Dmitry Reznik    schedule 01.04.2012
comment
Спасибо за ответ, но пункты 1 и 4 мне кажутся противоречивыми. Кроме того, в VS я не вижу dll-файлов episerver на вкладке .NET, поэтому, вероятно, пункт 4 является правильным утверждением. И пункт 3 кажется тоже противоречит пункту 4, или? - person staccata; 01.04.2012
comment
Что касается пункта 2: кажется, что Episerver требует установки episerver на производственном сервере, потому что в episerver.config есть ссылки, такие как PhysicalPath = C: \ Program Files (x86) \ EPiServer \ CMS. Это потому, что файлы CMS не находятся в корневом веб-каталоге, а находятся в центральном месте. Мне это кажется не очень чистым, но я понимаю, что в этом есть свои преимущества. - person staccata; 01.04.2012
comment
Наверное, я плохо писал :) Стр. 1 и 4 - да, это была моя ошибка - сборки GAC не попадают на вкладку .net. Стр.3 и 4 - никакого отношения не имеют. Когда я сказал использовать GAC на стр. 3, я имел в виду использовать установку episerver (которая помещает библиотеки в GAC). GAC хорош для целей развертывания / использования - вам не нужно включать файлы .dll в выходную папку, .NET найдет ссылки в GAC. - person Dmitry Reznik; 01.04.2012

arrow_upward
2
arrow_downward

Обычно мы создаем отдельный каталог, в котором храним все .dll-файлы, и ссылаемся на них из этого каталога. Это означает все сторонние библиотеки и episerver-dll. Основная причина для этого - избежать неприятностей, когда новому разработчику необходимо настроить проект, а также избежать конфликтов между разными версиями при обращении к GAC.

person erik_nw    schedule 03.04.2012