Upgrade to Oqtane 10 Issue with ContactForm module

[JoeAucoin]

I have a multi-tenant (5 databases) Oqtane 6.2.1 site on Azure and I wanted to prepare for an Oqtane 10.1 upgrade so I started by updating the .Net version from .Net 9 to .Net 10. That went fine. Site came back up running on .Net 10 . . . A couple hours later I FTP uploaded the Oqtane.Framework.10.0.1.Upgrade files and the upgrade failed. All I get is:

HTTP Error 500.30 - ASP.NET Core app failed to start
Common solutions to this issue:
The app failed to start
The app started but then stopped
The app started but threw an exception during startup
Troubleshooting steps:
Check the system event log for error messages
Enable logging the application process' stdout messages
Attach a debugger to the application process and inspect
For more guidance on diagnosing and handling these errors, visit Troubleshoot ASP.NET Core on Azure App Service and IIS.

I've tried restoring to .Net 9 and using backup files from the site, but it will no longer come up.

Site settings are:
Render Mode: Static
Interactivity: Server

Any suggestions?

[JoeAucoin]

Turned out to be an issue with TenantId being removed from the Site table . . . .

[2025-12-16 15:15:19+00:00] [Error] [Oqtane.Infrastructure.UpgradeManager] Oqtane Error: Error In 2.0.2 Upgrade Logic - Microsoft.Data.SqlClient.SqlException (0x80131904): Invalid column name 'TenantId'.

Restored back to 6.2.1

Thanks for the help @markdav-is

[sbwalker]

@JoeAucoin the only time the Upgrade_2_0_2() method should be called is if you have a tenant in your environment which has an Oqtane version that is < 2.0.2. I am curious how this could be possible as you said you were running Oqtane 6.2.1 - which means that all of the tenants that are part of your installation should be version 6.2.1. The tenant version is stored in the Tenant table in the Master database:

[sbwalker]

@JoeAucoin I think what you are saying is that after you experienced difficulty upgrading to Oqtane 10.0.1, you restored the Oqtane 6.2.1 installation - however the database migrations for Oqtane 10.0.1 had already been executed - which meant that the TenantId had been removed from the Site table.

Oqtane 6.2.1 expects that the TenantId is in the Site table, which resulted in some unpredictable behavior/errors because the database no longer matched the framework code. When rolling back a failed installation you need to either restore the database backup, or revert any migrations which were applied to the database. Note that there were a number of migrations between 6.2.1 and 10.0.1:

10000001_AddAspNetUserPasskeys.cs - added a new table
10000002_AddAspNetUserTokens.cs - added a new table
10000101_AddSiteEnhancedNavigation.cs - added a column to Site table
10000102_RemoveSiteTenantId.cs - removed index and removed column from Site table

all which need to be reverted

[JoeAucoin]

@sbwalker that is correct . . . all tenants were 6.2.1

[sbwalker]

@JoeAucoin Note that I also experienced an issue on one of my Oqtane installations when upgrading from Oqtane 6.2.1 to Oqtane 10. The site would not start and the error was:

HTTP Error 500.30 - ASP.NET Core app failed to start

When I looked at the /Content/Log/error.log file (where startup errors are logged) I saw:

[2025-12-16 16:34:07+00:00] [Error] [Oqtane.Infrastructure.DatabaseManager] An Error Occurred Installing Contact Form - ServerManagerType OqtaneLabs.ContactForm.Manager.ContactFormManager, OqtaneLabs.ContactForm.Server.Oqtane Does Not Exist

Basically the ContactForm module had a ServerManagerType defined in the ModuleInfo.cs but did not have a corresponding class defined in the project. Prior to Oqtane 10 this error was being suppressed, however in Oqtane 10 logic was added to log it to the error.log. However, the DatabaseManager also contained logic to prevent the framework from starting up if any errors occurred during module migrations. This resulted in the 500.30 error.

The quick fix was to delete the ContactForm module from the /bin folder. This allowed the framework to startup successfully.

A PR (#5892) was added to address the behavior in the next release (10.0.2) - essentially logging module migration errors but not preventing the framework from starting up.

A new version of the ContactForm module will be released today (which removes the invalid ServerManagerType specification). This will allow users to upgrade the ContactForm module before upgrading to Oqtane 10.

Is it possible that this may have been the problem you encountered in your upgrade?

[sbwalker]

@JoeAucoin I am glad my note about the ContactForm module was helpful. In regards to the database question I am not sure what you are trying to accomplish so I can't say it is "safe" or not. Basically the Oqtane Tenant table in the Master database contains a DBConnectionString column. This column contains the Name of the connection string in the appsettings.json which should be used with that Tenant. Connection strings specify the server, database name, etc... and there is no restriction on naming.

[sbwalker]

I am going to change the title of this thread so that it is more helpful to others who may encounter this upgrade issue.

[W6HBR]

Thanks for the notes on this. I've been struggling with this issue of a failing upgrade as some of my modules don't have database managers - they use data from other modules. Is there any way to configure ModuleInfo.cs to say that the module doesn't have any associated DatabaseManager for it?

[sbwalker]

@W6HBR simply remove the ServerManagerType property:

        public ModuleDefinition ModuleDefinition => new ModuleDefinition
        {
            Name = "Contact Form",
            Description = "Contact Form",
            Version = "6.1.3",
            Dependencies = "OqtaneLabs.ContactForm.Shared.Oqtane",
            SettingsType = "OqtaneLabs.ContactForm.Settings, OqtaneLabs.ContactForm.Client.Oqtane",
            PackageName = "OqtaneLabs.ContactForm"
        };

[W6HBR]

Awesome, that worked. I had originally built the modules using the templates and after removing the controller, manager, etc. never thought about needing to remove the ServerManagerType reference in the ModuleDefinition file.

[JoeAucoin]

@sbwalker I've restored all the databases on this install and removed the ContactForm module. All the OqtaneLabs.ContactForm dll's are now deleted. Everything seems to be up and running fine.

[sbwalker]

I am glad I was able to help

[sbwalker]

Version 6.1.3 of the ContactForm module has been released