Migrate your pages to .NET Core

Hybrid development

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 mechanism

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 View and 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 ViewComponent class. 

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

Frontend authentication

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.

Want to learn more?

Sign up for our free beginner training. Boost your credentials through advanced courses and certification.
Register for Sitefinity training and certification.

Was this article helpful?