Почему для полных имен сборки иногда требуются пробелы?
Просто споткнулся об этом сегодня, и я не могу найти никакой информации об этом. Так вот почему я спрашиваю здесь. Возможно, кто-то знает, почему.
Я добавил пользовательское расширение поведения WCF в свой web.config. Это выглядит так:
<behaviorExtensions>
<add name="errorBehavior" type="MyNs.TracingErrorBehaviorElement,MyNs,
Version=1.0.6.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>
(Нет места там: MyNs.TracingErrorBehaviorElement,MyNs
)
Он отлично работает на моей машине разработки, на нашем промежуточном сервере, на нашем реальном сервере и т.д.
Сегодня мы установили продукт на сервер клиента и получили следующее исключение:
System.Configuration.ConfigurationErrorsException: произошла ошибка создание обработчика раздела конфигурации для system.serviceModel/behaviors: Элемент расширения 'errorBehavior' не могут быть добавлены к этому элементу. Убедитесь, что расширение зарегистрировано в system.serviceModel/расширения/behaviorExtensions...
Проведя полчаса поиска в Интернете по возможным причинам, я добавил пробелы в полное имя сборки. Поэтому я изменил его на:
<behaviorExtensions>
<add name="errorBehavior" type="MyNs.TracingErrorBehaviorElement, MyNs,
Version=1.0.6.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>
(см. пробел: MyNs.TracingErrorBehaviorElement, MyNs
)
и он работал.
Кто-нибудь знает, почему он работает без места на некоторых машинах, а не на других?
Я проверил .Net-versions
. Они подошли. Это может быть вызвано региональными настройками?
Редактор говорит:
Я проверил используемые версии .Net на всех машинах, и они все одинаковы:.Net 4.0
Но я нашел разницу между машиной, где я получаю ошибку с отсутствующей пустой и другими машинами, где она работает:
Все машины, на которых он работает без пробела, установили .Net Framework 4.5. Таким образом, это может быть одна из тех ошибок, которые были исправлены в 4.0 и развернуты с 4.5, правильно?
Ответы
Ответ 1
Это известная ошибка, зарегистрированная в этом сообщении в блоге Shawn Cicoria.
Он не говорит ничего о том, когда именно ошибка была исправлена, классы конфигурации WCF слишком запутаны, чтобы сузить ее. Я предполагаю, что, учитывая возраст сообщения, это исправление .NET 4.5. С сбоем на клиентском сайте из-за его установки 4.0. Вы узнали бы лучше, чем вы выбрали для своего проекта.
В противном случае хорошая демонстрация того, насколько сложно Microsoft когда-либо исправлять ошибки.
Ответ 2
Ну, MSDN говорит:
Пространства являются релевантными для всех компонентов имени типа, кроме имени сборки. В имени сборки пробелы перед разделителем ',' имеют значение, но пробелы после разделителя ',' игнорируются.
Действительно, тестирование показывает, что это действительно так: GetType
и другие методы разрешения типа действительно игнорируют пробелы после разделителя ,
.
Однако WCF каким-то образом усложняет это, потому что по какой-то причине для него требуется полное имя типа, которое точно соответствует значению, которое вы получаете от Type.AssemblyQualifiedName
. Возможно, он хранит кеш файлы где-то, я не знаю.
Что касается того, почему это происходит только на некоторых машинах, я бы поставил свою ставку на GAC или какую-то другую систему, которая слегка изменяет разрешение сборки/типа. Поскольку вы не используете snk, GAC не может быть и речи, но, возможно, есть какая-то конфигурация, которая изменит это для вас, возможно, в файле machine.config или в веб-приложении в конфигурации IIS.
Кажется, что это ошибка конфигурации в .NET 3.5. У .NET 4.0+ нет такой же проблемы. Вы уверены, что приложение работает с той же версией .NET? Это может быть очень важно, если вы работаете с веб-приложением (клиентский сервер может быть настроен на использование .NET 3.5, на самом деле вам нужно указать system.web.compilation[targetFramework]
и httpRuntime
, чтобы настроить правильную Я добавлю ссылку на ошибку, но пока она упоминается во многих местах, статья, похоже, была удалена из MS Connect с: