Johan Björnfot
Nov 22, 2017
(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


Please login to comment.
Latest blogs
Optimizely community meetup - Sept 29 (virtual + Melbourne)

Super excited to be presenting this Thursday the 29th of September at the Optimizely community meetup. For the full details and RSVP's see the...

Ynze | Sep 27, 2022 | Syndicated blog

Preview multiple Visitor Groups directly while browsing your Optimizely site

Visitor groups are great - it's an easy way to add personalization towards market segments to your site. But it does come with it's own set of...

Allan Thraen | Sep 26, 2022 | Syndicated blog

The Report Center is finally back in Optimizely CMS 12

With Episerver.CMS.UI 12.12.0 the Report Center is finally re-introduced in the core product.

Tomas Hensrud Gulla | Sep 26, 2022 | Syndicated blog

Dynamic Route in ASP.NET Core When MapDynamicControllerRoute Does Not Work

Background Creating one of the add-on for Optimizely I had to deal with challenge to register dynamically route for the API controller. Dynamic rou...

valdis | Sep 25, 2022 | Syndicated blog