Blog posts by Per Bjurström

Visual Studio 2019 and Windows Server 2019

Mon, 15 Apr 2019 12:47:09 GMT

The Visual Studio integration now supports Visual Studio 2019, it should shortly be available in the Visual Studio Marketplace (the "Manage Extensions" menu option inside Visual Studio 2019). The Alloy sample templates that is shipped as part of the Visual Studio integration is also available as an open-source project on Github in case you missed that.

Our QA teams have also completed testing the different Episerver products on Windows Server 2019 and its now an officially supported operating system.

CMS drops support for WebForms

Fri, 19 Oct 2018 09:18:03 GMT

This is an early heads up that CMS 11.x will be the last generation of CMS with support for building templates on ASP.NET WebForms. When the ASP.NET MVC support was launched with Episerver 7 back in 2012 it quickly became the technology of choice for building modern web sites, some of our newer modules since such as Forms only supports MVC and Commerce dropped support for WebForms earlier this year. Today all new sites are either built on ASP.NET MVC or as a SPA.

For sites built on WebForms we will continue to support them on the CMS 11.x generation. There will be no breaking change release of CMS this year.

Performance improvements in CMS 11

Thu, 01 Mar 2018 15:58:58 GMT

Performance improvements are done continously but there are some that require breaking changes so I thought I mention some specifically that we did, they can have a huge impact on site performance.

Memory usage of PropertyData

Custom properties on any IContent is backed by a PropertyDataCollection that contains classes inheriting PropertyData. So in a running CMS site there might a ton of these classes cached into memory, small memory optimizations really make a huge difference here. In CMS 11 PropertyData was reviewed for references that did not had to be there, for example a reference to the LocalizationService was removed and backwards compatiblity with translation methods was resolved via extension methods instead. The more custom properties you have in a site, the bigger difference these changes makes to overall memory usage.

Load time from database

Previous optimizations and profiling we have done targeted a running site with a populated cache, for CMS 11 we tried to optimize cache misses when content is loaded from the database. For example, we changed so that the PropertyDataCollection is not created every time content is loaded from the database, instead a prototype is cached per content type and then cloned for each instance of that content type that is loaded from the database. This makes both the creation faster but also minimizes memory usage.

Memory usage in long running jobs

Jobs that go through all content in the database consume a lot of memory and you risk filling up the memory with content that never get accessed from the site, or even worse all content might not fit into memory. In those cases you would prefer to be able to control cache expiration, the default of 12 hours is probably not what you want.

It is now possible to define a cache scope with custom expiration:

var repo = ServiceLocator.Current.GetInstance<IContentRepository>();
using(var x = new ContentCacheScope { SlidingExpiration = TimeSpan.FromSeconds(10) })
{
   var content = repo.Get(contentLink)
   //etc..
}

Scheduled jobs uses cache scope and run with a custom expiration of 1 minutes by default. Note that custom cache expiration only affects cache misses when content is loaded from the database and added to the cache, any content already in the cache is not affected. Even though it is also possible to disable the cache completely, I would not recommend it since it puts a lot of strain on the database (caused by language fallbacks and other features, a single call to get content might generate several calls behind the scenes).

Performance test

To test some of these changes I created an ordinary Alloy demo site and generated ~10,000 pages. The test is pretty basic, it clear the cache and recursively loads all content from the database while monitoring memory usage via the Garbage Collector (GC) in a background thread.

I tested 3 different scenarios:

CMS.Core 10.10.4 calling GetChildren recursively
CMS.Core 11.3.4 calling GetChildren recursively
CMS.Core 11.3.4 calling GetChildren recursively with cache scope set to 10 seconds

In this test just upgrading the site to CMS 11 made the code run 2 seconds faster and consumed 60 MB less memory. The green line indicates running with a cache expiration of 10 seconds which might be a bit too small to have any real value but it shows nicely that it is possible to keep memory usage down when required for long running jobs. The content was generated into 2 hierarchies causing a bump in the lines when it loads already cache content and then moving over to the second hierarchy of not cache content.

