fix AOT linker warnings

[thomhurst]

Fixes #2458

[claude]

Claude finished @thomhurst's task —— View job

---

Code Review Complete ✅

Todo List:

• Read and analyze all 5 changed files
• Review the new PublishNugetTesterAOTModule.cs pipeline module
• Check project file modifications for consistency and correctness
• Assess AOT/trimming compatibility alignment
• Provide comprehensive code review feedback

---

Code Review Feedback

🟢 Overall Assessment

This PR effectively addresses AOT linker warnings by adding proper AOT publishing configuration to the NuGet tester projects. The implementation follows TUnit's AOT/trimming compatibility guidelines and uses appropriate MSBuild conditions.

📁 File Analysis

PublishNugetTesterAOTModule.cs - New Pipeline Module

• Good: Proper dependency injection with [DependsOn] attributes
• Good: Skips execution on .NET Framework (line 21) - AOT is not available there
• Good: Tests both net8.0 and net9.0 frameworks (line 36)
• Good: Uses proper runtime identifier detection (lines 61-79)
• Issue: Hard-coded architecture assumption for macOS (line 75) - uses osx-arm64 but Intel Macs would need osx-x64
• Good: Comprehensive command logging configuration (line 51)
• Good: Clean async/await pattern with proper cancellation token usage

Project File Modifications - AOT Configuration

