dotnet · meaghanlewis · Mar 2, 2026 · Mar 1, 2026
@@ -312,7 +312,7 @@ public class TestLevelCleanupExample
 > - [MSTEST0021](mstest-analyzers/mstest0021.md) - Prefer Dispose over TestCleanup methods
 > - [MSTEST0022](mstest-analyzers/mstest0022.md) - Prefer TestCleanup over Dispose methods
 >
-> If you have non-MSTest analyzers enabled, such as .NET code analysis rules, you might see [CA1001](/dotnet/fundamentals/code-analysis/quality-rules/ca1001) suggesting that you implement the dispose pattern when your test class owns disposable resources. This is expected behavior and you should follow the analyzer's guidance.
+> If you have non-MSTest analyzers enabled, such as .NET code analysis rules, you might see [CA1001](../../fundamentals/code-analysis/quality-rules/ca1001.md) suggesting that you implement the dispose pattern when your test class owns disposable resources. This is expected behavior and you should follow the analyzer's guidance.
 
 ### Complete test-level order
 

@@ -41,4 +41,4 @@ The transparency of a dynamic method depends on the module it's associated with.
 
 - The transparency of a dynamic method that's associated with a partially trusted assembly depends on how the assembly is loaded. If the assembly is loaded with partial trust (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types and members, including dynamic methods, are treated as transparent. The runtime pays attention to security annotations only if the partial-trust assembly is loaded with full trust (for example, into the default application domain of a desktop application). In that case, the runtime assigns the dynamic method the default transparency for methods according to the assembly's annotations.
 
-For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes).
+For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](../../framework/reflection-and-codedom/security-issues-in-reflection-emit.md). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes).
Original file line number	Diff line number	Diff line change
Expand Up		@@ -41,4 +41,4 @@ The transparency of a dynamic method depends on the module it's associated with.

		- The transparency of a dynamic method that's associated with a partially trusted assembly depends on how the assembly is loaded. If the assembly is loaded with partial trust (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types and members, including dynamic methods, are treated as transparent. The runtime pays attention to security annotations only if the partial-trust assembly is loaded with full trust (for example, into the default application domain of a desktop application). In that case, the runtime assigns the dynamic method the default transparency for methods according to the assembly's annotations.

		For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes).
		For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](../../framework/reflection-and-codedom/security-issues-in-reflection-emit.md). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes).