Update Xperience by Kentico projects

2025/05/22 5:25 PM

Hi friends,

We're looking for some clarity and additional functionality around the dotnet run --no-build --kxp-update command.

Execution Logs:
Is there a way to extract or export detailed logs of what is executed when this command runs? Having access to this output would greatly help with troubleshooting and understanding what changes are being applied.

Update Type Parameter:
It would be helpful to have a parameter that allows specifying the type of update to run—e.g., only assets/files, only the database, or both. This would give us more control and flexibility during deployments.

SQL Script Generation:
We’d also appreciate a parameter that enables generating the SQL script for the database updates without executing them. This would allow us to review and run the SQL manually through tools like SQL Server Management Studio.

If any of these capabilities already exist and we’ve missed them, we’d appreciate guidance or documentation references. Otherwise, we believe these additions could be very beneficial for a wide range of scenarios, let us know if we need to submit these features somewhere else, so we can see a clear status of our feedback.

Thanks for your time and support!

Environment

Tags:
v30.5.0 ASP.NET Core SQL

Answers

2025/05/22 6:46 PM
Accepted answer

Execution Logs:
Is there a way to extract or export detailed logs of what is executed when this command runs?

Not at this time. The only logs available are the ones that go to the console when the command is run. If a --verbose flag or some other kind of additional logging would be helpful for your deployment scenarios, give us feedback on the product roadmap.

Update Type Parameter:
It would be helpful to have a parameter that allows specifying the type of update to run

Application updates need to be internally consistent for the application to run predictably. With the way the product is designed today it doesn't make sense to enable only partial data transformations during a hotfix or Refresh. The code expects the data to be in a specific state after an update completes and before the application runs.

SQL Script Generation:
We’d also appreciate a parameter that enables generating the SQL script for the database updates without executing them.

Updates aren't guaranteed to be SQL scripts. They can also include code-driven data transformations. There's no way to export a data migration authored in C# as a SQL migration. So, even if we could export all the SQL code run during an update you'd still potentially be missing some of the behavior.

Additionally, we consider the database structure to be an implementation detail. The .NET APIs are the publish API surface that are tied to our semver versioned releases, not the database.

We know customers and partners work directly with the database when performing more advanced custom queries or when running SQL migration scripts in CI/CD scenarios. But, we do not want to expose these details so much that someone would rely on them.

Otherwise, we believe these additions could be very beneficial for a wide range of scenarios, let us know if we need to submit these features somewhere else, so we can see a clear status of our feedback.

If you could describe these kinds of scenarios (how these enhancements would benefit your team or stakeholders) when you provide feedback on our product roadmap, that would be very helpful!

2025/05/22 7:09 PM

Thank you for the detailed response and for the clarity regarding the current design and limitations.

Regarding the --verbose flag or similar logging capabilities, we believe this is a highly valuable feature that would support many common development and deployment scenarios. While we understand the process for submitting roadmap feedback, we would suggest that this kind of enhancement is broadly beneficial and aligns well with general developer expectations for transparency and traceability—especially in deployment pipelines. In anyways, I just submitted the feedback about the verbose flag on the roadmap (which I actually I cannot see it on the roadmap board).

Providing as much clarity during the upgrade process the better. In the following documentation page, there is not a set of recommendations of the paths we should follow to upgrade Xperience by Kentico projects using best practices, for example, if we are running a project in version 29.0.0, what should be the recommended path? Update to 30.0.0, then 31.0.0, etc. Or should we jump from 29.0.0 to 35.5.x?


Additionally, if we have a project on version 29.0.0 and we need to upgrade it to 35.5.x, how can I tell the dotnet run --no-build --kxp-update command to upgrade to a certain version? Or should I update the Packages within the .csproj file and then execute this command? If yes, we cannot see clear instructions on the documentation page.

Finally, on the documentation you mention this statement: "Create a backup of your Xperience database, project folder and the folder where you store assets (~/assets by default). In case of a failed update, use these backups to restore your environment to its original state to prevent inconsistent data."

So, if the update fails, how can I know what failed? the DB or the assets, or what exactly? We also believe it would be highly beneficial to introduce an automatic rollback mechanism in the event that the update process fails. Right now, without transparency or recovery options, teams are left in an uncertain state when something goes wrong, potentially requiring manual intervention or a full environment restore. An automatic rollback would mitigate the risk of partial updates or inconsistencies and would be a strong step toward more robust deployment workflows.

2025/05/22 10:26 PM

I just submitted the feedback about the verbose flag on the roadmap (which I actually I cannot see it on the roadmap board).

Correct. Feedback is triaged, taxonomized, discussed with the product team and engineers, and then prioritized. You won't see it on the roadmap until we've received enough feedback from a broad spectrum of partners and customers about this product area (ex: deployments, CLI, etc...) and we have committed to deliver improvements.

But, every item on the roadmap starts as feedback, so don't feel discouraged if you don't see your request immediately appear as an item on the roadmap.

there is not a set of recommendations of the paths we should follow to upgrade Xperience by Kentico projects using best practices, for example, if we are running a project in version 29.0.0, what should be the recommended path? Update to 30.0.0, then 31.0.0, etc. Or should we jump from 29.0.0 to 35.5.x?

We do have a support policy page. It explains which versions of Xperience by Kentico are currently supported.

That said, I would recommend updating your Xperience by Kentico project far more frequently than the example you shared. v29.0.0 (from April 2024) is still supported until October 2025, but the longer you wait the more difficult the update will be. A marketing team is also missing out on more than 1 year's worth of features even though they paid for them with their subscription.

My personal recommendation is to be at most 3 Refreshes (3 months) behind for ease of development and getting access to the latest capabilities.

As long as your current version is supported you can upgrade directly to any other supported version. We do not require you apply each intermediate update, so yes you can update from v29.0.0 to v30.5.0 (May 2025). There could be bugs that we haven't identified with an upgrade of that many features (we don't test upgrading from every supported version to every other version), but if you do find a bug in a supported version, we will work to resolve it.

Finally, on the documentation you mention this statement: "Create a backup of your Xperience database, project folder and the folder where you store assets (~/assets by default). In case of a failed update, use these backups to restore your environment to its original state to prevent inconsistent data."

So, if the update fails, how can I know what failed?

The database changes are applied as a transaction, but if you aren't using Xperience by Kentico SaaS we don't control your deployment process. We don't know what you changed, so we recommend you back up your assets, application, and database. Often this is accomplished by using shared (cloud) storage and blue/green deployments.

Additionally, deployments using our Continuous Deployment (CD) feature will make changes to the database. If the changes apply successfully but later you identify that these changes had unintended side-effects in a production environment, there is no way to "roll them back". This is another reason to backup your database and files.

An automatic rollback would mitigate the risk of partial updates or inconsistencies and would be a strong step toward more robust deployment workflows.

Again, we apply the Refresh updates in a transaction so it does rollback when there's a failure. We do not recommend applying Refreshes and CD updates to a live database because of the risk of locks and failures. We are planning a series of features working towards true zero-downtime deployments - if these are important for your team, let us know with feedback.

To response this discussion, you have to login first.