Sitefinity DX & .NET Core: Next Generation Cross Platform Development

An architecture built on separation of concerns has multiple positive effects on administration, development, hosting, deployment and scalability. 

The content you create can be reused and easily delivered and maintained across multiple frontend consumers. Whenever content is updated, it’s ready to be consumed via APIs by any frontend framework you choose to employ. Content editors have a high level of flexibility and independence, meaning developers on the other hand are free to explore more and better ways to improve the user experience and leverage diverse frontend technologies. 

The .NET Core renderer in Sitefinity 13, for example, is a stand-alone application that can be deployed and hosted anywhere. It can work on any OS that .NET Core supports and you can use any text editor. When developing new features and functionality, you work on the presentation layer of Sitefinity only, which lets you iterate at a higher speed.

The .NET Core Renderer started as a technical preview in Sitefinity 13.0 aiming to give early adopters a taste of the full .NET Core replatforming that's firmly on our roadmap. In upcoming releases, we will continue extending the functionality as we target a presentation layer fully relying on .NET Core as the technology to develop widgets, templates and scripts. The full frontend development suite. 

In Sitefinity 13.1, the Page Layout API received a major performance boost through a newly implemented cache mechanism. The Page Layout API is the key service exposing content to the .NET Core renderer, alongside multiple other frontend frameworks as well. A number of out-of-the-box .NET Core widgets were also introduced in the 13.1 release as part of Sitefinity’s .NET Core roadmap: content block widget, image widget and CTA widget.

Plans to migrate existing pages and widgets are being prepared for the upcoming releases. There will be several migration models available to Sitefinity license holders.

• Guidelines for the migration of MVC widgets - migration of MVC views and business logic (manual migration of code)
• One-way migration of existing pages to the renderer and editor: full migration of legacy pages built on MVC and Webforms along with widgets and templates. Considering ways to automate the process.

Migration of existing .NET Core projects to the CMS. Since we have seamless integration with the .NET core pipeline, users will be enabled to migrate their MVC razor pages and controllers to the CMS pages. This would be an entirely manual process.

Sitefinity constructs pages via the Page Editor with “drag and drop” support. Even users with little or no coding skills can easily build pages. Behind the scenes these widgets and their configurations are stored in the Sterility database as a meta model. The renderer can consume this model via REST services, parse it and construct a page for the specific set of widgets. It then renders the page in HTML and returns it to the end user.

These pages are based on templates coming from the Renderer. In the case of the .Net Core renderer, they are MVC Layout files in the file system. These layout files are available to choose from when creating a page. If a page is based on one of these layout files, the renderer will be able to render the page.

The standard approach to extending the Sitefinity frontend is to write custom widgets or configure/override the logic of the prebuilt ones. The corresponding elements for widgets in .Net Core are ViewComponents. Widgets that are available in the drag and drop editor correspond to the ViewComponents classes in the .Net Core Application.

The Sitefinity .NET Core Renderer is still in Community Technology Preview. If the two OOB widgets serve your needs, you are free to start developing with .NET Core. Although we plan to elaborate on it, we will not cease to support the standard .NET framework and the two-tier Sitefinity CMS architecture.