Fix AssemblyLoaderGenerator to only emit code for assemblies with physical locations

[Copilot]

The AssemblyLoaderGenerator was generating Assembly.Load() calls for all referenced assemblies, including those without physical files on disk. This could lead to runtime errors when attempting to load assemblies that don't exist as physical files, such as:

• In-memory assemblies during compilation
• Forwarded assemblies that don't have corresponding DLL files
• The current compilation assembly itself (which doesn't exist as a file yet during source generation)

Changes Made

Modified the AssemblyLoaderGenerator to check if an assembly has a physical location before emitting assembly loading code:

1. Added location validation: Introduced HasPhysicalLocation() method that checks if an assembly has a corresponding PortableExecutableReference with a valid file path
2. Updated code generation: Modified WriteAssemblyLoad() to only emit Assembly.Load() calls for assemblies that have physical files
3. Preserved existing filtering: Maintained the existing system assembly filtering logic

Example Impact

Before: Generated code would include problematic entries like:

global::TUnit.Core.SourceRegistrar.RegisterAssembly(() => 
    global::System.Reflection.Assembly.Load("CurrentCompilationAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"));

After: Only generates entries for assemblies with actual physical files:

global::TUnit.Core.SourceRegistrar.RegisterAssembly(() => 
    global::System.Reflection.Assembly.Load("TUnit.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b8d4030011dbd70c"));

The fix follows the same pattern used in ReferencesHelper.cs for filtering assemblies with valid locations, ensuring consistency across the codebase.

Fixes #2726.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.