Sorry for the delay, mail notification apparently got lost and I just
revisited that issue...
Well, not really, unfortunately this doesn't work for me. It should, as you
said; but instead I get this exception thrown (with no mention of my
installer class):
Castle.MicroKernel.ComponentRegistrationException was unhandled
HelpLink=groups.google.com/group/castle-project-users
HResult=-2146233088
Message=Component somethingelse could not be registered. There is already
a component with that name. Did you want to modify the existing component
instead? If not, make sure you specify a unique name.
Source=Castle.Windsor
StackTrace:
at
Castle.MicroKernel.SubSystems.Naming.DefaultNamingSubSystem.Register(IHandler
handler)
at
Castle.MicroKernel.DefaultKernel.AddCustomComponent(ComponentModel model)
at
Castle.MicroKernel.Registration.ComponentRegistration`1.Castle.MicroKernel.Registration.IRegistration.Register(IKernelInternal
kernel)
at Castle.MicroKernel.DefaultKernel.Register(IRegistration[]
registrations)
at Castle.Windsor.WindsorContainer.Register(IRegistration[]
registrations)
at
Castle.Windsor.Installer.DefaultComponentInstaller.SetUpComponents(IConfiguration[]
configurations, IWindsorContainer container, IConversionManager converter)
at
Castle.Windsor.Installer.DefaultComponentInstaller.SetUp(IWindsorContainer
container, IConfigurationStore store)
at Castle.Windsor.WindsorContainer.Install(IWindsorInstaller[]
installers, DefaultComponentInstaller scope)
at Castle.Windsor.WindsorContainer.Install(IWindsorInstaller[]
installers)
at ApplicationNamespace.ServiceRunner..ctor() in
e:\_dev\TestApplication\Infrastructure\ServiceRunner.cs:line 24
at ApplicationNamespace.ServiceRunner.Start() in
e:\_dev\TestApplication\Infrastructure\ServiceRunner.cs:line 40
at ApplicationNamespace.Program.Main(String[] args) in
e:\_dev\TestApplication\Program.cs:line 10
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly,
String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:
Actually, my initial reason for creating this thread was because of a
Service that isn't registered manually but by convention (using
Classes.FromAssemblyInThisApplication.BaseOn<ISomeInterface>().WithServiceSelf())
that didn't have an explicit name assigned. But even with named services
registered like in your example, that exception is thrown either way.
I just tried something else; and that is calling container.Install twice.
First with the App.config, then with the Installers using
FromAssembly.This(). The result is the same, altho the Stacktrace for the
exception looks different. This time, it stops inside my Installer class
where the line
container.Register(Component.For<IService>().ImplementedBy<SomeClass>().
Named("somethingelse"));
is.
The scenario is as follows (hopefully clearer than in the initial post):
1. My container.Install call looks like this:
container.Install(Configuration.FromAppConfig(),
FromAssembly.This()); (assuming that App.config comes first, with the idea
that I can override Installers when necessary).
2. One of the installer classes registers a service like that:
container.Register(Component.For<IService>().ImplementedBy<SomeClass>().Named("myservice"));
3. The default App.config has *no* <component> entry for "myservice" at
all. In fact, it is an empty <castle> block with nothing inside.
4. The application is shipped to a customer, and they notice a problem with
SomeClass.
5. I create a new Class Library project, implement a new version of IService
that works, and send it to the customer. In their environment, they put the
DLL in the install folder of the application and modify App.config to add
the additional line <component id="myservice"
service="ApplicationNamespace.IService" type="Bugfix.SomeOtherClass,
BugfixDLL"/>
My intention was that, by doing above steps, I get this result:
- with the <component> line in App.config: Bugfix.SomeOtherClass is used
whenever "myservice" is requested. The original SomeClass is never used.
- without the <component> line in App.config: The original SomeClass is
used all the time when "myservice" is requested.
Somehow, I think this might be a bug, since you suggested earlier that this
should actually work?
- BhaaL
On Tuesday, April 21, 2015 at 1:10:11 AM UTC+2, hammett wrote:
>
> If you try
>
> Component.For<YourComponent>().Named("somethingelse")
>
> It should work.
>
> That said, your composition will still use the first one registered,
> unless you rewire things somehow. That's why the xml config "works",
> because it's registering stuff before everything else. If you change
> the key there (the "id"), then you'll get the expected behavior -- if
> I understood your problem correctly.
>
>
--
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.