The Y axes is memory usage in megabytes and the X axis is time elapsed in seconds.

It might be worth mentioning here that there is a pretty nasty bug in ASP.NET 4.7.1 causing the cache scavenger that tracks memory usage to stop working, which might cause a site to run out of memory completely, you can read more about it here and here.

CMS 11 pre-release packages

Mon, 30 Oct 2017 10:25:01 GMT

Pre-release packages of CMS 11 are being published to the Episerver NuGet feed today. A pre-release version indicates that the version is unstable, it has currently been tested by both QA and internal teams at Episerver for a few weeks but there are still a few issues that we are investigating. You can read about the changes in these posts about breaking changes in Core and breaking changes in UI.

More documentation will be published when we release the actual packages. If you find issues or have questions let us know.

Upgrading an Alloy MVC

Make sure you have latest version of Visual Studio (Tools->Extensions and updates->Updates->Product Updates)
Right click on the Episerver project and select Properties, make sure project targets .NET Framework 4.6.1 or higher. Recompile and test.
Open "Manage NuGet packages", select Updates, select the Episerver feed, select "Include pre-release"
Select all packages and click on Update
If site is using XForms install that package (EPiServer.XForms)
If site is using Search install that package (EPiServer.Search.Cms)
If site is using Dynamic Content install that package (EPiServer.DynamicContent)
Build and start

NOTE: Packages for Find, Commerce and other add-ons are not yet available, so testing these pre-release packages will ony work on sites that only use CMS.

Quick summary of new packages in CMS 11:

EPiServer.CMS.AspNet + EPiServer.Framework.AspNet
Contains all APIs and configuration related to web development on the ASP.NET stack (both MVC and WebForms). Existing namespaces are preserved to keep the upgrade as smooth as possible.

EPiServer.ServiceLocation.StructureMap
Contains the integration with StructureMap 3, a new version supporting StructureMap 4 will be released soon.

EPiServer.CMS.TinyMCE
Contains the rich-text editor based on TincyMCE.

EPiServer.Search.Cms (optional)
Contains the CMS integration for full-text search. Not required for Find or other search implementations.

EPiServer.XForms (optional)
Contains the XForms have now been moved from the platform to a separate NuGet package.

EPiServer.DynamicContent (optional)
Dynamic Content has now been moved from the platform to a separate NuGet package.

EPiServer.Packaging (optional)
The add-on store is no longer a required package.

Known issues

These issues will be fixed before release.

Sometimes content that should not be visible, such as container pages, randomly show up in menus and similar.
EPiServer.Logging.Log4Net 2.2 package fails to update the binding redirect in web.config, you need to manually correct this.

Planned breaking changes 2017 (CMS Core)

Thu, 17 Aug 2017 14:45:00 GMT

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.

Support for Visual Studio 2017

Mon, 06 Mar 2017 14:18:43 GMT

A new version of the Episerver Visual Studio extension with support for Visual Studio 2017 is now available on the Visual Studio Marketplace. We support all editions from Community to Enterprise. Visual Studio 2017 will be available for download on March 7th.

The best way to install it is using the "Extensions and updates" menu inside Visual Studio.

What changed

This new version contains the latest releases of the CMS NuGet packages, we plan to have another version released in the coming weeks with the latest version of the Find packages as well.

Visual Studio 2017 requires add-ons to adhere to new rules and a packaging format to support the minimal footprint of Visual Studio 2017. So there are a lot of under-the-hood changes in this release.

There is also full support for Visual Studio 2015 ofcourse. Support for Visual Studio 2012 and 2013 has been dropped for this version, but will make the old version downloadable stand-alone.

The page on the Visual Studio Marketplace contains more details. Try it out and let us know if you find any issues.

Planned breaking changes 2016

Thu, 25 Aug 2016 15:08:05 GMT

An update to let you know what breaking changes are coming in CMS this year.

The main breaking changes are:

