После перехода на Windsor 3 регистрация различных реализаций из xml и кода для одного интерфейса завершается неудачно - PullRequest
Новая
       33

После перехода на Windsor 3 регистрация различных реализаций из xml и кода для одного интерфейса завершается неудачно

0 голосов
/ 02 апреля 2012

Мы находимся в процессе миграции одного стабильного проекта с Castle Windsor 2.5.2 на 3.0.

Мы используем смешанную регистрацию xml / api.После перехода на 3.0 параметры, введенные через ctor и определенные в xml, больше не могут быть разрешены.

Для иллюстрации: 

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
...
  <properties>
    <frontEnd.url>http://site.com</frontEnd.url>
    <admin.email>admin@site.com</admin.email>
  </properties>

  <components>
    ...
    <component id="ServicesBootstrapperAction"
   service="SomeNS.Startup.IBootstrapperAction"
        type="SomeNS.Service.ServicesBootstrapperAction, Project-Service"
        >
      <parameters>
        <frontEndUrl>#{frontEnd.url}</frontEndUrl>
        <adminEmail>#{admin.email}</adminEmail>
        <prohibitedLogins>Assets/prohibited-logins.txt</prohibitedLogins>
      </parameters>
    </component>
    ...
  </components>
</configuration>

И регистрация: 

        _container.Install(
            Castle.Windsor.Installer.Configuration.FromXmlFile("project.common.config"),
            Castle.Windsor.Installer.Configuration.FromXmlFile(String.Format("project.{0}.config", RuntimeEnvironment))
            );

После попытки разрешить этот компонент мы получаем: 

'SomeNS.Service.ServicesBootstrapperAction' is waiting for the following dependencies:
- Parameter 'frontEndUrl' which was not provided. Did you forget to set the dependency?
- Parameter 'adminEmail' which was not provided. Did you forget to set the dependency?
- Parameter 'prohibitedLogins' which was not provided. Did you forget to set the dependency?

Опять же, это то, что отлично работает с 2.5, так что я думаю, что это может быть какое-то недокументированное (или пропущенное / не понятое нами) критическое изменение.

Дифференциальный диагноз, кто-нибудь?

ОБНОВЛЕНИЕ: Я выяснил проблему и нашел обходной путь.Мне это не нравится, но это работает.

Для всех любопытных, вот ссылка на проект, иллюстрирующий проблему: https://docs.google.com/open?id=0B7XFrOzGfmirSldZUmRQeU9SZDZZVnV5UGhGaGhsUQ

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

Ответы [ 2 ]

0 голосов
/ 06 апреля 2012

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

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

Теперь, чтобы избежать двойной регистрации, я использовал .Unless (container.Kernel.HasComponent) до 3.0, который теперь предположительно устарел, но скомпилирован просто отлично!

Удивительно, но .Unless (t => container.Kernel.HasComponent (t.Name)) работал отлично, как и раньше!

Я уверен, что есть объяснение этому, но я не могу придумать ни одного.

Я действительно люблю Касла и наслаждаюсь им. Но 45 килобайт критических изменений не круто, извините, ребята.

0 голосов
/ 02 апреля 2012

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

...