We always either resolve instances by type, or resolve collections by common interface.
One of the problems is that we have a single type implementing a couple of interfaces - in this situation it sets them both to the same key (as it's based on the concrete type). E.g. we register concrete types in the container, and some of the interfaces they implement too (this allows classes in the same assembly to access the concrete type's internal functions, but those in other assemblies access the public interface). In these situations our auto-registration code gets its knickers in a name conflict twist. A naming strategy of (serviceType.FullName + "#" + compoentType.FullName) would stop us having to write any .Name() properties. On Jan 25, 9:19 pm, Krzysztof Koźmic <[email protected]> wrote: > No, there's no global point you can override the naming strategy. And > for a reason - it should not matter. > > The generated ids are for Windsor's internal usage and if you have a > clash that usually means you have a problem - there's no way to > differentiate between your components. > That's why you have to be explicit and if you don't care about the names > (which the only case I can think of would be when you resolve all > components only ever as a collection) > explicitly override them. > > Can you explan what is your scenario here? > > Krzysztof > > On 26/01/2011 3:49 AM,mcintyre321wrote: > > > > > > > > > We do all our registration using the fluent API and conventions, and > > occasionally the generated service names conflict and we have to > > manually override them. Is there some way to change the strategy used > > for when no name is specified (e.g. serviceType.FullName + "#" + > > compoentType.FullName or Guid.NewGuid().ToString()) to avoid these > > conflicts? -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