A new state AwaitingApproval for content. We are also adding new events to IContentEvents and new save actions. Supports features around content approval.
IContentRepository.Save and the events around that (IContentEvents) have a few quirks and odd behaviours that we have fixed to make the API more consistent and work better with approvals.
Migration to UTC dates in the database will be a required step when upgrading, be ready by doing the migration today.
Reviewed all APIs to make sure we do not expose implementation classes as part of our public versioned API. We will make a separate post about this with more details.

Some of the smaller breaking changes:

Links to unpublished content will return 404 (instead of login screen).
Localized texts will fallback to a fallback culture in the language files before falling back to values specified in code.
LanguageBranch class now implements IReadOnly to support read-only caching.
No longer possible to create sites without at least one host defined.
Properties PageData.StartPublish/StopPublish are changed to Nullable.
StartPublish will be null until published or set explicitly (today it defaults to the created date which is misleading).
Fixed confusing handling of empty properties (for example assigning an empty link item collection to a typed model resulted in a null value)
IContentVersionRepository List methods have been consolidated into one
The UI Framework EPiServer.Shell.dll will be moved from NuGet package EPiServer.Framework to EPiServer.CMS.UI.Core.

A lot more details will be provided as part of the release, including a list of all breaking changes and which APIs are being changed. Pre-release packages of the breaking change release will be made available as part of the continous release process in the coming weeks.

Planned breaking changes 2015

Thu, 02 Jul 2015 07:59:42 GMT

An update to let you know what breaking changes we are doing in CMS later this year. For many sites the changes will go unnoticed, just another major version number, the latest version of the Alloy templates for example requires no code changes - just recompile and you are done.

Breaking Changes

Remove hard dependency on Log4Net. This will make it possible to run on the latest version of Log4Net or use another provider. Link to SDK.
As previously announced we will remove our implementation of WWF (Windows Workflow Foundation), where WWF 3 that we are using is now obsoleted and (officially) not supported on Azure. We are instead investing in "Projects 2.0" and you can follow the release feed to see this beta feature light up and support rich collaboration on not just pages but block, media and catalog content.
Remove remains of the VPP system that was obsoleted in CMS 7.5. Link to SDK.
Remove Content Channel and the other ASP.NET 2 Web Services that was last shipped in 7.5 and officially obsoleted in 8.
Remove assemblies EPiServer.BaseLibrary.dll and EPiServer.Implementation.dll. These assemblies was the framework of CMS 5 and contained internal features such as the ObjectStore. There are a few classes in there still used that are being moved to EPiServer.dll.
Remove Page Objects. A feature that pre-dated blocks. Obsoleted in 7.5.
Disable Dynamic Properties by default. As officially annonced in 7.5 this feature does not support the new user interface. We know there will be a lot of sites upgrading that are using dynamic properties so it will be left intact and there will be a setting to enable/disable this feature.

Release later this year with more details. See this post by Magnus for updates on planned breaking changes in Commerce.

Automatic database updates, Visual Studio 2015 and MVC 5

Mon, 01 Jun 2015 08:39:08 GMT

Automatic database updates

When we first starting shipping database updates in our NuGet-packages we said that we would like to get back to this area:

"We have discussed building automatic database schema updates into the products but based on the feedback we got early on it was more important to get the simple and controlled semi-automatic approach right first. Maybe based on your feedback and ideas we will get back to this area and offer more automation, let us know what you think."

The feedback has been very clear that there should be a built-in/official scenario for supporting automatic updates, especially when publishing to Azure the semi-automatic approach is too cumbersome. And for developers to keep track of database updates and importing them into custom database projects seems like an unnecessary step (unless you have other migration steps or an existing process for database updates that you want to integrate into).

We discussed many approaches to this but finally decided that the built-in support should be flipping a switch and it should just work. When EPiServer starts, if it detects an older database version and you enabled this feature, it will automatically update the database to the correct version. The scripts from 7.5 and up are embedded into the assembly. Based on early feedback from some of our fellow EMVP we have also added extension points to make it possible to for example backup the database, or provide custom validation logic, refer to Automatic schema updates for more details. Also see Henrik Fransas blog about customizing updates in Azure.

