Migrate your pages to .NET Core
You can gradually migrate your MVC pages to .NET Core using the hybrid development approach - running both MVC and .NET Core pages in the same project. This is possible, because the .NET Core Renderer does not limit you to create and edit only .NET Core pages. Using the Renderer, you can work with .NET Core or MVC. This means that, in each site, you can have a mixed collection of all both supported rendering mechanisms.
However, rendering .NET Core widgets in MVC based pages or vice versa is not possible.
This hybrid development approach helps you to migrate to .NET Core in the following scenarios:
- If you want to have all of your pages based on .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 .NET Core, you can create your new pages in .NET Core independently of your existing pages in MVC.
Migration of widgets from MVC to .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:
Migrate the View and ViewModel classes
In general, the
ViewModel classes must not contain any logic. Therefore, you can easily copy and migrate them from the MVC to the .NET Core widgets.
There are some differences in the APIs for referencing scripts.
For more information, see Client-side development for the .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.
Migrate the Controller class
The controller class logic is designed to connect the logic of the
Model and the
View. This is also true for the .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
Migrate the Model 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.
Migrate the designers
MVC designers are written in AngularJS. The .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 .NET Core Renderer or vise versa.
The biggest benefit here is that when a user requests a .NET Core page the
HttpContext.User property in the .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.