My team tried some time ago to start using Castle Windsor (3.2.0) for the goodness of IoC. Our test run on development boxes was Persian, but when we tried to run the code on a 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[])
It was a demo table for us and it turned out to be quite complicated for Google. I recently had time to quit this problem and successfully debugged it to the point where the component had an explicit link / dependency (C #, not windsor) on the MVC 3 dll. The server was recently commissioned and only MVC was installed 4. All dev boxes had MVC 3, which made the problem only reproducible in production.
I debugged this by binary commenting on the component registration code, converting the mass registrations to the registration of each component, and then looked at the violating component until I clicked in the right place and had insight.
Now my question is, was there a better way I could debug this? Could I have Windsor give better information? And why was this a problem for Windsor when it was not in the usual case, not in Windsor? My team and I apologize a little for using Windsor now, given the disgusting error-free errors that are reproduced only in production, so I hope I have missed some good ways to solve this problem.