This feature will be a complement to the existing Update-EPiDatabase/Export-EPiUpdates cmdlets, these options are not going away. Automatic database updates are disabled by default, we want it to be a conscious decision to enable this feature.

We are also adding a new cmdlet Initialize-EPiDatabase that installs the current database schema into an empty database making it easier to switch to a new database in development.

The new database features will be supported by Commerce as well, automatic updates as of today and Initialize-EPiDatabase in another week or so.

Visual Studio 2015 support and MVC 5

We are also releasing an update of the Visual Studio extension. New EPiServer projects in this version will be based on MVC 5, which as been a popular request. An SDK article on how to upgrade an existing project to MVC 5 is also available, to keep the impact of this update to a minimum we have decided to continue to support MVC 4 in our NuGet-packages but we urge everyone to upgrade. We have also added support for the release candidate of Visual Studio 2015.

The update will be published today and should be visible as an update under ”Tools->Extensions and Updates” inside Visual Studio or on the gallery page. The NuGet-packages are available on nuget.episerver.com as usual.

Uploading blobs to Azure Storage with PowerShell

Fri, 10 Apr 2015 15:15:23 GMT

When uploading media in EPiServer the binary data are stored in a system called blob providers. By default media are stored on disk in a folder located at <path_to-site>\App_Data\blobs. Moving all those blobs to Azure is just one line of code in the Azure PowerShell console (just make sure the current directory is the blobs-folder):

ls -File -Recurse | Set-AzureStorageBlobContent -Container mycontainer

If you have not used Azure PowerShell before you might want to read the getting started. To store blobs in Azure (you don't need to run the site in Azure to do this) install the EPiServer.Azure package and change blob provider in web.config:

    <blob defaultProvider="azureblobs">
      <providers>
        <add name="azureblobs" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure"
              connectionStringName="EPiServerAzureBlobs" container="mycontainer"/>
      </providers>
    </blob>

And then add the connection string:

  <connectionStrings>
    <add name="EPiServerAzureBlobs" connectionString="DefaultEndpointsProtocol=https;AccountName=myaccount;AccountKey=abcdefghij" />
  </connectionStrings>

Screenshot:

There is also a scheduled job on NuGet called EPiCode.BlobConverter that supports uploading to any blob provider if you prefer having an actual user interface ;-)

Typed tabs/groups

Wed, 11 Feb 2015 13:53:08 GMT

Currently in the typed model you are limited to defining sort order on individual content types and properties. The order defined then indirectly defines in which order groups are displayed when creating new content, and in which order the tabs are shown when editing content in the forms view. Normally you define groups as a list of constants that you use in the DisplayAttribute:

[ContentType(GroupName=GroupNames.News, Order=1)]
public class ArticlePage : PageData
{
  [Display(GroupName = GroupNames.Contact)]
  public virtual ContentReference Image { get; set; }
}

public static class GroupNames
{
   public const string News = "News";
   public const string Contact= "Contact";
}

In CMS 8 we are adding support for defining order and required access on the groups themselves. Just decorate the class:

 [GroupDefinitions]
public static class GroupNames
{
   [Display(GroupName="MyNews", Order=1)]
   public const string News = "News";
   [RequiredAccess(AccessLevel.Publish)]
   public const string Contact= "Contact";
}

Groups that do not have any order defined will fallback to the indirect sorting and will have sort index set to -1. It is also possible to override built-in groups to change sort order, for example:

[GroupDefinitions]
public static class GroupNames
{
    [Display(Order = 1000)]
    public const string Content = SystemTabNames.Content;
}

See SDK article Grouping content types and properties for more details.

NuGet: A new database version for CMS

Mon, 09 Jun 2014 15:57:25 GMT

We are releasing an update to CMS that contain database schema changes, since this will be the first time we release schema changes via NuGet I thought I spend some time describing how it works and why we made certain choices. If you are using Commerce and been updating the past weeks you will already be familiar with these commands.

