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.