Может ли проект веб-сайта ссылаться на подписанную сборку в Visual Studio?

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

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

Отредактируйте, чтобы добавить

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

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

Отредактируйте, чтобы добавить

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

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

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

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

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

Возможные проблемы:

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

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

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

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

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

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