Migrate your pages to .NET Core

You can gradually migrate your MVC pages to ASP.NET Core using the hybrid development approach - running both MVC and ASP.NET Core pages in the same project. This is possible, because the ASP.NET Core Renderer does not limit you to create and edit only ASP.NET Core pages. Using the Renderer, you can work with ASP.NET Core or MVC. This means that, in each site, you can have a mixed collection of all both supported rendering mechanisms.

However, rendering ASP.NET Core widgets in MVC based pages or vice versa is not possible.

This hybrid development approach helps you to migrate to ASP.NET Core in the following scenarios:

• If you want to have all of your pages based on ASP.NET Core, you do not have to migrate your site all together. Instead, you can do it one page at a time.
• If you want to leave all of your existing pages, based on their current framework and you want only your new pages to be based on ASP.NET Core, you can create your new pages in ASP.NET Core independently of your existing pages in MVC.

Migration of widgets from MVC to ASP.NET Core  is not a straight-forward operation. The two frameworks are different, and manual work is required to achieve the migration. 

Use the following guidelines to migrate the widget components:

In general, the View and ViewModel classes must not contain any logic. Therefore, you can easily copy and migrate them from the MVC to the ASP.NET Core widgets.

There are some differences in the APIs for referencing scripts.  

For more information, see Client-side development for the ASP.NET Core framework.  

To configure the HTML sanitization API, use the HTML sanitizer sample on Sitefinity’s GitHub repository, located at HTML sanitizer.
For more information about using the sanitizer, see LongText.cshtml on Sitefinity’s GitHub repository. 

The controller class logic is designed to connect the logic of the Model and the View. This is also true for the ASP.NET Core ViewComponents as well. All OOB widgets listed in the following GitHub repository have no (or in rare cases, little) logic inside of them. Everything is placed in the Model classes. Alternatively, you can omit the Model class and place everything in the ViewComponent class. 

The Model class is the most complex for migration because it heavily employs content APIs. In this case, there is no straightforward approach, so migration must be done case-by-case.

For more information about fetching and displaying content, see Query content.

MVC designers are written in AngularJS. The ASP.NET Core framework uses automatically generated widget designers. These designers are also supported by MVC widgets. Thus, the recommended approach is to first migrate to the autogenerated designers, so you can easily switch the framework going forward.

For more information, see Autogenerated field types. 

Having the Default or OpenID authentication protocol configured for Sitefinity, enables the Renderer and Sitefinity CMS to be in a Single Sing On (SSO) scenario, as well as Single Sign Out. This means that when you log in Sitefinity CMS, this automatically logs you in the Renderer app.
For example, the login form on an MVC-based page automatically logs the user to the ASP.NET Core Renderer or vise versa.
The biggest benefit here is that when a user requests a ASP.NET Core page the HttpContext.User property in the ASP.NET Core Renderer app is properly configured with the ClaimsIdentity of the logged user. Because this is valid for only the GET requests that are related to rendering Sitefinity pages, if you want, you can to add it to any other request, such as form post to a custom controller.