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

Question

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

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

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

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

Редактировать:

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

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

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

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

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

Мой вывод:

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

Answer 1

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

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

---

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

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

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

---

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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