Fix cross-references to moved metadata and hosting APIs

Copilot · gewarren · Copilot · commit cf91c30d76fc · 2025-06-26T09:39:46.000Z
Co-authored-by: gewarren &lt;24882762+gewarren@users.noreply.github.com&gt;
diff --git a/docs/fundamentals/reflection/emitting-dynamic-methods-and-assemblies.md b/docs/fundamentals/reflection/emitting-dynamic-methods-and-assemblies.md
@@ -22,7 +22,7 @@ Reflection emit provides the following capabilities:
 - Define types in modules at run time, create instances of these types, and invoke their methods.
 - Define symbolic information for defined modules that can be used by tools such as debuggers and code profilers.
 
-In addition to the managed types in the <xref:System.Reflection.Emit> namespace, there are unmanaged metadata interfaces that are described in the [Metadata Interfaces](../../framework/unmanaged-api/metadata/metadata-interfaces.md) reference documentation. Managed reflection emit provides stronger semantic error checking and a higher level of abstraction of the metadata than the unmanaged metadata interfaces.
+In addition to the managed types in the <xref:System.Reflection.Emit> namespace, there are unmanaged metadata interfaces that are described in the [Metadata Interfaces](../../core/unmanaged-api/metadata/metadata-interfaces.md) reference documentation. Managed reflection emit provides stronger semantic error checking and a higher level of abstraction of the metadata than the unmanaged metadata interfaces.
 
 Another useful resource for working with metadata and CIL is the Common Language Infrastructure (CLI) documentation, especially "Partition II: Metadata Definition and Semantics" and "Partition III: CIL Instruction Set". The documentation is available online at the [Ecma Web site](https://www.ecma-international.org/publications-and-standards/standards/ecma-335/).
 
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](../../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.
+    > 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.
 
 - 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/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](../../framework/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](../../core/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](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentcputime-method.md) method.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentCpuTime](../../core/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](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentallocated-method.md) method.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentAllocated](../../core/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](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentsurvived-method.md) method, `pAppDomainBytesSurvived` parameter.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentSurvived](../../core/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](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-getcurrentsurvived-method.md) method, `pTotalBytesSurvived` parameter.
+  - Hosting API: [ICLRAppDomainResourceMonitor::GetCurrentSurvived](../../core/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](../../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.
+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.
 
 ## See also
 
 - <xref:System.AppDomain.MonitoringIsEnabled%2A?displayProperty=nameWithType>
-- [ICLRAppDomainResourceMonitor Interface](../../framework/unmanaged-api/hosting/iclrappdomainresourcemonitor-interface.md)
+- [ICLRAppDomainResourceMonitor Interface](../../core/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](../../framework/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](../../core/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](../../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.  
+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.  
   
 ## 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`](../../framework/unmanaged-api/hosting/icorthreadpool-corsetmaxthreads-method.md) method.  
+> Code that hosts the common language runtime can set the size using the [`ICorThreadpool::CorSetMaxThreads`](../../core/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`](../../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.
+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.
 
 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.  
 
