.Net делят DLL между двумя веб-сервисами - PullRequest
Новая
       8

.Net делят DLL между двумя веб-сервисами

2 голосов
/ 18 мая 2011

У меня есть две веб-службы, которые содержатся в общем подкаталоге 

CompanyName\Service1
CompanyName\Service2

В каждом каталоге есть папка bin, содержащая свои библиотеки DLL.Теперь я подошел к моменту, когда часть этого кода была реструктурирована и имеет довольно много общих компонентов, и я хотел бы иметь возможность «поделиться» ими.Каков будет лучший способ пойти по этому поводу?Ниже приведен список решений, которые я нашел (вместе с негативами).

  • AssemblyResolving - Проблемы безопасности.
  • codeBase elementinside of web.config - жестко запрограммированные пути к расположению компонентов.
  • GAC - В настоящее время не из наших продуктов используется GAC, и у меня лично есть очень ограниченные знания по его использованию.Это может быть просто страх перед неизвестным.
  • Размещайте сборки в обоих местах - сложнее обновлять исправления на месте.Нужно убедиться, что файлы заменены во всех местах.

Я скучаю по чему-то еще, что может быть полезным для меня?Кто-нибудь порекомендует использовать какой-либо из перечисленных выше вариантов?

Кроме того, я не могу объединить эти две службы, так как они в настоящее время используются третьими сторонами (они были созданы отдельно).

Ответы [ 5 ]

3 голосов
/ 18 мая 2011

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

, чтобы использовать GAC, все, что вам нужно, это дать строгое имя dll и поместить его в GAC во время установки это также дает вам хорошие возможности управления версиями (один WS использует версию 1.0.0.0, другой может использовать 1.0.0.1)

2 голосов
/ 18 мая 2011

Лучше всего, вы почти наверняка обновите обе услуги одновременно. Посмотрите на процесс развертывания, если вас это беспокоит.

Другой реальный вариант - использование GAC. GAC имеет свои собственные проблемы, такие как необходимость строгого имени / подписи ваших сборок и другие проблемы развертывания.

Что касается системы сборки, если вы всегда создаете и развертываете обе веб-службы одновременно, вам не придется беспокоиться о смешанных совпадениях, поскольку вы указали, что сборки должны оставаться одинаковыми между службами. Если вы не используете систему CI, я бы посоветовал вам начать с нее, TeamCity - отличный вариант для начала, и он бесплатный (ну для ограниченного числа пользователей / проектов - достаточно, чтобы вас началось). Затем просто разверните из CI, либо напрямую, либо из сгенерированных там пакетов. Я признаю, что CI немного решает одну проблему, но может помочь облегчить вашу жизнь, если вы примете ее в долгосрочной перспективе.

1 голос
/ 18 мая 2011

Это то, для чего был создан GAC.

Вы также можете создать приватную ленту NuGet, если хотите согласовать общий код.

http://haacked.com/archive/2010/10/21/hosting-your-own-local-and-remote-nupack-feeds.aspx

http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspx

1 голос
/ 18 мая 2011

Обе локации.Таким образом, вы можете опубликовать изменение общего кода в одной версии (изменение / прерывание изменения интерфейса), заменив файлы в этой папке bin, не подвергая опасности / не нарушая другую веб-службу.

Обновление: это имеетте же преимущества «параллельного управления версиями», что и при использовании GAC, без какой-либо согласованной сложности публикации, строгих требований к именованию и т. д.

0 голосов
/ 18 мая 2011

Другой вариант - разместить файлы в одном месте и связать их с помощью символической ссылки. Этот поток объясняет команду.

У меня нет опыта пробовать это, поэтому не рекомендую.

...