We started some time ago building support for shipping database updates in NuGet packages based on some design principals:

Never modify the database without consent: You should be able to update packages without being “scared” that schema changes are applied to a shared database or a database without backups that you need to revert.
Use ordinary SQL files: Make sure environments that have high auditing requirements can run them manually when needed.
Simple to update for devs: Make it super-easy to update the database schema cross products, assuming both CMS and Commerce starts shipping schema changes more often you don’t want any manual trickery.

The first thing you notice after applied the latest update is the more helpful error message when you start the site for the first time.

To apply the updates open up the ‘Package Manager Console’ and run the command Update-EPiDatabase:

This command will update database schema for the database defined in the connection string EPiServerDB for CMS (and EcfSqlConnection for Commerce), the printout shows which files it finds that are potential updates.

The files are by convention:

Stored in a folder tools/epiupdates/sql in each NuGet package.
Files are named after the package version they were introduced in (ie 7.8.0.sql)
Each file begins with a validation statements that determines if the file should be executed or not (you can run this statement manually if need to very if a file has been applied or not).

For troubleshooting, or if you just want to see more details, you can add -Verbose:$true.

Our recommended approach to deploy changes to production is to run Export-EPiUpdates to export the schema changes to a folder that is independent of Visual Studio, this command basically does the same thing as Update-EPiDatabase but dumps the commands into a bat file to make them portable and easy to run in any environment. If you have a look inside that file you will notice a simple command line tool epideploy.exe that used to execute scripts, same tool that is executed when you update Update-EPiDatabase.

You can also run this command on the development site to test it out, if there are no changes nothing will be modified so it’s safe to run multiple times.

A final note. We have discussed building automatic database schema updates into the products but based on the feedback we got early on it was more important to get the simple and controlled semi-automatic approach right first. Maybe based on your feedback and ideas we will get back to this area and offer more automation, let us know what you think.

Note: All of this is documented in the SDK under “Updating EPiServer via NuGet”, including schema changes to configuration which I did not cover in this post.

New version of Visual Studio extension available

Tue, 13 May 2014 09:01:20 GMT

A few weeks ago we released an update to the Visual Studio extension to create new sites without using Deployment Center. With that update we made it possible to create new sites configured with all the required NuGet packages, much like how ASP.NET projects are working in Visual Studio.

Today we are releasing another update to include the Alloy demo sites in the Visual Studio extension, both the MVC and the WebForms version.

We combined the project templates to a single option in the “New Project” dialog to avoid having too many combinations and alternatives:

Instead we show an options dialog where you can select project templates, and a new option to add the built-in search capability (the EPiServer.Search NuGet package).

A nice aspect for sites created based on the Alloy templates is that you get custom namespaces which was not previously possible:

Another requested feature was the possibility to use some item templates in class libraries so we added that feature as well:

How do I download this update?

Under Tools –> “Extensions and updates” inside Visual Studio 2012 or 2013, search for “EPiServer” in the “Online”-section. Or the “Updates”-section if you already have it installed. As part of this release we are also in the process of updating the Getting Started guide and releasing an updated SDK. Release notes available on Visual Studio gallery.

Creating site from NuGet packages

Thu, 27 Mar 2014 11:15:45 GMT

Today we are releasing a new version of the Visual Studio extension that runs completely standalone, no requirement on Deployment Center (no MSI’s, no GAC etc.). Sites created with the Visual Studio extension are configured with NuGet packages out-of-the-box and are more similar to ordinary ASP.NET projects (both SQL and geolocation databases are for example stored in App_Data to mention one thing). The new templates also use Universal Providers to simplify deployment to Azure.

It may not be obvious but the Visual Studio extension does not need an internet connection to create new sites, which actually is a requirement from Microsoft for project templates (so no connection to nuget.episerver.com required). You can of course go online and update the solution to the latest greatest versions after the site is created, the Visual Studio extension will not be released as often as our NuGet packages even though we will of course keep it up to date over time.

There are also a couple of smaller changes such as the “Scheduled Job” template exemplifies stoppable jobs with UI feedback. Big thanks to you that tested and contributed to the previews builds. See release notes for details.

