Блог

У меня есть решение, которое содержит два проекта. Одним из проектов является ASP.NET Проект веб-приложения, и один из них-библиотека классов. Веб — приложение содержит ссылку на проект библиотеки классов. Ни один из них не имеет строгого названия.

В библиотеке классов, которую я буду называть «Фреймворк», у меня есть поведение конечной точки (реализация IEndpointBehavior) и элемент конфигурации (класс, производный от BehaviorExtensionsElement). Элемент конфигурации предназначен для того, чтобы я мог присоединить поведение конечной точки к службе с помощью конфигурации.

В веб-приложении у меня есть служба WCF с поддержкой AJAX. В web.config у меня настроена служба AJAX для использования моего пользовательского поведения. Раздел system.ServiceModel конфигурации довольно стандартен и выглядит примерно так:

 <system.serviceModel>
 <behaviors>
  <endpointBehaviors>
   <behavior name="MyEndpointBehavior">
    <enableWebScript />
    <customEndpointBehavior />
   </behavior>
  </endpointBehaviors>
 </behaviors>
 <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
 <services>
 <service name="WebSite.AjaxService">
  <endpoint
           address=""
           behaviorConfiguration="MyEndpointBehavior"
           binding="webHttpBinding"
           contract="WebSite.AjaxService" />
  </service>
 </services>
 <extensions>
  <behaviorExtensions>
   <add
       name="customEndpointBehavior"
       type="Framework.MyBehaviorExtensionsElement, Framework, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
  </behaviorExtensions>
 </extensions>
</system.serviceModel>
 

Во время выполнения это работает идеально. Служба WCF с поддержкой AJAX правильно использует мое настраиваемое поведение конечной точки.

Проблема возникает, когда я пытаюсь добавить новую службу WCF AJAX. Если я добавлю -> Новый элемент… и выберу «Служба WCF с поддержкой AJAX», я смогу посмотреть, как он добавляет файл .svc и код, но когда он обновляет файл web.config, я получаю эту ошибку:

Файл конфигурации не является допустимым файлом конфигурации для библиотеки служб WCF.

Структура типа».MyBehaviorExtensionsElement, Фреймворк, Версия=1.0.0.0, Культура=нейтральная, PublicKeyToken=null» зарегистрирован для расширения «customEndpointBehavior» не удалось загрузить.

Очевидно, что конфигурация полностью верна, так как она отлично работает во время выполнения. Если я временно удалю элемент из своей конфигурации поведения, а затем добавлю службу WCF с поддержкой AJAX, все пройдет без сучка и задоринки.

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

Почему не найден мой пользовательский тип элемента расширения поведения WCF?

Обновления/уточнения:

• Он работает во время выполнения, просто не во время разработки.
• Сборка фреймворка находится в папке bin веб-проекта, когда я пытаюсь добавить службу.
• Хотя я мог бы добавлять службы вручную («без настройки»), мне нужен готовый шаблон элемента для работы-в этом вся цель вопроса.
• Эта проблема наблюдается в Visual Studio 2008. В сравнении с 2010 годом это, похоже, решено.

Я зарегистрировал эту проблему в Microsoft Connect, и оказалось, что вам нужно либо поместить свой пользовательский элемент конфигурации в GAC, либо поместить его в папку IDE. Они не будут его чинить, по крайней мере сейчас. Я опубликовал обходной путь, который они предоставили в качестве «ответа» на этот вопрос.

Согласно обходному решению, опубликованному Microsoft в связи с проблемой подключения, которую я подал для этого, это известная проблема, и для нее не будет никакого решения, по крайней мере, в текущем выпуске:

Причина невозможности добавления нового элемента службы: При добавлении нового элемента и обновлении файла конфигурации система попытается загрузить файл конфигурации, поэтому она попытается выполнить поиск и загрузить сборку расширения cusom в этом файле конфигурации. Только в тех случаях, когда сборка находится в GACed или расположена по тому же пути, что и vs exe (Program FilesMicrosoft Visual Studio 9.0Common7IDE), система может ее найти. В противном случае появится диалоговое окно с ошибкой, и «добавить новый элемент» завершится ошибкой.

