Возможно ли, чтобы проект веб-сайта ссылался на подписанную сборку в visual studio?

Question

Мне известны следующие два различных типа веб-проектов в Visual Studio 2008:

• Сайт проекта
• Проект веб-приложения

Проект веб-приложения может ссылаться на подписанную сборку, если сборка веб-приложения также подписана тем же ключом. Однако это не работает с проектом веб-сайта, потому что нет места для подписи сборки. Я думаю, это потому, что сборка динамически компилируется на сервере?

В любом случае, возможно ли заставить проект веб-сайта работать с этой подписанной сборкой? Или мне придется преобразовать этот проект веб-сайта в проект веб-приложения?

Изменить:

Следующая ситуация потребовала, чтобы я попросил разъяснений по этому вопросу:

У меня есть библиотека классов, на которую ссылаются несколько других проектов в моем решении в Visual Studio. Одним из проектов является Windows-приложение, которое будет развернуто для конкретных внешних пользователей. Чтобы убедиться, что приложение использует правильную сборку, а также чтобы другие не могли использовать сборку (я знаю об ограничениях в отношении ее эффективности), все сборки были подписаны и все классы в библиотеке объявлены как друг (внутренний).

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

Следующие атрибуты находятся внутри файла AssemblyInfo.vb в моем проекте библиотеки классов:

<Assembly: InternalsVisibleTo("OtherProject1, PublicKey=AAA...")>
<Assembly: InternalsVisibleTo("OtherProject2, PublicKey=AAA...")>
...

Мой вывод:

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

Answer 1

Теперь, когда у меня есть более четкое представление о проблеме, я вижу, что мой первоначальный ответ не подходит.То, что я делал раньше в аналогичной ситуации, заключалось в том, чтобы использовать управление исходным кодом для ветвления файлов кода для классов «Друг» в потребляющий проект, чтобы они компилировались как часть потребляющей сборки.

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

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

Answer 2

Нет необходимости подписывать два проекта одним и тем же ключом - после того как все сборки фреймворка будут подписаны ключом MS, к которому у вас нет доступа, вы можете с радостью ссылаться на них как с веб-сайта, так и с веб-сайта.Проекты приложений.

Ничто не мешает вам ссылаться на подписанную сборку из проекта веб-сайта - какие ошибки вы видите?

---

Изменить, чтобы добавить

В свете вашей обновленной информации, да, я думаю, вам придется либо:

1. Преобразовать веб-сайт в веб-приложение - как вы правильно заметили, нет способаподписать сайт, и действительно, нет никакого реального контроля над библиотеками, которые ASP.NET сгенерирует для сайта.
2. Скомпилируйте две версии библиотеки классов, одну подписанную, а другую нет.Вы могли бы, вероятно, использовать условную компиляцию для достижения этой цели.

---

Редактировать, чтобы добавить

Я думаю, что условная компиляция, вероятно, быстро закончится,но вкратце это будет работать так:

• Откройте «Свойства проекта» для библиотеки классов и перейдите на вкладку «Сборка».
• Переключите раскрывающийся список «Конфигурация» на «Все конфигурации»."
• В поле« Условные символы компиляции »добавьте новый символ, например« ВНУТРЕННИЙ ».

Перейдите в библиотеки классов, которые вы хотите сделать общедоступными, и изменитеих что-то вроде:

#if INTERNAL
  internal class MyClass
#else
  public class MyClass
#endif
  {
    [...]
  }

Затем, когда вам нужно создать публичную версию библиотеки, удалите символ «ВНУТРЕННИЙ» из свойств и пересоберите - вы могли бы упростить это, создав новый наборконфигураций отладки и выпуска, для которых определен этот символ, и переключайтесь между ними с помощью раскрывающегося списка «Конфигурация решения».

Потенциальные проблемы:

1. Itможет быть нелегко определить, определен ли у вас символ или нет - я не знаю, каково поведение в vanilla VS, однако при установленном ReSharper он затеняет части кода, которые не будут компилироваться втекущий набор символов и помечает класс как недоступный при вводе.
2. Вы захотите оставить свои свойства и методы как public, чтобы, когда вы не построили его как «ВНУТРЕННИЙ», выможет получить к ним доступ, но это будет выглядеть немного странно (хотя никаких предупреждений так явно не допустимо).

Answer 3

Открытые члены подписанной сборки должны быть доступны любому другому проекту, имеющему доступ к DLL. Я создал несколько подписанных сборок и распространил их среди других членов моей команды, мы использовали их в различных веб-сайтах, веб-проектах и ​​консольных приложениях. Единственное место, где мы столкнулись с конфликтом, - это попытка использовать сборку, которая ссылается на HttpContext.Current в консольном приложении. Даже это работало, если мы избегали методов, которые использовали эту ссылку.

Единственный случай, когда подпись / ключи должны быть проблемой, - это если вы пытаетесь сделать их «Друзьями», то есть они могут видеть друг друга внутренние типы и методы. Правила о друзьях и подписи описаны здесь: http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx