Hello Stu, The reason you got that popup was that the enumerable extension file is what iterates over the configuration, and the call-site was in a captured lambda of that loop.
So, greek aside, I think your problem is related to having incompatible versions of Windsor in your application. You can see that the tests run fine, so there's no rebind-problem in the facility. I think you'll have to go through your assemblies and check that you aren't referencing the wrong version of Windsor anywhere in there... Krzysztof - I'm on the right track here, right? Henrik ----- Ursprungligt meddelande ----- Från: [email protected] Till: Kopia: Skickat:Sat, 1 Sep 2012 08:12:13 -0700 (PDT) Ämne:Re: Announcing Castle.{Transactions, Facilities.AutoTx} v3.1 Hi Henrik, I've downloaded the latest version but I'm still having a problem that I think MIGHT be related. When I first built and ran my code after updating, an open file dialog appeared asking for the location of an EnumerableExtension.cs file. I didn't think much of this at the time as I didn't think it was related to the update so I cancelled the dialog. This was a few days ago so I'm not sure what exactly happened next as I was in a rush but I THINK that my app loaded successfully. However I've come back to it today and I'm getting the following exception when loading my app: Method not found: 'Castle.MicroKernel.Registration.ComponentRegistration`1 Castle.MicroKernel.Registration.Lifestyle.LifestyleGroup`1.get_PerWebRequest()'. The stacktrace for the exception is: at Castle.Facilities.NHibernate.NHibernateFacility.GetLifeStyle[T](ComponentRegistration`1 registration, UInt32 index, String baseName) at Castle.Facilities.NHibernate.NHibernateFacility.RegisterSession(Data x, UInt32 index) at Castle.Facilities.NHibernate.NHibernateFacility.b__7(Data x) at Castle.Transactions.Helpers.EnumerableExtensions.d__0`1.MoveNext() in d:BuildAgent-03work9844bdf039249947srcCastle.TransactionsHelpersEnumerableExtensions.cs:line 48 at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source) at Castle.Facilities.NHibernate.NHibernateFacility.Init() at Castle.MicroKernel.Facilities.AbstractFacility.Castle.MicroKernel.IFacility.Init(IKernel kernel, IConfiguration facilityConfig) at Castle.MicroKernel.DefaultKernel.AddFacility(IFacility facility) at Castle.MicroKernel.DefaultKernel.AddFacility[T]() at Castle.Windsor.WindsorContainer.AddFacility[T]() at ProjectName.Core.ViewModelResolver.configureContainer() in E:GithubProjectNameProjectNameProjectNameCoreWindsorResolver.cs:line 41 at ProjectName.Core.ViewModelResolver.Resolve(String viewModelName) in E:GithubProjectNameProjectNameProjectNameCoreWindsorResolver.cs:line 18 at ProjectName.Core.ViewModelLocator.get_Item(String viewModelName) in E:GithubProjectNameProjectNameProjectNameCoreViewModelLocator.cs:line 18 The code that is causing this exception is: _container = new WindsorContainer(); _container.AddFacility(); _container.Register( Component.For() .ImplementedBy()); _container.AddFacility(); It could well be that I am doing something wrong as I am new to Castle Windsor but it seemed worthy of posting here given that I've just updated my packages. Can you shed any light on the problem? ThanksStu On Thursday, August 23, 2012 1:18:38 AM UTC+1, Henrik wrote:v3.2 targeting the new Windsor released. They should indeed contain dlls this time. ^^ On Thursday, August 23, 2012 12:46:03 AM UTC+2, Henrik wrote:Hello, Just wanted to check in pretty late and say that I'm working on this now. There's been a gap in my ability to work on this, as you may have noticed. Regards, Henrik On Saturday, August 11, 2012 4:00:33 PM UTC+2, Stu wrote:I posted about this on Stack Overflow (see here: http://stackoverflow.com/questions/11913331/installing-castle-transactions-from-nuget-doesnt-produce-a-dll [1] ) as this is still a problem. Unfortunately I haven't been able to resolve the problem and I think the main reason for that is that Castle has also had an update in the past few days. Trying to manually resolve this by installing older versions of various packages is a dependency nightmare that I haven't beaten. Does anyone have any idea how to fix this? Is it only Henrik that can accept the pull request and deploy to NuGet? I dropped him an email the other day to tell him that this was an issue but I haven't had a response yet. ThanksStu On Wednesday, June 27, 2012 7:47:46 PM UTC+1, Henrik wrote: Castle.Transactions v3.1 and Castle.Facilities.AutoTx v3.1 are now ready for downloading from nuget and source from github, like usual! This is the first GA release of version 3.0. It’s compliant with Windsor 3.0. Cheers, Henrik -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-users/-/11BzIFOEaaoJ [2]. 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. Links: ------ [1] http://stackoverflow.com/questions/11913331/installing-castle-transactions-from-nuget-doesnt-produce-a-dll [2] https://groups.google.com/d/msg/castle-project-users/-/11BzIFOEaaoJ -- 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.
