-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When upgrading .NET versions(6.x), apps get "stuck" #23857
Comments
|
@NXTwoThou , is this specific to WinForms applications? Did you try others like WPF or console apps? |
We have two winform apps we wrote that live in the system tray. 6 that are regular windowed. I'm reporting what happened to our apps during an upgrade from .NET 6.0.1 to 6.0.2. There are no WPF nor console apps that stay running on any of these machines. |
|
This is repo contains Windows Forms runtime, i.e. the code that makes your apps run. Moving to the SDK, maybe they can help. |
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
As mentioned in the original post, only put it here due to Kirsan asking me to do so. :P |
|
@NikolaMilosavljevic Any idea why the applications aren't being shut down correctly during .net upgrade? Is this restart manager that handles this? |
All good. @kirsan31 is doing a great job helping the community and the team. |
This comment was marked as off-topic.
This comment was marked as off-topic.
.NET v6.0.1 was installed, running several winform applications. Ran .NET v6.0.2 installer to upgrade, apps disappeared from the task bar and system tray. .NET v6.0.2 installer completed successfully. Attempted to start back up one of the applications to find that it was already running. Checked task manager to find that all of the winform applications were still listed under Details, but not visible on the task bar or system tray. What I referred to as "stuck". Had to kill the processes via task manager so I could relaunch them. This did not happen with any of the .NET v3.x nor v5.x upgrades. Our winform applications were shut down during the upgrade process and once upgrade completed, we relaunched them. This is in contrast to how .NET Framework upgrades happened where no manual restart of applications was necessary as they never shut down. |
|
FYI, same thing happens with 6.0.3. Had several WinForm apps running. Ran windowsdesktop-runtime-6.0.3-win-x64. Apps disappeared from task bar and system tray. windowsdesktop-runtime-6.0.3-win-x64 completed and if I look in task manager, the apps that disappeared from the task bar and system tray show as still running. I have to end task each of them to relaunch. |
|
And 6.0.4. |
Previously, with .NET Desktop Runtime updates(v3.x, v5.x), when you run the installer the apps would shut down and when the installer completed, you would then need to start back up anything you had running. This is compared to the .NET Framework updates where apps did not close at all and continued to run.
Starting with .NET v6.x, when you run the Desktop Runtime installer, the apps disappear from the taskbar and system tray as with previous installs. When complete however, I try and start back up the apps but find out that they are actually running(just don't appear in the taskbar/tray). To get them working again I have to kill the processes in task manager and restart them.
Best possible case is if something was running before the upgrade, it should be started back up fully. Minimal case is completely shutting down any running .NET applications during the upgrade process so they can be properly started back up.
I noticed this with the 6.0.1 upgrade. It happened again with the 6.0.2 upgrade yesterday. This happened on the 3 Server 2016 machines that I have .NET WinForm apps running on(one machine has 6 winform apps that show in the taskbar, the other two machines have a tray icon each and a taskbar). I mentioned it on https://devblogs.microsoft.com/dotnet/december-2021-updates/#comment-14470 and someone replied that I should have used a different link to download. So I blew it off assuming it was an installer bug that had been immediately fixed and I just picked up the installer too early. I mentioned it again yesterday https://devblogs.microsoft.com/dotnet/february-2022-updates/#comment-14730 and was suggested I do a report here.
Note, this was not an issue with v3.x nor v5.x upgrades. It's a downgrade from how .NET Framework handled things, but after the first few times, we created batch files so we could quickly relaunch everything we needed.
The text was updated successfully, but these errors were encountered: