resets for hosting

gewarren · gewarren · commit b9f0e6f5bbb6 · 2025-06-26T20:39:27.000+02:00
diff --git a/docs/core/unmanaged-api/index.md b/docs/core/unmanaged-api/index.md
@@ -9,16 +9,16 @@ This section includes information on unmanaged APIs that can be used by managed-
 
 These articles describe APIs that were introduced in .NET Core 2.0 and later versions, or APIs that can be used with both .NET Framework and .NET. For .NET Framework-specific unmanaged APIs, see [.NET Framework unmanaged API reference](../../framework/unmanaged-api/index.md).
 
-## In This Section
+## In this section
 
-[Debugging](./debugging/index.md)
+[Debugging](./debugging/index.md)\
 Describes the debugging API, which enables a debugger to debug code that runs in the common language runtime (CLR) environment.
 
-[Hosting](./hosting/index.md)
+[Hosting](./hosting/index.md)\
 Describes the hosting API, which enables unmanaged hosts to integrate the CLR into their applications.
 
-[Metadata](./metadata/index.md)
+[Metadata](./metadata/index.md)\
 Describes the metadata API, which enables a client such as a compiler to generate or access a component's metadata without the types being loaded by the CLR.
 
-[Profiling](./profiling/index.md)
+[Profiling](./profiling/index.md)\
 Describes the profiling API, which enables a profiler to monitor a program's execution by the CLR.
diff --git a/docs/framework/unmanaged-api/index.md b/docs/framework/unmanaged-api/index.md
@@ -15,46 +15,43 @@ This section includes information on unmanaged APIs that can be used by managed-
 
 For unmanaged APIs that can be used with both .NET Framework and .NET, see [.NET unmanaged API reference](../../core/unmanaged-api/index.md).
 
-## In This Section
+## In this section
 
- [Common Data Types](common-data-types-unmanaged-api-reference.md)
+ [Common Data Types](common-data-types-unmanaged-api-reference.md)\
  Lists the common data types that are used, particularly in the unmanaged profiling and debugging APIs.
 
- [ALink](./alink/index.md)
+ [ALink](./alink/index.md)\
  Describes the ALink API, which supports the creation of .NET Framework assemblies and unbound modules.
 
- [Authenticode](./authenticode/index.md)
+ [Authenticode](./authenticode/index.md)\
  Supports the Authenticode XrML license creation and verification module.
 
- [Constants](constants-unmanaged-api-reference.md)
+ [Constants](constants-unmanaged-api-reference.md)\
  Describes the constants that are defined in CorSym.idl.
 
- [Custom Interface Attributes](/previous-versions/dotnet/netframework-4.0/ms231946(v=vs.100))
+ [Custom Interface Attributes](/previous-versions/dotnet/netframework-4.0/ms231946(v=vs.100))\
  Describes component object model (COM) custom interface attributes.
 
- [Debugging](./debugging/index.md)
+ [Debugging](./debugging/index.md)\
  Describes the debugging API, which enables a debugger to debug code that runs in the common language runtime (CLR) environment.
 
- [Diagnostics Symbol Store](./diagnostics/index.md)
+ [Diagnostics Symbol Store](./diagnostics/index.md)\
  Describes the diagnostics symbol store API, which enables a compiler to generate symbol information for use by a debugger.
 
- [Fusion](./fusion/index.md)
+ [Fusion](./fusion/index.md)\
  Describes the fusion API, which enables a runtime host to access the properties of an application's resources in order to locate the correct versions of those resources for the application.
 
- [Hosting](../../core/unmanaged-api/hosting/index.md)
- For hosting APIs that can be used with both .NET Framework and .NET, see the .NET unmanaged API reference.
+ [Hosting](./hosting/index.md)\
+ Describes the hosting API, which enables unmanaged hosts to integrate the CLR into their applications.
 
- [Metadata](../../core/unmanaged-api/metadata/index.md)
- For metadata APIs that can be used with both .NET Framework and .NET, see the .NET unmanaged API reference.
-
- [Profiling](./profiling/index.md)
+ [Profiling](./profiling/index.md)\
  Describes the profiling API, which enables a profiler to monitor a program's execution by the CLR.
 
- [Strong Naming](./strong-naming/index.md)
+ [Strong Naming](./strong-naming/index.md)\
  Describes the strong naming API, which enables a client to administer strong name signing for assemblies.
 
- [WMI and Performance Counters](wmi/index.md)
+ [WMI and Performance Counters](wmi/index.md)\
  Describes the APIs that wrap calls to Windows Management Instrumentation (WMI) libraries.
 
