Dev GuideAPI ReferenceUser Guide
HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback

Note

See also [Upgrade Assistant](🔗) which is a tool that automates the transition from an ASP.NET Standard project to an ASP.NET Core project.

Microsoft has the following guidelines for migrating to ASP.NET Core: [Overview of porting from .NET Framework to ASP.NET Core](🔗).

If your add-on contains views, configure the the assembly for precompiled views by changing the SDK type for the project to Razor as:


You should also add the following property to the _.csproj_ file:

## Views locations
To avoid collisions in view locations with the partner website, you should store the views for the app (add-on) under a custom folder in the project. If not specified, the default convention is that views are stored under a top folder `<AddonName>.Views`, like this:

You also can specify `viewFolder` in _module.config_, like this:

In that case, the views in the project should look like this:

## Precompiled views
A shell module or add-on can have views that are distributed as content together with the module/add-on and then at runtime the views are located through an `IFileProvider` (previously `VirtualPathProvider`). You can still have views located and compiled at runtime but that requires that the application enables the runtime compilation. The modules/add-on should precompile the views and distribute them in an assembly (typically named _<addon>.Views.dll_) instead.
To avoid risk for view conflicts with application/other apps (add-ons), CMS adds, by default, a view location expander that searches for views in location _<moduleName>.Views/Views_. You can also use the `viewFolder` attribute in _module.config_.
## Access rights
Previously, shell modules were protected by a configuration for the shell location in _web.config_ (typically path _/EPiServer_). Instead, each endpoint that is registered for a shell module is associated with a policy.
You can specify the policy to use for the module through the `authorizationPolicy` attribute in _module.config_. If you do not specify a value for `authorizationPolicy`, a module's endpoints are registered with `ShellModule.DefaultShellModulePolicy`, which requires that user is part of any of the following roles: **WebEditors**, **WebAdmins**, **CmsAdmins**, or **Administrators**.
## JSON Serialization
In an ASP.NET Core application, a “global” serializer is registered (by default from _System.Text.Json_ but you can configure it as NewtonSoft). Use the global serializer for model binding of posted data when you use the `[FromBody]` attribute and when data is returned using OK result, or automatic `IActionResult` conversion.
You should not rely on the global serializer for add-ons or modules because the end application can configure it in different ways (such as pascal or camel-casing). You should let each module register its own preferred serializer.
If no specific configuration is needed, then it can be specified in \*module.config\*\* using the `moduleJsonSerializerType` attribute.
  • Enter the **Net** value to specify the built-in serializer in net core.
  • Enter **Newtonsoft** to use **Newtonsoft.Json**.
  • If the module or app requires a custom configuration then it can set a **None** value and instead call either extension method (to `IServiceCollection`), `UseSystemTextJsonSerialization`, or `UseNewtonsoftSerialization`.
The extension methods let the serializer have a custom configuration. You can register a serializer per assembly but also override per type.