Castle Windsor v2.5.2 Release Notes
Release Date: 2010-11-15 // over 13 years ago-
- implemented IOC-243 - Unseal the InterceptorAttribute class
- 🛠 fixed IOC-239 - ArrayResolver attempts to instantiate an unresolvable array dependency
- 🛠 fixed IOC-238 - Resolving Composite depending on a Decorator may fire up cycle detection fuse
- 🛠 fixed IOC-237 - Castle Windsor : Possible bug with Startable Facility and "decorator pattern" dependencies
- 🛠 fixed IOC-236 - Typed Factory Facility causes memory leak because it keeps a reference after releasing object in list 'trackedComponents'
- 🛠 fixed IOC-235 - TypedFactoryFacility with inherited interfaces throws an exception
- 🛠 fixed IOC-234 - StackOverflow causing inability to use debugger view when there are components with dependency cycles in the container
- 🛠 fixed IOC-232 - Exception when using delegate based factories can throw when registered implicitly and used as dependencies of generic component
- 🛠 fixed IOC-231 - Boilerplate methods on facilities should be hidden from IntelliSense when configuring a facility
- 🛠 fixed IOC-230 - Missing Mixins/InterceptorSelectors/ProxyGenerationHooks and TypedFactoryFacility's component selectors are not detected until resolution time
- 🛠 fixed IOC-229 - Qurerying for subsystem is case sensitive
- 0️⃣ implemented IOC-228 - Chicken and egg problem when trying to inherit from DefaultDependencyResolver
- 🛠 fixed IOC-227 - ResolveAll fails for generic forwarded registrations
- 🛠 fixed IOC-224 - Obsolete message on some members of old obsolete API don't compile
- 🛠 fixed IOC-223 - Fluent registration registers components with System.Object service when no BasedOn discriminator is provided
💥 Breaking Changes:
🔄 change - One of CreationContext constructors has now additional argument; parent CreationContext Method public IDisposable ParentResolutionContext(...) on CreationContext was removed Method protected CreationContext CreateCreationContext(...) has now additional argument; parent CreationContext impact - low 🛠 fixability - medium 👀 description - To fix issue with false positive cycle detection (see issue IOC-238) changes had to be made to how parent creation context gets propagated in certain situation (when call to kernel.Resolve/ResolveAll is performed as part of resolution process, for example when CollectionResolver is being used). 🛠 fix - If you override CreateCreationContext method on DefaultKernel pass the additional argument as new constructor parameter to CreationContext. If you were using ParentResolutionContext method it should be fairly safe to remove the call if it was preceded by call to updated CreationContext constructor and the CreationContext is not used outside of local scope. In other cases it's best to consult Castle users group for advice on how to proceed.
🔄 change - IReference<> interface has two new methods impact - low 🛠 fixability - easy description - To make it possible to statically analyze dynamic dependencies provided by the IReference interface two new methods were added: void Attach(DependencyModelCollection dependencies); void Detach(DependencyModelCollection dependencies); 🛠 fix - if you're providing dependencies on a component from the container call Attach so that reference gets a chance to create and add DependencyModel for that dependency so that it can be statically analyzed by the container.
🔄 change - Method IDependencyResolver.Initialize change signature impact - low 🛠 fixability - easy description - To make it possible to use custom DependencyResolver inheriting from DefaultDependencyResolver initialization of DefaultDependencyResolver was moved out of its constructor and to IDependencyResolver.Initialize method which now takes IKernel as its additional parameter 🛠 fix - if you're implementing the interface adjust signature of the overriding method to public void Initialize(IKernel kernel, DependencyDelegate dependencyDelegate) The method is called by the kernel at the end of its constructor.
🔄 change - Changed visibility of members on AbstractFacility to protected and implementation of interface members to explicit. impact - low 🛠 fixability - easy 🔧 description - To make it less confusing to users when fluently configuring facilities (via AddFacility(f => f.ConfigureSomething()) method) visibility of certain members of AbstractFacility class was changed. Public properties FacilityConfig and Kernel are now protected, and all methods from IFacility interface are implemented explicitly. Additionally protected Dispose method was introduced to allow inheriting classes to still be disposed. 🛠 fix - If you were using FacilityConfig and/or Kernel properties outside of inherited classes refactor your code accordingly not to do so. If you were overriding Dispose method change its signature from public override void Dispose() to protected override void Dispose()