Dll search path sequence changed in dotnet 9 if we use symlink to a exe.

[hmisaki]

Description

I'm working on migrating a Windows project from .NET 8 to .NET 9. During this process, I discovered a change in behavior when launching an executable via a symlink. Specifically, the DLL search sequence differs between .NET 8 and .NET 9 when using a symlink to run the executable.

To illustrate the issue, I created a sample project to reproduce the problem and used the Process Monitor tool to compare the behavior. Below is the result of the comparison between .NET 8 and .NET 9:

This change in behavior could potentially lead to different results in some code execution. For example,

/// Gets the file path of the current module.
std::wstring getModuleFileName()
{
    MEMORY_BASIC_INFORMATION mb;
    VirtualQuery(getModuleFileName, &mb, sizeof(mb));
    HINSTANCE hInst = reinterpret_cast<HINSTANCE>(mb.AllocationBase);
    std::wstring path(MAX_PATH, L'\0');
    DWORD nRet = ::GetModuleFileNameW(hInst, &path[0], MAX_PATH);
    path.resize(nRet);
    return path;
}

Reproduction Steps

Using .NET 8 SDK:

1. Create a Console App project named "APP".
2. Create a Class Library project named "LIBA".
3. Set the APP project to depend on the LIBA project.
4. Build both the APP and LIBA projects.
5. Use the mklink command to create symlink files for *.dll, *.exe, and *.runtimeconfig.json in a deployment folder.
6. Use Process Monitor to track the file search sequence for LIBA.dll.
7. Double-click the symlinked APP.exe file to launch the executable.

Using .NET 9 SDK:
Follow the same steps as outlined in the .NET 8 SDK section.

Expected behavior

It should search the folder where the symlink file is located, as we are launching the executable from this folder.

Actual behavior

It first searches the folder where the source APP.exe is located.

Regression?

Yes

Known Workarounds

Stop using Symfile and copy the APP.exe to the deployment folder.

Configuration

Dotnet 9.0 in windows

Other information

none

[elinor-fung]

I'd guess this is related to #99576 - cc @agocke

@hmisaki I'd like to understand your scenario that broke a bit more here. Are you manually constructing an entire deployment folder using symlinks that point to files from different folders? That is, the real APP.exe/APP.dll and LIBA.dll are not in the same folder? If they are all in the same folder, I'd expect the scenario to still work even though the runtime stopped looking next to the .exe symlink.

[romanan]

Are you manually constructing an entire deployment folder using symlinks that point to files from different folders?

Yes. This is only happening for our development environment, we use symbolic links to create a deployment folder to map the binaries from their build output folder. This facilitates our development & testing.
Our actual product install environment doesn't do this.

[panxn]

It also affects AppDomain.CurrentDomain.BaseDirectory, Assembly.GetExecutingAssembly().Location etc.

Will .NET fix it or accept this behavior change?

[dennis-yemelyanov]

Also hit this issue. .NET 8 was using config file from the current folder (the one containing the symlink), but .NET 9 uses config file from a different folder (the symlink target). It was really tricky to debug and narrow down to this issue.

Any plans to fix or document this breaking change?

[elinor-fung]

@agocke filed a breaking change doc issue at dotnet/docs#45584
He also mentioned he might have a narrow patch for the visible API change (like AppContext.BaseDirectory).

[agocke]

We previously took a fix for windows network shares that restores the base directory to what it looked like before. But overall, the base directory change is intentional. The base directory of an application behind a symlink is the symlink target, not the symlink itself.

[snakefoot]

See also #115135 and #116244