Custom GC is loaded from the wrong place in a C++/CLI program

[heh-ad]

Description

In a C++/CLI program, when specifying a custom GC with System.GC.Name, such as clrgc.dll. It will load it from a wrong place included in the PATH environment variable, such as from the PowerShell folder.

If the wrong custom GC is loaded and it is not compatible with the current .NET runtime, then it will cause a crash.

Reproduction Steps

Install .NET 10 preview 7 and PowerShell 7.5.2. Make sure C:\Program Files\PowerShell\7\ added to the PATH environment variable.

Create a C++ console application which loads a C++/CLI library. Add the RuntimeHostConfigurationOption to the C++/CLI project.

  <ItemGroup>
    <RuntimeHostConfigurationOption Include="System.GC.Name" Value="clrgc.dll" />
  </ItemGroup>

Build and run the application.

The code is attached as StandaloneGC.zip. Please try the Debug | x64 configuration.

Expected behavior

clrgc.dll is loaded from C:\Program Files\dotnet\shared\Microsoft.NETCore.App\10.0.0-preview.7.25380.108 and it shows "Hello World!" in the console.

Actual behavior

clrgc.dll is loaded from C:\Program Files\PowerShell\7\ which is still .NET 9, and it crashes when starting the .NET runtime.

Regression?

It worked in .NET 8.

Known Workarounds

Avoid using a custom GC in a C++/CLI program in .NET 9+.

Configuration

.NET 10 preview 7 on Windows 11 24H2 x64

Other information

It is probably caused by #101874, which added APP_CONTEXT_BASE_DIRECTORY as the search path for the custom GC. But for a C++/CLI program, it is empty. Then HostInformation::GetProperty still returns true and CLRLoadLibrary will load it from the one in the PowerShell folder when libraryName doesn't contain the full path.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[agocke]

@AaronRobinsonMSFT The differing behavior in APP_CONTEXT_BASE_DIRECTORY in C++/CLI is pretty strange. Can you take a look?

[AaronRobinsonMSFT]

@heh-ad Sorry you're hitting this issue. I would recommend using System.GC.Path with the absolute path to avoid this issue. Any of the advanced knobs that accept a simple DLL name should be looked at with suspicion. I see the issue and I'll address it shortly, but the "fix" is going to be to fallback to the coreclr path. Components set APP_CONTEXT_BASE_DIRECTORY to empty string, this is by design.

@agocke The issue is that we don't know/set the app base directory for components. The behavior is consistent with the AppContext.BaseDirectory managed API. The fix is going to be to fallback to the install location by the coreclr binary.

@elinor-fung for any additional context.