All 4 test projects (F#, VB, C#, main) have consistent changes:

• Good: Conditional AOT configuration only for net8.0+ frameworks (line 13 in each)
• Good: Uses IsTargetFrameworkCompatible for proper framework detection
• Good: Sets all three required properties: IsAotCompatible, PublishAot, PublishTrimmed
• Good: Library project correctly excluded from AOT configuration (netstandard2.0 target)

🔍 Detailed Findings

Code Quality: Good

• Modern C# practices with proper async patterns
• Clear separation of concerns in the pipeline module
• Consistent project file modifications across all test projects

Potential Issues

1. macOS Architecture: GetRuntimeIdentifier() assumes ARM64 for macOS, but should detect actual architecture
2. Error Handling: Pipeline module could benefit from better error handling for publish failures
3. Output Directory: Hard-coded output directory names could cause conflicts in parallel builds

Performance Considerations

• Good: Efficient use of SubModule pattern for parallel execution
• Good: Proper framework targeting to avoid unnecessary builds
• Consideration: AOT publishing is inherently slow - this is expected

Security Concerns

• No issues identified: Standard MSBuild properties and .NET CLI usage
• Good: No dynamic code generation or unsafe operations

Test Coverage

• Good: Tests both major AOT-capable frameworks (net8.0, net9.0)
• Good: Tests across multiple language projects (C#, F#, VB)
• Note: This is integration testing - unit tests may not be applicable

💡 Suggestions for Improvement

1. Fix macOS Runtime Detection (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:61-79):

private string GetRuntimeIdentifier()
{
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        return "linux-x64";
    
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
        return "win-x64";
    
    if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
        return RuntimeInformation.ProcessArchitecture == Architecture.Arm64 ? "osx-arm64" : "osx-x64";
    
    throw new ArgumentException("Unknown platform");
}

2. Consider Adding Error Context (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:38-53):
   Add try-catch around publish operations to provide better error context for AOT compilation failures.

✅ Alignment with TUnit Guidelines

• ✅ AOT/Trimming compatibility properly configured
• ✅ Follows modern C# syntax requirements
• ✅ Performance-conscious implementation
• ✅ Consistent with existing pipeline patterns

🎯 Summary

This PR successfully implements AOT testing infrastructure to prevent linker warnings. The code is well-structured and follows TUnit's guidelines. The only minor issue is the macOS architecture detection, but this doesn't affect the core functionality on typical CI environments.

Recommendation: Approve with optional architecture fix

---

[claude]

Claude finished @thomhurst's task —— View job

---

PR Code Review - AOT Linker Warnings Fix

Todo List:

• Read CLAUDE.md for TUnit-specific guidelines
• Analyze all 6 changed files in detail
• Review AOT configuration consistency across projects
• Check pipeline module implementation
• Assess alignment with TUnit dual-mode requirements
• Provide comprehensive code review feedback

---

Code Review Complete ✅

🟢 Overall Assessment

This PR effectively addresses AOT linker warnings by adding proper AOT publishing configuration to the NuGet tester projects and creating automated testing infrastructure. The implementation aligns well with TUnit's AOT/trimming compatibility guidelines and follows the project's performance-first philosophy.

📁 Detailed File Analysis

PublishNugetTesterAOTModule.cs - New Pipeline Module

Code Quality: Good ✅

• Modern C# with proper async/await patterns following TUnit guidelines
• Correct dependency injection using [DependsOn] attributes (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:14-16)
• Proper use of SubModule pattern for parallel execution
• Clean cancellation token propagation

Performance Considerations ⚠️

• AOT publishing is inherently slow but necessary for testing
• Good use of parallel SubModule pattern to avoid blocking
• Hard-coded output directories could cause conflicts in parallel builds

Potential Issues:

1. macOS Architecture Assumption (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:75): Hard-codes osx-arm64 but Intel Macs need osx-x64
2. Error Handling: No try-catch around publish operations - AOT failures could be hard to diagnose
3. Platform Support: Should validate AOT support before attempting publish

Security: ✅ No concerns - standard .NET CLI operations

Project File Modifications - AOT Configuration

All 4 test projects show consistent, well-designed AOT configuration:

TUnit.NugetTester.csproj, .FSharp.fsproj, .VB.vbproj (lines 14-18):

<PropertyGroup Condition="'$(Aot)' == 'true' and $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net8.0'))">
    <IsAotCompatible>true</IsAotCompatible>
    <PublishAot>true</PublishAot>
    <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

Excellent Design Choices ✅:

• Conditional activation only when $(Aot) property is set
• Proper framework compatibility check for net8.0+
• All three required AOT properties configured consistently
• Library project correctly excluded (netstandard2.0 target)

TUnit.NugetTester.Library.csproj: ✅ Correctly excluded from AOT (netstandard2.0 target)

Directory.Packages.props

Good: Minor package version updates, standard maintenance

🎯 TUnit Guidelines Compliance

✅ AOT/Trimming Compatibility: Perfectly aligned - implements testing for AOT scenarios as recommended
✅ Performance First: Adds necessary AOT testing without impacting main execution paths
✅ Modern C# Syntax: Uses proper async patterns, collection expressions where appropriate
✅ Thread Safety: Pipeline module is stateless and thread-safe
✅ Dual-mode Support: This change supports both source-gen and reflection modes equally

💡 Suggested Improvements

1. Fix macOS Runtime Detection (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:61-79):

private string GetRuntimeIdentifier()
{
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        return "linux-x64";
    
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
        return "win-x64";
    
    if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
        return RuntimeInformation.ProcessArchitecture == Architecture.Arm64 ? "osx-arm64" : "osx-x64";
    
    throw new ArgumentException("Unknown platform");
}

2. Add Error Context (Optional):
   Consider wrapping publish operations in try-catch to provide better AOT compilation error diagnostics.

🔍 Bug Risk Assessment

Low Risk ✅:

• Configuration changes are conservative and well-conditioned
• Pipeline module follows established patterns
• No breaking changes to existing functionality
• AOT failures won't affect non-AOT builds

🚀 Performance Impact

Positive ✅:

• Adds AOT testing to catch performance regressions early
• Pipeline runs in parallel, minimizing CI impact
• No runtime performance impact on TUnit itself

🧪 Test Coverage

Excellent ✅:

• Tests AOT publishing across multiple frameworks (net8.0, net9.0)
• Tests multiple language projects (C#, F#, VB)
• Integration testing approach appropriate for AOT scenarios

✅ Summary

This PR successfully implements comprehensive AOT testing infrastructure that will prevent linker warnings and ensure TUnit's AOT compatibility. The code is well-structured, follows TUnit guidelines, and the only minor issue is the macOS architecture detection which doesn't affect typical CI environments.

Recommendation: ✅ Approve - This change strengthens TUnit's AOT compatibility testing with minimal risk and good implementation quality.

---

[claude]

Claude finished @thomhurst's task —— View job

---

PR Code Review - AOT Linker Warnings Fix

Todo List:

• Read CLAUDE.md for TUnit-specific guidelines
• Analyze all 6 changed files in detail
• Review AOT configuration consistency across projects
• Check pipeline module implementation
• Assess alignment with TUnit dual-mode requirements
• Provide comprehensive code review feedback

---

Code Review Complete ✅

🟢 Overall Assessment

This PR effectively addresses AOT linker warnings by adding proper AOT publishing configuration to the NuGet tester projects and creating automated testing infrastructure. The implementation aligns well with TUnit's AOT/trimming compatibility guidelines and follows the project's performance-first philosophy.

📁 Detailed File Analysis

PublishNugetTesterAOTModule.cs - New Pipeline Module

Code Quality: Good ✅

• Modern C# with proper async/await patterns following TUnit guidelines
• Correct dependency injection using [DependsOn] attributes (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:14-16)
• Proper use of SubModule pattern for parallel execution
• Clean cancellation token propagation

Performance Considerations ⚠️

• AOT publishing is inherently slow but necessary for testing
• Good use of parallel SubModule pattern to avoid blocking
• Hard-coded output directories could cause conflicts in parallel builds

Potential Issues:

1. macOS Architecture Assumption (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:75): Hard-codes osx-arm64 but Intel Macs need osx-x64
2. Error Handling: No try-catch around publish operations - AOT failures could be hard to diagnose
3. Platform Support: Should validate AOT support before attempting publish

Security: ✅ No concerns - standard .NET CLI operations

Project File Modifications - AOT Configuration

All 4 test projects show consistent, well-designed AOT configuration:

TUnit.NugetTester.csproj, .FSharp.fsproj, .VB.vbproj (lines 14-18):

<PropertyGroup Condition="'$(Aot)' == 'true' and $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net8.0'))">
    <IsAotCompatible>true</IsAotCompatible>
    <PublishAot>true</PublishAot>
    <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

Excellent Design Choices ✅:

• Conditional activation only when $(Aot) property is set
• Proper framework compatibility check for net8.0+
• All three required AOT properties configured consistently
• Library project correctly excluded (netstandard2.0 target)

Notable Enhancement ✅: Main C# project includes <IlcSingleWarn>false</IlcSingleWarn> (line 18) to disable AOT linker warnings aggregation, directly addressing the issue.

TUnit.NugetTester.Library.csproj: ✅ Correctly excluded from AOT (netstandard2.0 target)

Directory.Packages.props

Good: Minor package version updates, standard maintenance

🎯 TUnit Guidelines Compliance

✅ AOT/Trimming Compatibility: Perfectly aligned - implements testing for AOT scenarios as recommended
✅ Performance First: Adds necessary AOT testing without impacting main execution paths
✅ Modern C# Syntax: Uses proper async patterns, collection expressions where appropriate
✅ Thread Safety: Pipeline module is stateless and thread-safe
✅ Dual-mode Support: This change supports both source-gen and reflection modes equally

💡 Suggested Improvements

1. Fix macOS Runtime Detection (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:61-79):

private string GetRuntimeIdentifier()
{
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        return "linux-x64";
    
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
        return "win-x64";
    
    if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
        return RuntimeInformation.ProcessArchitecture == Architecture.Arm64 ? "osx-arm64" : "osx-x64";
    
    throw new ArgumentException("Unknown platform");
}

2. Add Error Context (Optional):
   Consider wrapping publish operations in try-catch to provide better AOT compilation error diagnostics.

🔍 Bug Risk Assessment

Low Risk ✅:

• Configuration changes are conservative and well-conditioned
• Pipeline module follows established patterns
• No breaking changes to existing functionality
• AOT failures won't affect non-AOT builds

🚀 Performance Impact

Positive ✅:

• Adds AOT testing to catch performance regressions early
• Pipeline runs in parallel, minimizing CI impact
• No runtime performance impact on TUnit itself

🧪 Test Coverage

Excellent ✅:

• Tests AOT publishing across multiple frameworks (net8.0, net9.0)
• Tests multiple language projects (C#, F#, VB)
• Integration testing approach appropriate for AOT scenarios

🛡️ Security Considerations

No Issues ✅:

• Standard MSBuild properties and .NET CLI usage
• No dynamic code generation or unsafe operations
• Follows secure development practices

✅ Summary

This PR successfully implements comprehensive AOT testing infrastructure that will prevent linker warnings and ensure TUnit's AOT compatibility. The code is well-structured, follows TUnit guidelines, and the only minor issue is the macOS architecture detection which doesn't affect typical CI environments.

Recommendation: ✅ Approve - This change strengthens TUnit's AOT compatibility testing with minimal risk and good implementation quality.

---

[claude]

Claude finished @thomhurst's task —— View job

---

PR Code Review - AOT Linker Warnings Fix

Todo List:

• Read CLAUDE.md for TUnit-specific guidelines
• Analyze the new PublishNugetTesterAOTModule.cs pipeline module
• Review AOT attribute usage patterns across changed files
• Check NuGet tester project configurations for AOT
• Assess dual-mode compatibility requirements
• Review public API changes and snapshots
• Evaluate performance and security implications
• Provide comprehensive code review feedback

---

Code Review Complete ✅

🟢 Overall Assessment

This PR comprehensively addresses AOT linker warnings through systematic application of RequiresUnreferencedCode and RequiresDynamicCode attributes across the TUnit codebase. The implementation follows TUnit's dual-mode requirements and includes robust testing infrastructure for AOT scenarios.

📁 Detailed Analysis

PublishNugetTesterAOTModule.cs - New AOT Testing Infrastructure

Code Quality: Good ✅

• Clean async/await patterns following TUnit guidelines (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:24-58)
• Proper dependency injection with [DependsOn] attributes (lines 14-16)
• Effective use of SubModule pattern for parallel execution (line 38)

Potential Issues ⚠️:

1. macOS Architecture Assumption (line 75): Hard-codes osx-arm64 but Intel Macs need osx-x64
2. Platform Support: No validation that AOT is supported before attempting publish
3. Error Handling: No try-catch around publish operations - AOT compilation failures could be hard to diagnose

Suggestion: Consider using RuntimeInformation.ProcessArchitecture to detect actual macOS architecture.

AOT Attribute Application - Systematic Compatibility

Excellent Coverage ✅:

• Consistent application of RequiresUnreferencedCode and RequiresDynamicCode attributes
• Proper conditional compilation with #if NET6_0_OR_GREATER guards
• Meaningful warning messages that guide users toward AOT-compatible alternatives

Example from ClassDataSourceAttribute.cs (lines 29-30):

[RequiresUnreferencedCode("ClassDataSourceAttribute uses reflection to instantiate and access test data classes. For AOT compatibility, use strongly-typed ClassDataSourceAttribute<T> instead.")]
[RequiresDynamicCode("ClassDataSourceAttribute may require runtime type generation. For AOT compatibility, use strongly-typed ClassDataSourceAttribute<T> instead.")]

Best Practice Implementation: Clear guidance toward AOT-compatible alternatives (strongly-typed versions).

NuGet Tester Project Configurations - AOT Setup

Excellent Design ✅ (TUnit.NugetTester.csproj:14-19):

<PropertyGroup Condition="'$(Aot)' == 'true' and $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net8.0'))">
    <IsAotCompatible>true</IsAotCompatible>
    <PublishAot>true</PublishAot>
    <PublishTrimmed>true</PublishTrimmed>
    <IlcSingleWarn>false</IlcSingleWarn>
</PropertyGroup>

Key Strengths:

• Conditional activation only when $(Aot) property is set
• Framework compatibility check for net8.0+
• All required AOT properties configured
• IlcSingleWarn>false disables warning aggregation - directly addresses the issue

Engine Reflection Mode - Dual Compatibility

Good Coverage ✅ (TUnit.Engine/Discovery/ReflectionTestDataCollector.cs:47-48):

• Proper attribute application on reflection-heavy methods
• Maintains dual-mode compatibility as required by TUnit guidelines
• Performance optimizations with caching (lines 17-24)

🎯 TUnit Guidelines Compliance

✅ Dual-mode Support: Changes work identically in both source-generated and reflection modes
✅ Performance Focus: No performance regression - actually improves AOT scenarios
✅ Modern C# Practices: Consistent use of modern syntax and patterns
✅ AOT/Trimming Compatibility: Comprehensive attribute coverage with clear guidance
✅ Snapshot Tests: Public API snapshots properly updated (TUnit.PublicAPI/*.verified.txt)

🔍 Specific Technical Findings

Code Quality: Excellent

• Systematic attribute application across 97 files
• Consistent patterns and messaging
• Proper conditional compilation for framework targeting
• Clean separation between AOT-compatible and reflection-based implementations

Security: No Issues ✅

• Standard .NET AOT attributes with no security implications
• No dynamic code generation or unsafe operations introduced
• Follows secure development practices

Performance: Positive Impact ✅

• Enables AOT compilation for improved startup and runtime performance
• Caching strategies maintained in reflection mode
• No allocations added to hot paths

Test Coverage: Comprehensive ✅

• Tests AOT publishing across multiple frameworks (net8.0, net9.0)
• Tests multiple language projects (C#, F#, VB)
• Integration testing appropriate for AOT scenarios

💡 Minor Suggestions for Improvement

1. Fix macOS Runtime Detection (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:73-76):

if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
    return RuntimeInformation.ProcessArchitecture == Architecture.Arm64 ? "osx-arm64" : "osx-x64";
}

2. Consider Error Context (Optional): Add try-catch around publish operations for better AOT compilation error diagnostics.

3. Validate AOT Support (Optional): Check if the current platform/framework combination supports AOT before attempting publish.

🔄 Impact Assessment

Breaking Changes: None - all attributes are properly conditionally compiled and provide clear migration paths.

Compatibility: Maintains full backward compatibility while enabling AOT scenarios.

Maintenance: Well-structured approach that will be easy to maintain and extend.

✅ Summary

This PR successfully implements comprehensive AOT compatibility for TUnit through:

• Systematic application of AOT-related attributes across the codebase
• Clear guidance toward AOT-compatible alternatives
• Robust testing infrastructure for AOT scenarios
• Proper dual-mode implementation maintaining TUnit's core requirements

The implementation is thorough, well-executed, and follows best practices. The only minor issue is the macOS architecture detection in the pipeline module, which doesn't affect core functionality.

Recommendation: ✅ Approve - This change significantly improves TUnit's AOT compatibility with minimal risk and excellent implementation quality.

---

[claude]

Claude finished @thomhurst's task —— View job

---

PR Code Review - AOT Linker Warnings Fix

Todo List:

• Read CLAUDE.md for TUnit-specific guidelines
• Analyze the new PublishNugetTesterAOTModule.cs pipeline module
• Review AOT attribute usage patterns across changed files
• Check NuGet tester project configurations for AOT
• Assess dual-mode compatibility requirements
• Review public API changes and snapshots
• Evaluate performance and security implications
• Provide comprehensive code review feedback

---

Code Review Complete ✅

🟢 Overall Assessment

This PR comprehensively addresses AOT linker warnings through systematic application of RequiresUnreferencedCode and RequiresDynamicCode attributes across the TUnit codebase. The implementation follows TUnit's dual-mode requirements and includes robust testing infrastructure for AOT scenarios.

📁 Detailed Analysis

PublishNugetTesterAOTModule.cs - New AOT Testing Infrastructure

Code Quality: Good ✅

• Clean async/await patterns following TUnit guidelines (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:24-58)
• Proper dependency injection with [DependsOn] attributes (lines 14-16)
• Effective use of SubModule pattern for parallel execution (line 38)

Potential Issues ⚠️:

1. macOS Architecture Assumption (line 75): Hard-codes osx-arm64 but Intel Macs need osx-x64
2. Platform Support: No validation that AOT is supported before attempting publish
3. Error Handling: No try-catch around publish operations - AOT compilation failures could be hard to diagnose

Suggestion: Consider using RuntimeInformation.ProcessArchitecture to detect actual macOS architecture.

AOT Attribute Application - Systematic Compatibility

Excellent Coverage ✅:

• Consistent application of RequiresUnreferencedCode and RequiresDynamicCode attributes
• Proper conditional compilation with #if NET6_0_OR_GREATER guards
• Meaningful warning messages that guide users toward AOT-compatible alternatives

Example from ClassDataSourceAttribute.cs (lines 29-30):

[RequiresUnreferencedCode("ClassDataSourceAttribute uses reflection to instantiate and access test data classes. For AOT compatibility, use strongly-typed ClassDataSourceAttribute<T> instead.")]
[RequiresDynamicCode("ClassDataSourceAttribute may require runtime type generation. For AOT compatibility, use strongly-typed ClassDataSourceAttribute<T> instead.")]

Best Practice Implementation: Clear guidance toward AOT-compatible alternatives (strongly-typed versions).

NuGet Tester Project Configurations - AOT Setup

Excellent Design ✅ (TUnit.NugetTester.csproj:14-19):

<PropertyGroup Condition="'$(Aot)' == 'true' and $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net8.0'))">
    <IsAotCompatible>true</IsAotCompatible>
    <PublishAot>true</PublishAot>
    <PublishTrimmed>true</PublishTrimmed>
    <IlcSingleWarn>false</IlcSingleWarn>
</PropertyGroup>

Key Strengths:

• Conditional activation only when $(Aot) property is set
• Framework compatibility check for net8.0+
• All required AOT properties configured
• IlcSingleWarn>false disables warning aggregation - directly addresses the issue

Engine Reflection Mode - Dual Compatibility

Good Coverage ✅ (TUnit.Engine/Discovery/ReflectionTestDataCollector.cs:47-48):

• Proper attribute application on reflection-heavy methods
• Maintains dual-mode compatibility as required by TUnit guidelines
• Performance optimizations with caching (lines 17-24)

🎯 TUnit Guidelines Compliance

✅ Dual-mode Support: Changes work identically in both source-generated and reflection modes
✅ Performance Focus: No performance regression - actually improves AOT scenarios
✅ Modern C# Practices: Consistent use of modern syntax and patterns
✅ AOT/Trimming Compatibility: Comprehensive attribute coverage with clear guidance
✅ Snapshot Tests: Public API snapshots properly updated (TUnit.PublicAPI/*.verified.txt)

🔍 Specific Technical Findings

Code Quality: Excellent

• Systematic attribute application across 97 files
• Consistent patterns and messaging
• Proper conditional compilation for framework targeting
• Clean separation between AOT-compatible and reflection-based implementations

Security: No Issues ✅

• Standard .NET AOT attributes with no security implications
• No dynamic code generation or unsafe operations introduced
• Follows secure development practices

Performance: Positive Impact ✅

• Enables AOT compilation for improved startup and runtime performance
• Caching strategies maintained in reflection mode
• No allocations added to hot paths

Test Coverage: Comprehensive ✅

• Tests AOT publishing across multiple frameworks (net8.0, net9.0)
• Tests multiple language projects (C#, F#, VB)
• Integration testing appropriate for AOT scenarios

💡 Minor Suggestions for Improvement

1. Fix macOS Runtime Detection (TUnit.Pipeline/Modules/PublishNugetTesterAOTModule.cs:73-76):

if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
    return RuntimeInformation.ProcessArchitecture == Architecture.Arm64 ? "osx-arm64" : "osx-x64";
}

2. Consider Error Context (Optional): Add try-catch around publish operations for better AOT compilation error diagnostics.

3. Validate AOT Support (Optional): Check if the current platform/framework combination supports AOT before attempting publish.

🔄 Impact Assessment

Breaking Changes: None - all attributes are properly conditionally compiled and provide clear migration paths.

Compatibility: Maintains full backward compatibility while enabling AOT scenarios.

Maintenance: Well-structured approach that will be easy to maintain and extend.

✅ Summary

This PR successfully implements comprehensive AOT compatibility for TUnit through:

• Systematic application of AOT-related attributes across the codebase
• Clear guidance toward AOT-compatible alternatives
• Robust testing infrastructure for AOT scenarios
• Proper dual-mode implementation maintaining TUnit's core requirements

The implementation is thorough, well-executed, and follows best practices. The only minor issue is the macOS architecture detection in the pipeline module, which doesn't affect core functionality.

Recommendation: ✅ Approve - This change significantly improves TUnit's AOT compatibility with minimal risk and excellent implementation quality.

---