SF4 migration woes

Hi guys.

We're trying to migrate from 3.7 to 4, using the migration tool on Codeplex.  We eventually got the migration assembly to compile and then ran the tool.  It seems to have time-out issues when dealing with a large amount of data (eg users), but repeatidly running the tool seemed to get the job done.

HOWEVER, we are now finding that there have been many UNDOCUMENTED changes to the Telerik API, making the migration of user controls hard.

One such example of this is the implementation of a custom http handler.  In 3.7 we simply inheritted from ContentHttpHandler, but this class no longer exists (or has moved to a different namespace).  How do we resolve this?

Why haven't these subtle class/namespace changes been documented?  Why doesn't the migration tool take care of this?

Regards,

Nick

Also ran into problems with:

Telerik.Cms.Engine (doesn't exist anymore?);
LibraryManager;
Telerik.Cms.Web.InternalPage;
Telerik.Framework.Web.Design.ControlDesigner (Design namespace no longer in Telerik.Framework.Web...?);
Telerik.Cms.Web.InternalPage (InternalPage class has been moved...?).

This is just to name a few...

Hi Nick Haworth,

Sitefinity 4.0 API is completely different compared to 3.7. It has been rewritten from scratch so the namespaces and the class names are completely different.

We are sorry for the inconvenience but unfortunately this means you should rewrite your custom controls code using the new API.

Hi Lupi,

Thanks for replying.  I understand that, but is there somewhere that documents the API changes? 

For example, how would I know where to find Telerik.Cms.Web.InternalPage (or equivalent) in the SF 4 API?

Thanks.

Nick

Hello Nick,

There is no more InternalPage class and the architecture is completely different. This is why we migrate the data. Sitefinity 4.0 uses ASP.NET Routing Engine. We have routing handlers that inherit from IRouteHandler . The route handler for pages is PageRouteHandler.

Regards,
Ivan Dimitrov
the Telerik team

So where would we now do things that we used to do with InternalPage? I think what everyone's trying to get at is Yes the API has changed, but we're kind of left in the dark here about how to 'properly' migrate existing customers.

Hi J.Hoventer,

We have implemented functionality similar to the InternalPage class in 3.x. This was implemented because of interest towards such feature. Now what you can do is to create a custom page class which inherits from the standard ASP.NET Page class. Then all you have to do is build it and tell your pages to use it from their properties (Code behind type) as in attached image.

Kind regards,
Radoslav Georgiev
the Telerik team