Support for renaming classes for custom properties
Episerver now supports renaming of custom properties without any bad consequences to the database. In this blog post we will look how this works and how to apply this properly to existing solutions.
I'm a strong believer in feature-based structuring of solutions. In my opinion the best way to structure a solution is to make sure to create a solid foundation that all features depend on – and then structure all code related to a feature in folder – regardless if it relates to the model, view, script or style sheet. In theory – you should be able to add, rename or delete a feature folder without any side effects to other code. Episerver supports this model very well with its code first approach. However, there's been a flaw that I've seen that has caused some trouble. Fortunately enough this was fixed in a recent release: Episerver.Cms.Core 1.14.
Issues when renaming a custom property
If you've worked with Episerver, you are used to creating content definitions, like page and block types. A best practice when defining this attribute is to always set a unique GUID value. This ensures that you can rename the class name, or even any part of the namespace of the content type without any side effects. This is due to Episervers start up content type synchronization that will find the right content type in the database based on the GUID and then update the content type to use the updated model type.
However – for custom properties this has not been possible before. While totally custom properties with custom UI or base data type is quite rare these days – defining list properties is rather common. I always try to keep the definitions of the list properties within my feature instead of grouping custom properties in it's own namespace (unless they are shared across features). Before – a rename of a feature or even a project namespace change – has resulted in a database out of sync with the code. When this happens – you need to manually update the database to fix this – which is a hassle that involves several database tables, specifically if the code has been deployed to several environment. Fortunately, enough – this is remedied with the option to now set a GUID for the custom property.
Lets first have a look on how the database is affected of a simple namespace change before the update. I've added a simple list property to a standard Alloy template site:
namespace UIExtensionSamples.Properties
{
[PropertyDefinitionTypePlugIn]
public class PropertyPersonList : PropertyList<Person>
Now let's add a V2 to the namespace to see what happens in the database when we change the namespace:
namespace UIExtensionSamples.Properties.V2
{
[PropertyDefinitionTypePlugIn]
public class PropertyPersonList : PropertyList<Person>
We check the database by executing the following query: select * from tblPropertyDefinitionType where TypeName like '%PropertyPersonList%'
As you can see we now have two definitions for the custom property in the database. Old data is connected to the old type and new data will be connected to the new property type. Notice also the new GUID column with null for both values.
Now let's add a GUID to our property
namespace UIExtensionSamples.Properties.V2
{
[PropertyDefinitionTypePlugIn(GUID = "6331fa43-c1a2-49d2-b63e-486a989b291b")]
public class PropertyPersonList : PropertyList<Person>
We start the site to execute the content and property type synchronization and check the database again:
As you can see - we still have two property definitions - but the last one has been updated with a GUID value. As a final test - let's rename both the class and namespace and check the database again:
The process if you want to start renaming properties
If you have a custom property with a class name or namespace that you want to change – you first need to update to the latest version of Episerver.Cms.Core and make sure to add a GUID to the property definition. Then this code needs to be deployed to all environments to set the property definition in an initial known state including a GUID. Once this is done – you can start renaming the class or namespace, just as with content type definitions.
https://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=CMS-14783