How do I get it?

Under Tools –> “Extensions and updates” inside Visual Studio, search for “EPiServer” in the “Online”-section. Or the “Updates”-section if you already have it installed. As part of this release we are also in the process of updating the Getting Started guide and releasing an updated SDK.

Want to create your own project templates?

An interesting part of this release is the project templates (what you see under File->New Project->EPiServer), they are just an empty project that installs the new EPiServer.CMS package. That means that you can have your own “empty” starter projects and just add this package to get a working EPiServer site.

I created a sample starter kit off the Visual Studio templates with a start page and the media types:

git clone https://github.com/bjuris/EPiServerStarterKitSolution.git (or click on “Download ZIP”)
Open the Solution File and in Package Manager Console run: Install-Package EPiServer.CMS
Start the site, hit F5. Ready to go.

Feel free to fork and change to your heart’s content.

Do I need the Visual Studio extension for this? No, but the Visual Studio extension comes with some 20 item templates with everything from Initialization Modules to Page Types, they work on any ASP.NET project. So, even though you don’t use our project templates you can still use the item templates which at least I find highly usable.

Remote Events Providers (EPiServer 7.5)

Tue, 03 Dec 2013 14:23:02 GMT

A long time ago I wrote an article that among other things used a trick to change how Remote Events works (the system used in load balancing). The implementation switched out Windows Communication Foundation (WCF) in favor of a custom database implementation to get events flowing in synch with data (when using SQL replication).

But now we have official support for Event Providers in 7.5 – and it’s used by both Commerce and CMS. It’s a pretty easy API to implement if you want to make your own provider:

The built-in provider, based on WCF, is the same implementation used in previous versions so it should be a smooth upgrade if you have a complex setup with TCP endpoints for example.

But we are also releasing more providers on the NuGet feed, one for Azure Service Bus and one for Amazon SQS/SNS to take advantage of the elastic scaling of cloud environments. How to configure them are available in the CMS SDK.

Anyhow, I picked up the old code from my custom implementation and rewrote it into the new event provider system. Basically its just serializes and deserializes message to and from a table in SQL Server, more a proof of concept than anything I would put into production. It’s available on GitHub if you want to play with it.

Synchronization of typed models

Tue, 23 Oct 2012 17:10:05 GMT

EPiServer 7 comes with typed models for pages and blocks, this post is about what happens when we synchronize the code with the database (and not about how you define the model). All of this is documented in some way or form in the SDK and there are more areas like refactoring and renaming of properties that you can read about in the SDK that I won’t go into.

Overview of synchronization

In the first phase during startup classes marked with the [ContentType]-attribute are scanned and meta data on these classes and its properties are added to an in-memory repository, this repository contains all the information from your model classes down to individual attribute settings on properties. This phase is the only phase that deals with reflection.

In the second phase the in-memory repository is analyzed by comparing it to the content types stored in the database. From this phase the in-memory repository is updated with information about synchronization status such as if a property is new or removed and if there are any conflicts.

In the third phase any changes are committed to the database, as a general rule changes that cause loss in content on the site are never committed automatically. For example if you delete a property from code that has content stored it will be marked as “Missing in code” in admin mode and you will have to manually delete it. By enabling logging using log4net you can detect warnings or errors.

Default Values – not the ones you define in code

One of the features is that administrators can do a manual override of some settings defined in code, such as for example if a property is required or not. The “Revert to default” button in admin mode (when you are editing a property or content type) can be used to reset settings defined by an administrator.

The architecture behind this is that content types are merged with the in-memory repository when loaded from the database. And when a content type is stored back to the database it is stripped of any values that comes from the typed model. So some changes in code are actually never stored in the database at all. If you want to dig deep into the database you will notice that a lot of columns in tblPropertyDefinition, that contains defined properties, are actually NULL when the defaults comes from code.

Sort order of properties

