OK so they documentation isn't fantastic but you're not going to get much sympathy here if you've just dropped in the new dlls, F5'd your solution and then compiled a three page whine when it doesn't work. A small amount of research/google would have led you to a good few blogs detailing the breaking changes.
Thank you for you concern on the health of the project. I would suggest you check the jira/donjon, pick up some issues and submit some patches. /rant over/ I've upgraded several projects (some pretty damn large indeed) successfully. It is more than worth the effort of spending just a few hours bringing your project up to date since it will be time well-spent in transitioning to new releases in the future. Thanks, Ben On Tue, Feb 10, 2009 at 7:56 AM, Flominator <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
