Is there an existing issue for this?

• I have searched the existing issues

What happened?

When doing a DNN Upgrade using /Install/Install.aspx?mode=upgrade, if a second request to any page of the site is made by anyone, the lock file gets deleted prematurely.

The root cause is that the code in Install.aspx DotNetNuke.Services.Install.Install.UpgradeApplication() that renders the WriteInstallationInProgress() is part of the same try-finally that is supposed to safely create then delete the lock file during installation.

So, what happens is that the first request (that starts the installation) enters the try-finally and runs execution, but then any request to the site gets redirected to UpgradeWizard.aspx initially (from Initialize.cs CheckVersion()) and then to Install.aspx by the IsInstallInProgress() check on the first line of UpgradeWizard.OnLoad(). These requests then enter the same try-finally to render the WriteInstallationInProgress() and then immediately returns, but due to the fact that they are in the try-finally, the finally block gets executed for them as well, which immediately removes the lock file during installation.

Steps to reproduce?

1. Unzip a DNN Upgrade package over the site files.
2. Access /Install/Install.aspx?mode=upgrade (I think it can in fact be anything other than mode=none)
3. The lock file is created and Installation begins.
4. During installation make a request to anything on the site (e.g. Home page)
5. That request will get redirected to UpgradeWizard.aspx and then to Install.aspx by the IsInstallInProgress() check on the first line of UpgradeWizard.OnLoad() which will then fall through to render the WriteInstallationInProgress() and short circuit return, but not before also executing the finally block that removes the file.
6. The Installation continues after that without a lock file.

Current Behavior

No response

Expected Behavior

Lock file should be present for the entire Upgrade process.

Relevant log output

Anything else?

No response

Affected Versions

10.1.2 (latest v10 release)

What browsers are you seeing the problem on?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct