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

Question

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

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

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

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

Edit:

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

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

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

следующие атрибуты внутри файла 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. Это не может быть легко сказать, у вас есть ли символ определен или нет - я не знаю, что такое поведение в ванильным VS, однако с ReSharper установлено, что будет серые части кода, которые не будут скомпилированы под текущим набором символов, и помещает класс как недоступный по мере ввода.
2. Вы должны оставить свои свойства и методы как public, так что, когда вы не создадите его как «ВНУТРЕННИЙ», вы можете получить к ним доступ, но это будет выглядеть немного странно (хотя и не вызывает никаких предупреждений очевидно, является законным).

Answer 2

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

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

Answer 3

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

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

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