Kentico CI store fails on finding content item asset in Azure Storage

2025/09/30 9:41 AM

Doing a Kentico CI store with content item assets in Azure Storage seems to fail. The following error occurs:

[ERR] KenticoCiStore: Message: Serialization of object type "Content item data Legacy media file" (contentitemdata.legacy.mediafile) failed for object "54745082-74da-4059-8fc4-8fe836c786e3" (ContentItemDataID: 374). See inner exception for further details.
[ERR] KenticoCiStore: Exception type: CMS.ContinuousIntegration.ObjectTypeSerializationException
[ERR] KenticoCiStore: Stack trace:
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.FileSystemStoreAllJob.StoreSingleObjectTypeObject(FileSystemStoreJob storeJob, ObjectTypeInfo typeInfo, BaseInfo info, Int32 counter, Int32 total)
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.FileSystemStoreAllJob.StoreAllObjectTypeObjects(String objectType, Int32 counter, Int32 total)
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.AbstractFileSystemJob.CancellableForEach[T](IEnumerable1 collection, Action2 action, CancellationToken cancellationToken)
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.FileSystemStoreAllJob.StoreObjects()
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.FileSystemStoreAllJob.RunInternal(CancellationToken cancellationToken)
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.AbstractFileSystemAllJob.Run(Nullable`1 cancellationToken)
[ERR] KenticoCiStore: Message: Serialization of the object CMS.ContentEngine.Internal.ContentItemDataInfo (contentitemdata.legacy.mediafile) - 54745082-74da-4059-8fc4-8fe836c786e3 has failed.
[ERR] KenticoCiStore: Exception type: CMS.ContinuousIntegration.ObjectSerializationException
[ERR] KenticoCiStore: Stack trace:
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.AbstractSingleObjectJob.Run(BaseInfo baseInfo)
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.FileSystemStoreAllJob.StoreSingleObjectTypeObject(FileSystemStoreJob storeJob, ObjectTypeInfo typeInfo, BaseInfo info, Int32 counter, Int32 total)
[ERR] KenticoCiStore: Message: Path 'assets\contentitems\00\00ddedec-210c-4948-8d44-9ba63b88402c\dfc3d011-8f63-43f6-9ed8-4b444333a1d0\1dc33986-af33-585d-ac61-80d2d3b55210.JPG' does not exist.
[ERR] KenticoCiStore: Exception type: System.IO.FileNotFoundException
[ERR] KenticoCiStore: Stack trace:
[ERR] KenticoCiStore: at Kentico.Xperience.AzureStorage.File.ThrowOnNonexistentFile(String path)
[ERR] KenticoCiStore: at Kentico.Xperience.AzureStorage.File.OpenRead(String path)
[ERR] KenticoCiStore: at CMS.ContentEngine.ContentItemAssetsProcessor.StoreFiles(ContentItemDataInfo contentItemData, RepositoryPathHelper repositoryPathHelper, IFileSystemWriter writer)
[ERR] KenticoCiStore: at CMS.ContentEngine.ContentItemDataFileStoreJob.RunInternal(BaseInfo baseInfo)
[ERR] KenticoCiStore: at CMS.ContinuousIntegration.Internal.AbstractSingleObjectJob.Run(BaseInfo baseInfo)
[ERR] KenticoCiStore: Target KenticoCiStore has thrown an exception

This happens while the file and the path does exist in Azure Storage, the file also works in the CMS (it can be downloaded as well). When I use the files on the file system it does work with the same path.

Has anyone else been successful in doing a Kentico CI store or restore with the files being in an Azure Storage environment?

Environment

  • Xperience by Kentico version: 30.8.2

  • .NET version: 9

  • Execution environment: Locally

Tags:
CI/CD Azure

Answers

2025/09/30 7:16 PM

All of the documentation on CI mentions the "local filesystem". I don't think this is a supported use case for CI.

  1. Are you trying to share files between team members working on the same project? I wouldn't advise that. The CI repository is intended to be a complete snapshot of the data that populates the application, enabling you to branch the database.
  1. Are you trying to avoid a large number of files in the CI repository that would bloat the Git repository? In that case, limit the data you are using for local development, at least on the branches you actively work on. Local is not meant to replicate production.
2025/10/02 9:49 AM
Accepted answer

Yes I'm trying to share the local development environment between developers. I also want to be as close as possible to other environments thus I'm using Azure Storage emulator locally (tho I'm still finding a good solution to share the initial files with other developers).

The problem here was the case sensitivity of Azure storage for file names. After converting all the files to lowercase and then placing them in Azure storage the error was solved. Apparently the Kentico CI restore tries to check if the file exists and throws the error if non existent.

I am still not sure what the best way is to share files between developers, because including them in the git repository causes extra files in commits and that feels unnecessary. But that would be something for another discussion I guess.

2025/10/02 9:12 PM

Good to hear you got it resolved. Azure Storage is case sensitive, which can cause issues if you are manually copying files into any storage environment (emulator or hosted in Azure).

We handle this for you when using our supported APIs, but don't make guarantees otherwise.

Unlike regular file systems (NTFS, VFAT), Azure Blob storage is case-sensitive. To ensure consistent behavior, Xperience automatically converts all file and folder names to lowercase when processing files on Azure storage.

Xperience by Kentico's CI folder is intended to reflect the state of the data of the LOCAL application environment; db schema, content, and files. The files are not separate from the rest of the content - they are a required part of that content - so they are included in the CI repository.

Unless you have thousands and thousands of assets that you are changing regularly, commit diffing and PR review tools are good at helping developers exclude folders from review when needed.

I would recommend not attempting to replicate PROD in your LOCAL environment. It does make sense to re-populate your LOCAL db and assets from PROD on occasion to ensure your feature development and bug fixes work with the content and data marketers are using, but you should still trim down what is used locally to the minimum required, not a complete replication of PROD.

There's an older (but relevant) conversation about this topic already in the Q&A discussions.

To response this discussion, you have to login first.