Merge pull request #7893 from tarekgh/Known6.0Issue

1 files changed, 13 insertions, 6 deletions

diff --git a/release-notes/6.0/known-issues.md b/release-notes/6.0/known-issues.md
index e7223355..5bd25458 100644
--- a/release-notes/6.0/known-issues.md
+++ b/release-notes/6.0/known-issues.md
@@ -19,10 +19,17 @@ The optional workload manifest MSIs in the SDK populate the Language column in t
 #### Workaround
 Running the 6.0.101 SDK bundle (without using MU) results in the context changing to MSIINSTALLCONTEXT_MACHINE, this allows the API call to query the INSTALLEDLANGUAGE to complete and the SDK Wix bundle install succeeds.
 
-Therefore a workaround for this issue is to install the 6.0.101 SDK bundle manually by downloading it from the [.NET download site](https://dotnet.microsoft.com/en-us/download/dotnet/6.0). Once this is successfully installed scanning MU again will result in clearing the previous error. 
+Therefore a workaround for this issue is to install the 6.0.101 SDK bundle manually by downloading it from the [.NET download site](https://dotnet.microsoft.com/en-us/download/dotnet/6.0). Once this is successfully installed scanning MU again will result in clearing the previous error.
 
-As described previously the computer can be secured by installing the VS 17.0.3 update, even if the MU update results in a failure so the MU failure is not a critical factor from a security perspective. Therefore for the case where we expect the VS update to offer and secure the computer we will be making a change to not offer the MU update to those computers to avoid the MU failure. For the case where .NET 6 was installed as a standalone version and VS is not expected to patch the computer we will continue to offer the 6.0.1 update via MU. 
+As described previously the computer can be secured by installing the VS 17.0.3 update, even if the MU update results in a failure so the MU failure is not a critical factor from a security perspective. Therefore for the case where we expect the VS update to offer and secure the computer we will be making a change to not offer the MU update to those computers to avoid the MU failure. For the case where .NET 6 was installed as a standalone version and VS is not expected to patch the computer we will continue to offer the 6.0.1 update via MU.
 
+## Failure when using ICU App-Local feature in .NET 6.0.10
+### Summary
+Applications using the [App-local ICU](https://learn.microsoft.com/en-us/dotnet/core/extensions/globalization-icu#app-local-icu) feature to deploy ICU library binaries with the application binaries can experience throwing unhandled [AccessViolationException](https://learn.microsoft.com/en-us/dotnet/api/system.accessviolationexception?view=net-6.0). The [reported issue](https://github.com/dotnet/runtime/issues/77045) contains more information about this failure.
+
+**Workarounds**
+- If having the ICU app-local feature to use ICU in the .NET 6.0 application when running on OS like `Windows Server 2019`, migration to .NET 7.0 would help as ICU gets loaded in the application without the need to use the app-local feature. .NET 7.0 supports loading ICU by default on `Windows Server 2019`.
+- Use a different .NET version than `6.0.10` like `6.0.9` or `6.0.11` or any later version including .NET `7.0`.
 
 ## .NET SDK
 
@@ -54,7 +61,7 @@ Example rollback file for 6.0.400
   "microsoft.net.workload.emscripten": "6.0.4/6.0.300"
 }
 ```
-   
+
 ## ASP.NET Core
 
 ### SPA template issues with Individual authentication when running in development
@@ -109,7 +116,7 @@ CoreCLR Version: 6.0.121.56705
 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()   
+   at WinFormsApp1.Program.Main()
 ```
 
 This is a result of Windows Desktop servicing ref pack in 6.0.2, which was shipped with an incorrect version.
@@ -151,7 +158,7 @@ This happened because WPF builds in 6.0.7 onwards, only considered source genera
 
 **Fix:**
 * To enable build in Windows Desktop 6.0.7, navigate to the directory containing the `Microsoft.WinFx.targets` file ( `C:\Program Files\dotnet\sdk\6.0.302\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets` )
-* Add the following target in the file : 
+* Add the following target in the file :
     ```xml
 
     <Target Name="RemoveDuplicateAnalyzers" BeforeTargets="CoreCompile">
@@ -160,5 +167,5 @@ This happened because WPF builds in 6.0.7 onwards, only considered source genera
             <Analyzer Remove="@(Analyzer)" />
             <Analyzer Include="@(FilteredAnalyzer)" />
         </ItemGroup>
-    </Target>    
+    </Target>
     ```