Update xml/System/AppDomain.xml

Author: gewarren

xml/System/AppDomain.xml

@@ -97,7 +97,7 @@ Application domains, which are represented by <xref:System.AppDomain> objects, h
 - If an assembly is loaded into the default application domain, it cannot be unloaded from memory while the process is running. However, if you open a second application domain to load and execute the assembly, the assembly is unloaded when that application domain is unloaded. Use this technique to minimize the working set of long-running processes that occasionally use large DLLs.
 
  > [!NOTE]
- > On .NET Core and .NET 5+, the <xref:System.AppDomain> implementation is limited by design and does not provide isolation, unloading, or security boundaries. For .NET Core and .NET 5+ versions, there is exactly one <xref:System.AppDomain>. Isolation and unloading are provided through <xref:System.Runtime.Loader.AssemblyLoadContext>. Security boundaries should be provided by process boundaries and appropriate remoting techniques.
+ > On .NET Core and .NET 5+, the <xref:System.AppDomain> implementation is limited by design and does not provide isolation, unloading, or security boundaries. These versions have exactly one <xref:System.AppDomain>. Isolation and unloading are provided through <xref:System.Runtime.Loader.AssemblyLoadContext>. Security boundaries should be provided by process boundaries and appropriate remoting techniques.
 
  Multiple application domains can run in a single process; however, there is not a one-to-one correlation between application domains and threads. Several threads can belong to a single application domain, and while a given thread is not confined to a single application domain, at any given time, a thread executes in a single application domain.