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
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.
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 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)
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
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
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?