- [Tlbexp Helper Functions](./tlbexp/index.md)
+ [Tlbexp Helper Functions](./tlbexp/index.md)\
  Describes the two helper functions and interface used by the Type Library Exporter (Tlbexp.exe) during the assembly-to-type-library conversion process.
diff --git a/docs/framework/unmanaged-api/toc.yml b/docs/framework/unmanaged-api/toc.yml
@@ -1,5 +1,4 @@
 items:
-
 - name: .NET Framework unmanaged API reference
   href: index.md
 - name: Common data types
@@ -37,6 +36,8 @@ items:
   href: diagnostics/
 - name: Fusion
   href: fusion/
+- name: Hosting
+  href: hosting/
 - name: Profiling
   href: profiling/
 - name: Strong naming
diff --git a/docs/framework/wcf/migrating-from-net-remoting-to-wcf.md b/docs/framework/wcf/migrating-from-net-remoting-to-wcf.md
diff --git a/docs/fundamentals/runtime-libraries/system-threading-thread.md b/docs/fundamentals/runtime-libraries/system-threading-thread.md
@@ -124,7 +124,7 @@ You can retrieve a number of property values that provide information about a th
 - A thread ID. The value of the read-only <xref:System.Threading.Thread.ManagedThreadId> property is assigned by the runtime and uniquely identifies a thread within its process.
 
     > [!NOTE]
-    > An operating-system [ThreadId](/windows/win32/api/processthreadsapi/nf-processthreadsapi-getthreadid) has no fixed relationship to a managed thread, because an unmanaged host can control the relationship between managed and unmanaged threads. Specifically, a sophisticated host can use the [CLR Hosting API](../../core/unmanaged-api/hosting/index.md) to schedule many managed threads against the same operating system thread, or to move a managed thread between different operating system threads.
+    > An operating-system [ThreadId](/windows/win32/api/processthreadsapi/nf-processthreadsapi-getthreadid) has no fixed relationship to a managed thread, because an unmanaged host can control the relationship between managed and unmanaged threads. Specifically, a sophisticated host can use the [CLR Hosting API](../../framework/unmanaged-api/hosting/index.md) to schedule many managed threads against the same operating system thread, or to move a managed thread between different operating system threads.
 
 - The thread's current state. For the duration of its existence, a thread is always in one or more of the states defined by the <xref:System.Threading.ThreadState> property.
 
diff --git a/docs/navigate/tools-diagnostics/toc.yml b/docs/navigate/tools-diagnostics/toc.yml
@@ -571,6 +571,8 @@ items:
             href: ../../core/diagnostics/debug-stackoverflow.md
       - name: Unmanaged API reference
         items:
+          - name: Overview
+            href: ../../core/unmanaged-api/index.md
           - name: Debugging
             items:
               - name: Overview
diff --git a/docs/standard/garbage-collection/app-domain-resource-monitoring.md b/docs/standard/garbage-collection/app-domain-resource-monitoring.md
@@ -25,7 +25,7 @@ As soon as ARM is enabled, it begins collecting data on all application domains
 
 - You can enable ARM at CLR startup by adding the [\<appDomainResourceMonitoring>](../../framework/configure-apps/file-schema/runtime/appdomainresourcemonitoring-element.md) element to the configuration file, and setting the `enabled` attribute to `true`. A value of `false` (the default) means only that ARM is not enabled at startup; you can activate it later by using one of the other activation mechanisms.
 
-- The host can enable ARM by requesting the [ICLRAppDomainResourceMonitor](../../core/unmanaged-api/hosting/iclrappdomainresourcemonitor-interface.md) hosting interface. Once this interface is successfully obtained, ARM is enabled.
+- The host can enable ARM by requesting the [ICLRAppDomainResourceMonitor](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-interface.md) hosting interface. Once this interface is successfully obtained, ARM is enabled.
 
 - Managed code can enable ARM by setting the static (`Shared` in Visual Basic) <xref:System.AppDomain.MonitoringIsEnabled%2A?displayProperty=nameWithType> property to `true`. As soon as the property is set, ARM is enabled.
 
@@ -39,31 +39,31 @@ ARM provides the total processor time that is used by an application domain and
 
   - Managed API: <xref:System.AppDomain.MonitoringTotalProcessorTime%2A?displayProperty=nameWithType> property.
 