As some of you know the sort index on property definitions has been a double-edged sword, it had this feature that it enforced unique sort orders to make it easier to get consistent sort order and to re-sort properties in the user interface.

This feature was good when page types was only entered manually and it helped the person entering the type to get correct order of things. This feature is painful when defining properties in code since the code and what is stored in the database easily gets out-of-sync if you don’t enforce unique index in code as well. So as of EPiServer 7 we have changed this behavior, sort index is never enforced when saving properties but always enforced (1..n) if you re-order using drag-n-drop or use the move up and down arrows in admin mode. To make sure the sort order is consistent we order first by index and for properties that do not have a sort index we “put them at the end” and order by the ID, so order of creation basically.

Synching manually

You can disable the commit phase by setting enableModelSyncCommit to false on the siteSettings-element in episerver.config. This can be useful if there are many developers working on a shared database and you want to avoid a newly added property to be removed from another piece of the code. In some scenarios it makes sense to have it disabled always in development and the dev working on the types should enabled it when needed.

A new Synchronize-button will appear in admin mode so that you can manually start the sync process on a per content item bases, it’s the exact same process as would start automatically if this setting was not disabled but on a single type. For new types you can of course create an empty page/block type and then use the Guid in the [ContentType]-attribute to hook up your code to the database.

Deployment in load balanced scenarios

Deploying code in load balanced scenarios gets a bit more trickier when your code is automatically updating the database, if you just add the latest code one server at a time with full control over when they go down and come up you are fine. But if you have a staging server and another front end server reboots while you are doing your final testing on the code using a shared database you don’t want it changing your content types with old models in the live environment.

You can solve this by disabling the commit phase on all servers but one, the staging server, as described above. You can also use our support for semantic versioning. Every time a content type is changed we make sure we update the full type name including assembly version number. If the sync process detects that for example version 1.2 was the version that updated the content type the last time and the code has version 1.1 we silently back off from that type and display a little warning message in admin to notify you. This feature can of course be used to your advantage in dev environments as well.

Another point is that the event system is not enabled until after the synchronization has completed to make sure deploying new content types on one site does not clear the caches on all other sites/servers forcing them to read potentially not up-to-date info and put unnecessary load on the database.

Note: We only check major and Minor on the version number (major.minor[.build[.revision]]).

Changing type on properties

As I mentioned in the introduction all changes that does not result in data loss for the content will be committed, including changing types on properties. But sometimes you need to change type on a property and you are fine with loosing data stored on it, so in the case of mismatch on a content type we enable the previously read-only fields Name and Type in admin mode to allow for manual override of whatever we did not dare do automatically.

EPiServer 7: Startup Performance

Wed, 12 Sep 2012 11:41:00 GMT

One of the areas we have improved is the startup time of EPiServer 7, there is a lot of new functionality that requires initialization but it actually starts faster that previous versions.

Some of the changes we have done is using parallelization where a single initialization module runs multiple independent tasks in parallel or run some tasks asynchronously. Another change to speed up typed pages is that we precompile the Castle proxies that is backing your custom models , that processes starts in the background before the the first page is accessed. We also enabled the optimizeCompilations by default which I blogged about a few years back, that does a big difference. We also rewrote assembly scanning and implemented a disk based cache and centralized discovery of types to avoid doing reflection over and over again.

To make it easier to debug startup performance there is a hidden gem that displays the last startup and how long time each initialization module needed at http://[site]/[UI]/Shell/Debug/ShowTimeMeters.

There is a web.config setting in appSettings that enables this debug view, you get the name of the key that goes into web.config when you access the url the first time.

Update: If you are running one of the EPiServer 7 preview versions then the URL will be http://[site]/[UI]/modules/Shell/Debug/ShowTimeMeters instead. Thanks Steve for noticing.

Initialize HTTP events in a module

Thu, 27 Jan 2011 10:51:39 GMT

EPiServer CMS 6 and Community 4 introduced a new approach to initialization, read more about it here.

We are adding infrastructure for subscribing to HTTP events in the R2 wave with the new IInitializableHttpModule interface which is defined like this:

