Planned breaking changes 2017 (CMS Core)

An update to let you know what breaking changes are planned for CMS Core, as we have done the last few years we plan for one breaking change release of CMS per year. With that said, please note that this is preliminary and subject to change. More details will be provided when we get closer to a release.

For many projects this will just require a re-build of the solution assuming you have stayed up to date with the continuous release process and continuously fixed the obsolete warnings that shows up.

New NuGet packages for ASP.NET integration

New NuGet packages EPiServer.CMS.AspNet and EPiServer.Framework.AspNet will be introduced which will contain all API's related to web development on the ASP.NET stack (both MVC and WebForms). Existing namespaces will be preserved to keep the upgrade as smooth as possible.

The goal is that the EPiServer.CMS.Core and EPiServer.Framework NuGet packages will be .NET Standard 2 compliant and will not contain any API's related to ASP.NET development, and that they in the future can be used stand-alone (without a web.config).

You might have noticed that we already started obsoleting methods that have dependencies on ASP.NET in core API's to prepare for this split. So for example the CreatePropertyControl-method in PropertyData will be removed since it has a dependency on WebForms (System.Web.UI.Control), but you can prepare for this change by registering controls on startup instead.

New NuGet package for StructureMap integration

A new NuGet package EPiServer.ServiceLocation.StructureMap will be introduced which will contain the integration with StructureMap, with support both for the existing signed StructureMap 3 and the new unsigned StructureMap 4 which we currently cannot support. The package only contain the integration and have NuGet dependencies on the official StructureMap packages. Episerver and module packages should not directly depend on this package but use our own abstractions for dealing with dependency injection, this API have been available for a few versions now and is already being used by most Episerver products.

This change makes it easier to support multiple versions of StructureMap but we are also looking into the dependency injection system that is shipped with .NET Core. Moving the dependency to a NuGet package is the same approach we have for logging, where we have abstractions in the platform and an integration in a separate NuGet package.

You might have noticed that we obsoleted the "Container" property in the initialization system and move that logic into an extension method, that was a preparation for this change where the extension method will be provided by a separate NuGet package (since EPiServer.Framework will no longer have any direct depedencies on StructureMap).

New NuGet packages for Dynamic Content and XForms

The legacy features Dynamic Content and XForms will be removed from the platform and moved into separate NuGet packages as add-ons instead (e.g. EPiServer.DynamicContent and EPiServer.XForms) with their own versioning number and breaking changes, as the platform progresses these features will become more limited over time. We recommend migrating to Forms or Blocks wherever possible.

PropertList<T> improvements

The base class PropertyList<T> is an API that have been in beta for a long time and has no official documentation, we know some projects are using it despite the shortcomings. We plan to make a few breaking changes to make sure the API properly can support these property types, document what they support and not, and then remove the beta stamp from this class.

As an example we are changing how properties are imported/exported by moving logic previously locked into PropertyData such as ToRawProperty to external services that can have their own dependencies and are easier to customize per property type. There will be a separate blog post with more details.

Performance improvements when loading content

Performance improvements up to 50% when content is loaded from the database, the results vary depending on the size of content types and the data being loaded. Besides optimizations of the API the larger behavioural change is that the CreateWritableClone-method is now also used when loading data from the database.

Bug fixes

We have a list of bugs that we have not been able to fix since they are considered breaking according to semantic versioning.

User interface changes

A separate blog post about breaking changes in the UI will be published later.

Getting access to pre-releases

We will publish pre-release versions on our NuGet site as soon as we have something that can be tested.