Johan Björnfot
Nov 22, 2017
visibility 10329
star star star star star star
(16 votes)

CMS 11 - A package breaking release

At Episerver we are using continuous releases and we follow semantic versioning. That means that we release features and bugfixes continuously. A major release indicates that there is breaking change compared to the previous version. The main breaking change we have introduced in CMS 11 is that we have separated our packages in "core" runtime packages and packages dependent on specific technologies. Some of the new packages are:

  • EPiServer.Framework.AspNetEPiServer.CMS.AspNet - Contains the ASP.NET specific implementations of CMS like WebForms and MVC 5 support.
  • EPiServer.ServiceLocation.StructureMap - A StructureMap based IOC implementation. Having this as a separate package opens up for newer version of unsigned StructureMap (planned to be release in a near future) but also for other implementations of IOC containers.
  • EPiServer.XForms - Optional package that can be used if xforms is used. 
  • EPiServer.DynamicContent - Optional package that can be used if dynamic content is used
  • EPiServer.Search.Cms - Optional package if EPiServer Search is used.

The main purpose is to achieve a better separation of concern. One goal was to have a core runtime that is not dependent to be executed in a specific environment like ASP.NET but instead can be setup in for example an integration test.

.NET Standard

The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations. The specification is maintained by .NET implementors, specifically Microsoft (includes .NET Framework, .NET Core and Mono) and Unity. The idea is that a library that is compliant with NET standard can be consumed and executed on all environments where .NET is supported (a.k.a. cross-platform library).

Previous to CMS 11 all Episerver CMS packages (e.g. EPiServer.Framework, EPiServer.CMS.Core) where dependent on assemblies only available on .NET Framework and could hence only execute on environments where .NET Framework is installed.

In CMS 11 our "core" packages EPiServer.Framework and EPiServer.CMS.Core are now .NET Standard 2.0 compliant. The packages EPiServer.Framework.AspNet and EPiServer.CMS.AspNet that contain the ASP.NET specific implementation (e.g. with dependecies to System.Web, System.Web.Mvc and System.Configuration) still requires .NET Framework.

An overview of the packages are shown below:

Image CMS11.png

The existing applications today that are ASP.NET application will require the EPiServer.CMS.AspNet package (supporting both WebForms and MVC 5) and will execute on ASP.NET on .NET Framework. However the separation of packages also opens up for example for integration tests (that do not require ASP.NET) and also since core packages are now .NET Standard compliant it is also possible to build other types of applications (e.g. Console application or Web API) based on .Net Core. 

We aim to release a package that will assist with setting up CMS runtime in an ASP.NET Core application within a near future. This package will for example contain an implementation of our IOC abstraction based on the default dependency injection implementation in .Net Core. 

Nov 22, 2017

Comments

error Please login to comment.
Latest blogs
Serving Heavy Multilingual Content Efficiently with Optimizely SaaS CMS

When building enterprise-grade applications on modern headless stacks, performance is governed by payload efficiency. Optimizely SaaS CMS and...

Vipin Banka | Aug 31, 2026

The Under-Documented Optimizely Caching API I Somehow Missed

I recently discovered some useful, but poorly documented, caching features in Optimizely CMS. Here’s how ReadThrough, ReadStrategy.Wait and master...

Dom Reilly | Aug 31, 2026 |

Beyond [Authorize]: Function-Level Permissions in Optimizely

Why basic role checks fall short and how Permissions to Functions unlock audience-based access control The Problem with Basic Authorization ASP.NET...

Sanjay Kumar | Aug 28, 2026

Insights from upgrading Optimizely CMS 12 to CMS 13

Optimizely CMS 13 has been here a while now, so I wanted to share some insights from a few of the migrations that has been done. The framework and...

Pär Wissmark | Aug 28, 2026 |