Hi Nicholas, I've upgraded my current case study to trunk some weeks ago. Worked quite well when following http://codeprairie.net/blogs/chrisortman/archive/2008/01/09/catching-up-with-castle-trunk-4710.aspx
Best regards, Flo On 10 Feb., 00:21, Nicholas Piasecki <[email protected]> wrote: > Hello, and apologies for the forth-coming semi-rant, > > I'm currently evaluating the feasibility of upgrading a 2-year-old > MonoRail Web site running RC2 to the latest or near-latest trunk. Now, > I don't expect upgrading from a 2-year-old binary to a new one to > "just work," but when moving from a "release candidate," I really > don't expect to see that many changes, at least not without a clearly > defined migration. The number of breaking changes, however, is > astounding. Here's a sample overview: > > * MonoRailHttpHandler.CurrentContext seems to be gone. This is huge > and causes a lot of problems for this site. Is the preferred method to > simply favor the ASP.NET-provided HttpContext.Current property to > access these variables? > > * IRailsEngineContext has changed to IEngineContext. Irritating, but a > find and replace is simple enough. Similarly, ExecuteEnum has changed > to ExecuteWhen. A silly breaking change, but okay. > > * The IFilter interface has changed to include an IControllerContext, > which seems to be new. > > * IsPreConditionSatisified() on WizardStepBase is now public instead > of protected, breaking any code that overrode that method. Simple > enough to fix. > > * WizardStepBase has lost the Redirect() overload that took a single > URI, which was useful for redirecting to external sites like PayPal or > Google Checkout. I suppose the new replacement is RedirectToUrl(). > > * The Initialize() method of WizardStepPage is gone. What is the > replacement? The constructor? > > * The interface for IWizardController has changed in that the GetSteps > () method returns an interface instead of an concrete class. Fair > enough. > > * The Initialize() method on Controller is now public instead of > protected. Okay. > > * The SelectMethod() method on SmartDispatcherController has gained an > additional parameter, actionType. Straight forward. > > * The IParameterBinder interface has changed with new parameters in > the methods. Simple enough. > > * The UrlReferrer property on IRailsEngineContext has disappeared. > UnderlyingContext.Request.UrlReferrer is the presumed replacement. > > * Controller's ObtainDefaultLayoutName() now returns a string[] > instead of a string. This seems odd to me. > > * SmartDispatcherController's CreateAbsoluteRailsUrl() is no longer > available. We can work around. > > * ControllerFactory's CreateController() method no longer has an > overload that accepts an UrlInfo object. > > * PaginationHelper's CreatePagination() overloads seem to now require > an IEngineContext and is now generic. A simple enough change. > > * In ViewComponent, the RailsContext property has been renamed to > EngineContext. Does a prettier name really justify a breaking change? > > * The addition of the Validator namespace causes a nasty namespace > collision. But is cosmetic. > > * The Logger and Context properties on the Controller class are no > longer public, which makes a few logging handlers break. > > * The PropertyBag property is no longer public on controllers. How can > my BeforeAction filters now inject data into the controller? Define my > own interface for this? (Think of an [AddCartToPropertyBag] or an > [AddMenuToPropertyBag] attribute that decorates a class.) > > * The protected virtual InternalSend() method on > SmartDispatcherController no longer exists. We had been using a lock > here to work around NVELOCITY-12, a severe threading problem in RC2, > and a few other sundry logging statements happen here. I assume the > new method to override is InvokeMethod()? > > ... I gave up at this point, seeing as it will take a lot of revisions > to get the code to even compile. > > So the question, and point of this post, is: Has anyone ever > realistically upgraded from RC2? We certainly are pioneering a new > usage of the phrase "release candidate." There seems to be no > migration path here. > > At this point, I reckon that it will be easier to just keep this site > on RC2 until its end of life, unless anyone has some insightful > recommendations. I suppose I could always do "baby upgrades" to > previous trunk points in history where there are fewer breaking > changes to deal with all at once, but it doesn't seem worth the > effort. It seems it'd be nearly as difficult to jump ship to a > completely different framework. > > RC2, at least, has been a great product and I'm very thankful to the > community for it, but I must admit that all of these changes has me > concerned about the direction and health of the project. Any insight > that can be provided would be appreciated, and thanks for listening to > my rant! =) > > V/R, > Nicholas Piasecki --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