Я понимаю ваши болевые точки. К сожалению, мы не можем принять это изменение в текущем выпуске. Мы рассмотрим это в более поздних выпусках и попытаемся предложить лучшее решение,например, предоставить диалоговое окно просмотра, чтобы клиенты могли указать путь, или лучшее сообщение об ошибке, чтобы указать какое-то обходное решение и т. Д…

Можете ли вы попробовать обойти эту проблему на текущем этапе: создайте свою сборку пользовательского расширения или скопируйте ее в «Program FilesMicrosoft Visual Studio 9.0Common7IDE»?

Мы предоставим readme, чтобы помочь другим клиентам, которые могут столкнуться с той же проблемой.

К сожалению, похоже, что в этом мне не повезло.

К вашему сведению, для всех, кто столкнется с этим в наши дни, возможным решением является ПОЛНАЯ квалификация вашей сборки в файле app.config/web.config. НАПРИМЕР, если бы у вас был

 <system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="clientCredential" type="Client.ClientCredentialElement, Client" />
        </behaviorExtensions>
    </extensions>
 

попробуйте — замените значения как необходимые

 <system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="clientCredential" type="Client.ClientCredentialElement, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        </behaviorExtensions>
    </extensions>
 

это конкретное решение сработало для меня.

Я просто использовал

 [assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyVersion("1.0.0.0")]
//[assembly: AssemblyFileVersion("1.0.0.0")] 
 

Поэтому у меня каждый раз появляется новый номер сборки сборки.

Но у нас есть

    <add name="clientCredential" type="Client.ClientCredentialElement, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
 

где Версия=1.0.0.0 ЭТО НЕПРАВИЛЬНО!!!

Таким образом, у вас есть 2 варианта

1. Вернуться к

    //[assembly: AssemblyVersion("1.0.*")] 
   [assembly: AssemblyVersion("1.0.0.0")]  Keep it manually.
   [assembly: AssemblyFileVersion("1.0.0.0")] 
    

2. Каждая сборка вручную заменяет версию=1.0.0.0 правильным номером.

Я попробовал это с новым проектом, просто чтобы убедиться, что это не ваш конкретный проект/конфигурация, и у меня была точно такая же проблема.

Используя журналы слияния, похоже, что система ищет расширения поведения ТОЛЬКО в каталоге IDE (C:Program ФайлыMicrosoft Visual Studio 9.0Common7IDE). Копирование сборки в этот каталог на этапе после сборки работает, но это некрасиво.

У вас есть копия фреймворка.dll с вашим пользовательским поведением в каталоге bin вашего веб-проекта? Если нет, то, вероятно, в этом и проблема. Visual Studio ищет реализацию такого поведения. Поскольку он указан в вашей конфигурации, он не думает искать в других проектах; он ожидает найти сборку в корзине.

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

В любом случае, возможно, вам просто захочется еще раз проверить, доступна ли сборка во время разработки.

Вот список шагов, которые сработали для меня:

• Установите dll в GAC, т. е. gacutil /i Bla.dll
• Получите полный каталог dll, т. е. gacutil /l Bla
• Скопируйте полученный FQN в Web.config
• Добавить новую услугу в VS
• Удалите dll файлы из GAC, т. е. gacutil /u Bla

Только все вместе.

Размещение сборки в GAC, вероятно, помогло бы, но я ценю, что это не тот ответ, который вы ищете. Не уверен, где еще VS будет искать сборки, кроме GAC и каталога, содержащего devenv.exe.

Я решил эту проблему, закомментировав соответствующие разделы в web.config, включая элемент, который использовал пользовательское расширение, элемент и элемент.

После этого я смог добавить службу WCF в проект, добавить строки обратно в web.config и опубликовать проект.

если вы используете фреймворк 3.5, Культура=нейтральная в малом, а не Культура=Нейтральная в БОЛЬШОМ

У меня был класс расширения в том же проекте (dll), что и мой класс обслуживания, и я не мог заставить его работать. Как только я переместил его в другой проект и сослался на него из проекта службы, он работал. На всякий случай, если кто-нибудь еще столкнется с этой проблемой.

У меня был класс расширения, определенный в моем классе, который реализует мой интерфейс, что привело к ошибке «не удалось загрузить», когда WCF не смог загрузить мой класс расширения.

Перемещение определения класса расширения из реализации интерфейса (но все еще в том же проекте/dll) решило мою проблему.