-  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentCpuTime](../../core/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentcputime-method.md) method.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentCpuTime](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentcputime-method.md) method.
 
   - ETW events: `ThreadCreated`, `ThreadAppDomainEnter`, and `ThreadTerminated` events. For information about providers and keywords, see "AppDomain Resource Monitoring Events" in [CLR ETW Events](../../framework/performance/clr-etw-events.md).
 
 - **Total managed allocations made by an application domain during its lifetime, in bytes**: Total allocations do not always reflect memory use by an application domain, because the allocated objects might be short-lived. However, if an application allocates and frees huge numbers of objects, the cost of the allocations could be significant.
 
   - Managed API: <xref:System.AppDomain.MonitoringTotalAllocatedMemorySize%2A?displayProperty=nameWithType> property.
 
-  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentAllocated](../../core/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentallocated-method.md) method.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentAllocated](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentallocated-method.md) method.
 
   - ETW events: `AppDomainMemAllocated` event, `Allocated` field.
 
 - **Managed memory, in bytes, that is referenced by an application domain and that survived the most recent full, blocking collection**: This number is accurate only after a full, blocking collection. (This is in contrast to concurrent collections, which occur in the background and do not block the application.) For example, the <xref:System.GC.Collect?displayProperty=nameWithType> method overload causes a full, blocking collection.
 
   - Managed API: <xref:System.AppDomain.MonitoringSurvivedMemorySize%2A?displayProperty=nameWithType> property.
 
-  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentSurvived](../../core/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentsurvived-method.md) method, `pAppDomainBytesSurvived` parameter.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentSurvived](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentsurvived-method.md) method, `pAppDomainBytesSurvived` parameter.
 
   - ETW events: `AppDomainMemSurvived` event, `Survived` field.
 
 - **Total managed memory, in bytes, that is referenced by the process and that survived the most recent full, blocking collection**: The survived memory for individual application domains can be compared to this number.
 
   - Managed API: <xref:System.AppDomain.MonitoringSurvivedProcessMemorySize%2A?displayProperty=nameWithType> property.
 
-  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentSurvived](../../core/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentsurvived-method.md) method, `pTotalBytesSurvived` parameter.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentSurvived](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentsurvived-method.md) method, `pTotalBytesSurvived` parameter.
 
   - ETW events: `AppDomainMemSurvived` event, `ProcessSurvived` field.
 
@@ -79,11 +79,11 @@ Alternatively, you can call the <xref:System.GC.CollectionCount%2A?displayProper
 
 #### Hosting API
 
-If you use the unmanaged hosting API, your host must pass the CLR an implementation of the [IHostGCManager](../../core/unmanaged-api/hosting/ihostgcmanager-interface.md) interface. The CLR calls the [IHostGCManager::SuspensionEnding](../../core/unmanaged-api/hosting/ihostgcmanager-suspensionending-method.md) method when it resumes execution of threads that have been suspended while a collection occurs. The CLR passes the generation of the completed collection as a parameter of the method, so the host can determine whether the collection was full or partial. Your implementation of the [IHostGCManager::SuspensionEnding](../../core/unmanaged-api/hosting/ihostgcmanager-suspensionending-method.md) method can query for survived memory, to ensure that the counts are retrieved as soon as they are updated.
+If you use the unmanaged hosting API, your host must pass the CLR an implementation of the [IHostGCManager](../../framework/unmanaged-api/hosting/ihostgcmanager-interface.md) interface. The CLR calls the [IHostGCManager::SuspensionEnding](../../framework/unmanaged-api/hosting/ihostgcmanager-suspensionending-method.md) method when it resumes execution of threads that have been suspended while a collection occurs. The CLR passes the generation of the completed collection as a parameter of the method, so the host can determine whether the collection was full or partial. Your implementation of the [IHostGCManager::SuspensionEnding](../../framework/unmanaged-api/hosting/ihostgcmanager-suspensionending-method.md) method can query for survived memory, to ensure that the counts are retrieved as soon as they are updated.
 
 ## See also
 
 - <xref:System.AppDomain.MonitoringIsEnabled%2A?displayProperty=nameWithType>
-- [ICLRAppDomainResourceMonitor Interface](../../core/unmanaged-api/hosting/iclrappdomainresourcemonitor-interface.md)
+- [ICLRAppDomainResourceMonitor Interface](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-interface.md)
 - [\<appDomainResourceMonitoring>](../../framework/configure-apps/file-schema/runtime/appdomainresourcemonitoring-element.md)
 - [CLR ETW Events](../../framework/performance/clr-etw-events.md)
diff --git a/docs/standard/garbage-collection/performance.md b/docs/standard/garbage-collection/performance.md
@@ -117,7 +117,7 @@ If fragmentation of virtual memory is preventing the garbage collector from addi
 - Holding too many references to COM objects when interoperating with unmanaged code.
 - Creation of large transient objects, which causes the large object heap to allocate and free heap segments frequently.
 
