Handle empty Assembly.Location on Android CoreCLR

[nohwnd]

Assembly.Location is empty on Android CoreCLR (assemblies are memory-mapped), which makes AreValidSources throw NotSupportedException because empty string is neither .dll nor .exe.

Fall back to <AssemblyName>.dll when Location is empty. Works on .NET Core because FileOperations.DoesFileExist always returns true there, and FileOperations.LoadAssembly loads by name, not by path — so the already-loaded assembly is found.

Added tests for empty / null Location, null name, a real dynamic in-memory assembly, and a file-backed one.

Fixes #7769

[Copilot]

Pull request overview

This PR addresses a runtime-specific issue in the VSTest bridge where Assembly.Location can be an empty string (notably on Android CoreCLR with memory-mapped assemblies), which previously caused MSTest discovery/execution to fail due to source extension validation.

Changes:

• Updated VSTest bridge assembly source collection to use a helper that tolerates empty Assembly.Location.
• Added GetAssemblyPath(Assembly) fallback logic to synthesize a “.dll” path from the assembly name when Location is empty.
• Added unit tests covering non-empty, empty, null Location, missing assembly name, dynamic in-memory assemblies, and real file-backed assemblies.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Platform/Microsoft.Testing.Extensions.VSTestBridge/SynchronizedSingleSessionVSTestAndTestAnywhereAdapter.cs	Uses GetAssemblyPath instead of Assembly.Location directly, and introduces the fallback helper.
test/UnitTests/Microsoft.Testing.Extensions.VSTestBridge.UnitTests/SynchronizedSingleSessionVSTestBridgedTestFrameworkTests.cs	Adds coverage for the new GetAssemblyPath behavior across key scenarios.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[simonrozsival]

This change will unblock us in dotnet/android

[Evangelink]

Looks good! The fix correctly solves the reported issue with minimal risk. The synthetic path approach works because on .NET Core, FileOperations.DoesFileExist always returns true and FileOperations.LoadAssembly resolves by assembly name (not file path), so the synthetic name.dll path is just a token to pass AreValidSources validation.

A few minor suggestions below — none are blocking.

Summary of suggestions:

1. Remove the now-redundant #pragma warning disable IL3000 at the call site — the pragma has moved into GetAssemblyPath, so the outer pragma is no longer needed.
2. Use method group Select(GetAssemblyPath) instead of Select(x => GetAssemblyPath(x)).
3. Narrow the pragma scope inside GetAssemblyPath to just the assembly.Location line.
4. The hardcoded .dll extension is fine for the Android CoreCLR scenario (test assemblies are always DLLs there), but a brief comment documenting this assumption would be helpful for future readers.

[Copilot]

Copilot's findings

Comments suppressed due to low confidence (1)

src/Platform/Microsoft.Testing.Extensions.VSTestBridge/SynchronizedSingleSessionVSTestAndTestAnywhereAdapter.cs:192

• GetAssemblyPath currently has nested IL3000 suppressions (one wrapping the whole method and another around assembly.Location). This is redundant and broadens the suppression scope more than needed. Consider keeping a single suppression scoped as narrowly as possible (e.g., only around the assembly.Location access).

#pragma warning disable IL3000 // Avoid accessing Assembly file path when publishing as a single file
    internal static string GetAssemblyPath(Assembly assembly)
    {
#pragma warning disable IL3000 // Avoid accessing Assembly file path when publishing as a single file
        string location = assembly.Location;
#pragma warning restore IL3000 // Avoid accessing Assembly file path when publishing as a single file

• Files reviewed: 2/2 changed files
• Comments generated: 2