public interface IInitializableHttpModule : IInitializableModule
{
     void InitializeHttpEvents(HttpApplication application);
}

Every time a new HttpApplication is being initialized this interface will let you participate and listen to events. Do remember that this is an initializer interface, there will only be one instance of your initializer but there will be many HttpApplication instances being initialized. The use case for this interface is to able to deploy modules without adding adding an HTTP Module in web.config.

A skeleton module to use the new interface:

[ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
public class MyInitialization : IInitializableHttpModule
{
    public void InitializeHttpEvents(HttpApplication application)
    {
        application.BeginRequest += application_BeginRequest;
    }

    public void Initialize(EPiServer.Framework.Initialization.InitializationEngine context)
    {
        DataFactory.Instance.PublishedPage += Instance_PublishedPage;
    }

    public void Uninitialize(EPiServer.Framework.Initialization.InitializationEngine context)
    {
        DataFactory.Instance.PublishedPage -= Instance_PublishedPage;
    }

    public void Preload(string[] parameters)
    {
    }

    void Instance_PublishedPage(object sender, PageEventArgs e)
    {
        //implementation
    }

    void application_BeginRequest(object sender, EventArgs e)
    {
        //implementation
    }
}

CDN Support goes open-source

Mon, 14 Jun 2010 14:00:12 GMT

Last year I did a lot of research on using a CDN with EPiServer CMS, that resulted in a module that I released on my blog.

Since then at least 1 site is running it live and a few others are thinking about using the module. Today we are making it available as open-source. The module should work with both CMS 5 R2 and CMS 6.

The code is tightly integrated with the URL rewriting mechanism and Virtual Path Provider’s (VPP). Since the module may generate large amounts of calls to the VPP API’s there is also a small cache MicroCache<T> that offloads the resolving of URL’s. The solution also contains a test project.

Let me know if you have any feedback or want to contribute to the project.

Visit the project here: CDN Support for EPiServer CMS

Using the CSRF page extension in CMS 6

Fri, 23 Apr 2010 17:22:45 GMT

EPiServer CMS 6 has a new page extension that add CSRF prevention on a Web form. I won’t go into detail of the CSRF exploit since Wikipedia has a good description. In short, someone uses a visitors browser to send a malicious request to another site were the user is already logged in to (or trusts in some way).

The countermeasure implemented in this page extension is a per-user cryptographically generated token stored in a cookie. A hidden field on the page is generated based on the user token and salted with information specific to that page. Whenever a post is made to the page we validate the tokens in the PreInit phase. There are no server-state involved except a per-site secret stored in the database used to protect the values from tampering (safe for load balancing).

This page extension called AntiForgeryValidation is completely transparent to the user as long as they have cookies enabled and hopefully to you as a developer as well.

using EPiServer.Web.PageExtensions;

namespace EPiServer.Templates
{
    /// <summary>
    /// The default start page
    /// </summary>
    public partial class Default : TemplatePage
    {
        public Default() : base(AntiForgeryValidation.OptionFlag,0)
        {
        }

But, you do want to test that it actually works after you implemented the code, the easiest way is to use a tool like Firecookie to manipulate the request. For example: Make a request to the page and store away the cookie __epiAntiForgeryToken_X, close the browser and go the page again, now edit the cookie and paste the old value before doing a submit to the page. The error you will get should be “This request has probably been tampered with. Close the browser and try again.”.

There are some limitations, it won’t work with output caching since we need the unique field on the page. Also, if you are doing some custom coding you need to post the hidden field “_epiAntiForgeryToken” as well or the page won’t validate. Also, the user must have cookies enabled.

This extension is used extensively on administrative interfaces in EPiServer CMS 6 that is based on Web forms. If you ever worked with ASP.NET MVC you will know that this feature exists in MVC as well and they use the same type of prevention scheme.

There are some alternative implementations of CSRF protection in ASP.NET Web forms like changing how ViewState is generated or by using Session State but we did not want to take an dependency on those features, you choose what scheme fits your requirements.

Le me know if you have any questions.