-  When hosting the CLR, an application can request that the garbage collector retain its segments. This reduces the frequency of segment allocations. This is accomplished by using the STARTUP_HOARD_GC_VM flag in the [STARTUP_FLAGS Enumeration](../../core/unmanaged-api/hosting/startup-flags-enumeration.md).
+  When hosting the CLR, an application can request that the garbage collector retain its segments. This reduces the frequency of segment allocations. This is accomplished by using the STARTUP_HOARD_GC_VM flag in the [STARTUP_FLAGS Enumeration](../../framework/unmanaged-api/hosting/startup-flags-enumeration.md).
 
 |Performance checks|
 |------------------------|
diff --git a/docs/standard/threading/exceptions-in-managed-threads.md b/docs/standard/threading/exceptions-in-managed-threads.md
@@ -34,7 +34,7 @@ If these exceptions are unhandled in the main thread, or in threads that entered
   
 ## Host override
 
-An unmanaged host can use the [ICLRPolicyManager](../../core/unmanaged-api/hosting/iclrpolicymanager-interface.md) interface in the Hosting API to override the default unhandled exception policy of the common language runtime. The [ICLRPolicyManager::SetUnhandledExceptionPolicy](../../core/unmanaged-api/hosting/iclrpolicymanager-setunhandledexceptionpolicy-method.md) function is used to set the policy for unhandled exceptions.  
+An unmanaged host can use the [ICLRPolicyManager](../../framework/unmanaged-api/hosting/iclrpolicymanager-interface.md) interface in the Hosting API to override the default unhandled exception policy of the common language runtime. The [ICLRPolicyManager::SetUnhandledExceptionPolicy](../../framework/unmanaged-api/hosting/iclrpolicymanager-setunhandledexceptionpolicy-method.md) function is used to set the policy for unhandled exceptions.  
   
 ## See also
 
diff --git a/docs/standard/threading/the-managed-thread-pool.md b/docs/standard/threading/the-managed-thread-pool.md
@@ -38,7 +38,7 @@ The number of operations that can be queued to the thread pool is limited only b
 You can control the maximum number of threads by using the <xref:System.Threading.ThreadPool.GetMaxThreads%2A?displayProperty=nameWithType> and <xref:System.Threading.ThreadPool.SetMaxThreads%2A?displayProperty=nameWithType> methods.  
 
 > [!NOTE]
-> Code that hosts the common language runtime can set the size using the [`ICorThreadpool::CorSetMaxThreads`](../../core/unmanaged-api/hosting/icorthreadpool-corsetmaxthreads-method.md) method.  
+> Code that hosts the common language runtime can set the size using the [`ICorThreadpool::CorSetMaxThreads`](../../framework/unmanaged-api/hosting/icorthreadpool-corsetmaxthreads-method.md) method.  
   
 ### Thread pool minimums
 
@@ -56,7 +56,7 @@ When a minimum is reached, the thread pool can create additional threads or wait
 
 The easiest way to use the thread pool is to use the [Task Parallel Library (TPL)](../parallel-programming/task-parallel-library-tpl.md). By default, TPL types like <xref:System.Threading.Tasks.Task> and <xref:System.Threading.Tasks.Task%601> use thread pool threads to run tasks.
 
-You can also use the thread pool by calling <xref:System.Threading.ThreadPool.QueueUserWorkItem%2A?displayProperty=nameWithType> from managed code (or [`ICorThreadpool::CorQueueUserWorkItem`](../../core/unmanaged-api/hosting/icorthreadpool-corqueueuserworkitem-method.md) from unmanaged code) and passing a <xref:System.Threading.WaitCallback?displayProperty=nameWithType> delegate representing the method that performs the task.
+You can also use the thread pool by calling <xref:System.Threading.ThreadPool.QueueUserWorkItem%2A?displayProperty=nameWithType> from managed code (or [`ICorThreadpool::CorQueueUserWorkItem`](../../framework/unmanaged-api/hosting/icorthreadpool-corqueueuserworkitem-method.md) from unmanaged code) and passing a <xref:System.Threading.WaitCallback?displayProperty=nameWithType> delegate representing the method that performs the task.
 
 Another way to use the thread pool is to queue work items that are related to a wait operation by using the <xref:System.Threading.ThreadPool.RegisterWaitForSingleObject%2A?displayProperty=nameWithType> method and passing a <xref:System.Threading.WaitHandle?displayProperty=nameWithType> that, when signaled or when timed out, calls the method represented by the <xref:System.Threading.WaitOrTimerCallback?displayProperty=nameWithType> delegate. Thread pool threads are used to invoke callback methods.  
 
