My team tried some time ago to start using to Castle Windsor (3.2.0) for IoC goodness. Our trial runs on development boxes went peachy, but when we tried to run the code on the production server, it failed with the following exception
Application: XXXX
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
Stack:
at System.Signature.GetSignature(Void*, Int32, System.RuntimeFieldHandleInternal, System.IRuntimeMethodInfo, System.RuntimeType)
at System.Reflection.RuntimeMethodInfo.get_Signature()
at System.Reflection.RuntimeMethodInfo.GetParametersNoCopy()
at System.Reflection.RuntimePropertyInfo.GetIndexParametersNoCopy()
at System.Reflection.RuntimePropertyInfo.GetIndexParameters()
at Castle.MicroKernel.ModelBuilder.Inspectors.PropertiesDependenciesModelInspector.IsValidPropertyDependency(System.Reflection.PropertyInfo)
at System.Linq.Enumerable+WhereArrayIterator`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext()
at System.Collections.Generic.List`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]..ctor(System.Collections.Generic.IEnumerable`1<System.__Canon>)
at System.Linq.Enumerable.ToList[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.Collections.Generic.IEnumerable`1<System.__Canon>)
at Castle.MicroKernel.ModelBuilder.Inspectors.PropertiesDependenciesModelInspector.InspectProperties(Castle.Core.ComponentModel)
at System.Collections.Generic.List`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].ForEach(System.Action`1<System.__Canon>)
at Castle.MicroKernel.ModelBuilder.DefaultComponentModelBuilder.BuildModel(Castle.MicroKernel.ModelBuilder.IComponentModelDescriptor[])
at Castle.MicroKernel.Registration.ComponentRegistration`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Castle.MicroKernel.Registration.IRegistration.Register(Castle.MicroKernel.IKernelInternal)
at Castle.MicroKernel.DefaultKernel.Register(Castle.MicroKernel.Registration.IRegistration[])
at Castle.Windsor.WindsorContainer.Register(Castle.MicroKernel.Registration.IRegistration[])
at Sproom.Web.Infrastructure.WindsorInstaller.Install(Castle.Windsor.IWindsorContainer, Castle.MicroKernel.SubSystems.Configuration.IConfigurationStore)
at Castle.Windsor.Installer.AssemblyInstaller.Install(Castle.Windsor.IWindsorContainer, Castle.MicroKernel.SubSystems.Configuration.IConfigurationStore)
at Castle.Windsor.Installer.CompositeInstaller.Install(Castle.Windsor.IWindsorContainer, Castle.MicroKernel.SubSystems.Configuration.IConfigurationStore)
at Castle.Windsor.WindsorContainer.Install(Castle.MicroKernel.Registration.IWindsorInstaller[], Castle.Windsor.Installer.DefaultComponentInstaller)
at Castle.Windsor.WindsorContainer.Install(Castle.MicroKernel.Registration.IWindsorInstaller[])
This was a showstopper for us and proved quite difficult to google. I recently had some time to throw at the issue, and successfully debugged it down to the fact that a component had an explicit reference/dependency (C#, not windsor) on a MVC 3 dll. The server was a newly commissioned one, and had only MVC 4 installed. All dev boxes had MVC 3 installed, making the problem only reproducible on production.
I debugged this by binary commenting out component registration code, converting mass registrations to per-component registration, and then staring at the offending component until I clicked the right place and had an epiphany.
My question is now, was there a better way that I could have debugged this? Could I have had Windsor give better information? And why was this a problem for Windsor when it was not in the normal non-Windsor case? I and the team are a bit leery of using Windsor now, given the nastyness of non-googlable errors only reproducible on production, so I hope I missed some nice ways of addressing this problem.