From 6ccb2111b459fd47c093c3b2c5ea274a2fe52d0e Mon Sep 17 00:00:00 2001 From: Igor Velikorossov Date: Thu, 7 Apr 2022 10:08:47 +1000 Subject: [PATCH 1/6] Update known-issues.md Document the problem with Windows Desktop 6.0.2 --- release-notes/6.0/known-issues.md | 43 +++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/release-notes/6.0/known-issues.md b/release-notes/6.0/known-issues.md index c51e94bc80..4f1cc8f8ca 100644 --- a/release-notes/6.0/known-issues.md +++ b/release-notes/6.0/known-issues.md @@ -58,3 +58,46 @@ To fix this, edit your `PATH` environment variable to either remove the `c:\Prog The first time SPA apps are run, the authority for the spa proxy might be incorrectly cached which results in the JWT bearer being rejected due to Invalid issuer. The workaround is to just restart the SPA app and the issue will be resolved. If restarting doesn't resolve the problem, another workaround is to specify the authority for your app in Program.cs: `builder.Services.Configure("IdentityServerJwtBearer", o => o.Authority = "https://localhost:44416");` where 44416 is the port for the spa proxy. When using localdb (default when creating projects in VS), the normal database apply migrations error page will not be displayed correctly due to the spa proxy. This will result in errors when going to the fetch data page. Apply the migrations via 'dotnet ef database update' to create the database. + +## Windows Desktop (Windows Forms / WPF) + +### Issues running applications with Windows Desktop 6.0.2 + +Some customers are unable to run Windows Desktop (that is, Windows Forms or WPF) applications built against 6.0.2 won't run, if either .NET Windows Desktop runtime 6.0.0 or 6.0.1 are installed, and receieve error messages similar to the following: +``` +Application: WinFormsApp1.exe +CoreCLR Version: 6.0.121.56705 +.NET Version: 6.0.1 +Description: The process was terminated due to an unhandled exception. +Exception Info: System.IO.FileLoadException: Could not load file or assembly 'System.Windows.Forms, Version=6.0.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The located assembly's manifest definition does not match the assembly reference. (0x80131040) +File name: 'System.Windows.Forms, Version=6.0.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' + at WinFormsApp1.Program.Main() +``` + +This is a result of Windows Desktop servicing ref packs in 6.0.2, which was shipped with an incorrect version. + +**Fix:** +* To run Windows Desktop applications built against 6.0.0 or 6.0.1, the Windows Desktop runtime either 6.0.0 or 6.0.1 must be installed. +* To run Windows Desktop applications built against 6.0.2 or later, the Windows Desktop 6.0.2 or later is required. + +The team appreciates that the fix is less than ideal, however it was chosen for the following reasons. +* If the ref pack version number was reverted to 6.0.0, then all DLLs built against the 6.0.2 reference assemblies would be broken. Those projects/libraries would have no other workaround besides rebuilding, which would mean that any NuGet packages published would be irreversibly broken and would need to be updated. +* If we lock the ref pack version number at 6.0.2, there is a workaround that lets allows building an app or library that can run on 6.0.0 or 6.0.1 - for the end-user it requires installing Windows Desktop runtime 6.0.0 or 6.0.1, and for a developer either locking the SDK in global.json: + ```json + { + "sdk": { + "version": "6.0.101", + "rollForward": "disable" + } + } + ``` + ...or locking the runtime at the project level: + ```xml + + + + ``` +* Additionally 6.0.1 and 6.0.2 are security releases, and customers are encouraged to update to the latest version. + From 5f33cd1c52e1e27a26e36da8da2f5ead05ec5e4f Mon Sep 17 00:00:00 2001 From: Igor Velikorossov Date: Fri, 8 Apr 2022 12:23:40 +1000 Subject: [PATCH 2/6] Update known-issues.md Feedback --- release-notes/6.0/known-issues.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/release-notes/6.0/known-issues.md b/release-notes/6.0/known-issues.md index 4f1cc8f8ca..6d7faa994f 100644 --- a/release-notes/6.0/known-issues.md +++ b/release-notes/6.0/known-issues.md @@ -63,7 +63,7 @@ When using localdb (default when creating projects in VS), the normal database a ### Issues running applications with Windows Desktop 6.0.2 -Some customers are unable to run Windows Desktop (that is, Windows Forms or WPF) applications built against 6.0.2 won't run, if either .NET Windows Desktop runtime 6.0.0 or 6.0.1 are installed, and receieve error messages similar to the following: +Some customers are unable to run Windows Desktop (that is, Windows Forms or WPF) applications built with 6.0.200 or later .NET SDK, if the target workstation has only .NET Windows Desktop runtime 6.0.0 or 6.0.1 installed, and receieve error messages similar to the following: ``` Application: WinFormsApp1.exe CoreCLR Version: 6.0.121.56705 @@ -74,19 +74,18 @@ File name: 'System.Windows.Forms, Version=6.0.2.0, Culture=neutral, PublicKeyTok at WinFormsApp1.Program.Main() ``` -This is a result of Windows Desktop servicing ref packs in 6.0.2, which was shipped with an incorrect version. +This is a result of Windows Desktop servicing ref pack in 6.0.2, which was shipped with an incorrect version. **Fix:** -* To run Windows Desktop applications built against 6.0.0 or 6.0.1, the Windows Desktop runtime either 6.0.0 or 6.0.1 must be installed. -* To run Windows Desktop applications built against 6.0.2 or later, the Windows Desktop 6.0.2 or later is required. +* To run Windows Desktop applications built with 6.0.200 or later .NET SDK, the Windows Desktop runtime 6.0.2 or later is required. The team appreciates that the fix is less than ideal, however it was chosen for the following reasons. -* If the ref pack version number was reverted to 6.0.0, then all DLLs built against the 6.0.2 reference assemblies would be broken. Those projects/libraries would have no other workaround besides rebuilding, which would mean that any NuGet packages published would be irreversibly broken and would need to be updated. +* If the ref pack version number was reverted to 6.0.0, then all DLLs built with 6.0.2 reference assemblies would be broken. Those projects/libraries would have no other workaround besides rebuilding, which would mean that any NuGet packages published would be irreversibly broken and would need to be updated. * If we lock the ref pack version number at 6.0.2, there is a workaround that lets allows building an app or library that can run on 6.0.0 or 6.0.1 - for the end-user it requires installing Windows Desktop runtime 6.0.0 or 6.0.1, and for a developer either locking the SDK in global.json: ```json { "sdk": { - "version": "6.0.101", + "version": "6.0.100", "rollForward": "disable" } } From 85adc3b984bccea60f4e9fa5ae9a04b201ecba2d Mon Sep 17 00:00:00 2001 From: Igor Velikorossov Date: Tue, 26 Apr 2022 14:40:02 +1000 Subject: [PATCH 3/6] Update release-notes/6.0/known-issues.md Co-authored-by: Daniel Plaisted --- release-notes/6.0/known-issues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release-notes/6.0/known-issues.md b/release-notes/6.0/known-issues.md index 6d7faa994f..ee22d79570 100644 --- a/release-notes/6.0/known-issues.md +++ b/release-notes/6.0/known-issues.md @@ -81,7 +81,7 @@ This is a result of Windows Desktop servicing ref pack in 6.0.2, which was shipp The team appreciates that the fix is less than ideal, however it was chosen for the following reasons. * If the ref pack version number was reverted to 6.0.0, then all DLLs built with 6.0.2 reference assemblies would be broken. Those projects/libraries would have no other workaround besides rebuilding, which would mean that any NuGet packages published would be irreversibly broken and would need to be updated. -* If we lock the ref pack version number at 6.0.2, there is a workaround that lets allows building an app or library that can run on 6.0.0 or 6.0.1 - for the end-user it requires installing Windows Desktop runtime 6.0.0 or 6.0.1, and for a developer either locking the SDK in global.json: +* If we lock the ref pack version number at 6.0.2, there is a workaround that allows building an app or library that can run on 6.0.0 or 6.0.1 - for the end-user it requires installing Windows Desktop runtime 6.0.0 or 6.0.1, and for a developer either locking the SDK in global.json: ```json { "sdk": { From a6b52e4851515b791cc6c449d2ccb82d46e280bd Mon Sep 17 00:00:00 2001 From: Igor Velikorossov Date: Tue, 26 Apr 2022 14:41:58 +1000 Subject: [PATCH 4/6] Update release-notes/6.0/known-issues.md --- release-notes/6.0/known-issues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release-notes/6.0/known-issues.md b/release-notes/6.0/known-issues.md index ee22d79570..422b4a34d2 100644 --- a/release-notes/6.0/known-issues.md +++ b/release-notes/6.0/known-issues.md @@ -92,7 +92,7 @@ The team appreciates that the fix is less than ideal, however it was chosen for ``` ...or locking the runtime at the project level: ```xml - + From 348e60e3a88d335593bcab086658c9d0681b103a Mon Sep 17 00:00:00 2001 From: Igor Velikorossov Date: Tue, 26 Apr 2022 14:44:19 +1000 Subject: [PATCH 5/6] Update release-notes/6.0/known-issues.md --- release-notes/6.0/known-issues.md | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/release-notes/6.0/known-issues.md b/release-notes/6.0/known-issues.md index 422b4a34d2..6b5ff6048f 100644 --- a/release-notes/6.0/known-issues.md +++ b/release-notes/6.0/known-issues.md @@ -81,16 +81,7 @@ This is a result of Windows Desktop servicing ref pack in 6.0.2, which was shipp The team appreciates that the fix is less than ideal, however it was chosen for the following reasons. * If the ref pack version number was reverted to 6.0.0, then all DLLs built with 6.0.2 reference assemblies would be broken. Those projects/libraries would have no other workaround besides rebuilding, which would mean that any NuGet packages published would be irreversibly broken and would need to be updated. -* If we lock the ref pack version number at 6.0.2, there is a workaround that allows building an app or library that can run on 6.0.0 or 6.0.1 - for the end-user it requires installing Windows Desktop runtime 6.0.0 or 6.0.1, and for a developer either locking the SDK in global.json: - ```json - { - "sdk": { - "version": "6.0.100", - "rollForward": "disable" - } - } - ``` - ...or locking the runtime at the project level: +* If we lock the ref pack version number at 6.0.2, there is a workaround that allows building an app or library that can run on 6.0.0 or 6.0.1 - for an end-user it requires installing Windows Desktop runtime 6.0.0 or 6.0.1, and for a developer - locking the runtime at the project level: ```xml Date: Tue, 26 Apr 2022 14:44:59 +1000 Subject: [PATCH 6/6] Update release-notes/6.0/known-issues.md Co-authored-by: Daniel Plaisted --- release-notes/6.0/known-issues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release-notes/6.0/known-issues.md b/release-notes/6.0/known-issues.md index 6b5ff6048f..0264f6a80f 100644 --- a/release-notes/6.0/known-issues.md +++ b/release-notes/6.0/known-issues.md @@ -63,7 +63,7 @@ When using localdb (default when creating projects in VS), the normal database a ### Issues running applications with Windows Desktop 6.0.2 -Some customers are unable to run Windows Desktop (that is, Windows Forms or WPF) applications built with 6.0.200 or later .NET SDK, if the target workstation has only .NET Windows Desktop runtime 6.0.0 or 6.0.1 installed, and receieve error messages similar to the following: +Some customers are unable to run Windows Desktop (that is, Windows Forms or WPF) applications built with 6.0.200 or later .NET SDK, if the target environment has only .NET Windows Desktop runtime 6.0.0 or 6.0.1 installed, and receive error messages similar to the following: ``` Application: WinFormsApp1.exe CoreCLR Version: 6.0.121.56705