EntryPointNotFoundException when having a dependency with the same name as a Windows DLL

[a-carvallo]

Description

If one of the project dependency is a DLL with the same name as one from the DLLs used by Interop methods (like GetFileVersionInfoSizeEx() called in System.Diagnostics.FileVersionInfo.GetVersionInfo()), and you call such method, it will throw a System.EntryPointNotFoundException likely because it tries to load the DLL from the project dependency, and not the one from Windows.

Reproduction Steps

I made a repository with a solution to reproduce the issue here: https://github.com/a-carvallo/IssueLibName

Run the project IssueWithNet, and there will be a System.EntryPointNotFoundException : 'Unable to find an entry point named 'GetFileVersionInfoSizeExW' in DLL 'version.dll'.'
On the other hand, running the project NoIssueWithNetFramework will run to the end without any issue.

Expected behavior

The .NET 6 program executes with no exception like its .NET Framework 4.8 counterpart.

Actual behavior

A System.EntryPointNotFoundException is thrown while executing the program from the .NET 6 project.

Regression?

No response

Known Workarounds

No response

Configuration

SDK .NET :
 Version:   7.0.101
 Commit:    bb24aafa11

Environnement d'exécution :
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.101\

Host:
  Version:      7.0.1
  Architecture: x64
  Commit:       97203d38ba

Other information

The method which fails to be called:

runtime/src/libraries/Common/src/Interop/Windows/Version/Interop.GetFileVersionInfoSizeEx.cs

Line 10 in e49d7ec

[LibraryImport(Libraries.Version, EntryPoint = "GetFileVersionInfoSizeExW", StringMarshalling = StringMarshalling.Utf16)]

It seems that the issue could be also reproduced when calling methods from any of the DLLs here: https://github.com/dotnet/runtime/blob/e49d7ec7f04f84abc5b6ad35dd00b8d71347c811/src/libraries/Common/src/Interop/Windows/Interop.Libraries.cs

I just happened to get the issue when trying to migrate a project from .NET Framework to .NET, and having a dependency called "Version".

[ghost]

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

Issue Details

---

Description

If one of the project dependency is a DLL with the same name as one from the DLLs used by Interop methods (like GetFileVersionInfoSizeEx() called in System.Diagnostics.FileVersionInfo.GetVersionInfo()), and you call such method, it will throw a System.EntryPointNotFoundException likely because it tries to load the DLL from the project dependency, and not the one from Windows.

Reproduction Steps

I made a repository with a solution to reproduce the issue here: https://github.com/a-carvallo/IssueLibName

Run the project IssueWithNet, and there will be a System.EntryPointNotFoundException : 'Unable to find an entry point named 'GetFileVersionInfoSizeExW' in DLL 'version.dll'.'
On the other hand, running the project NoIssueWithNetFramework will run to the end without any issue.

Expected behavior

The .NET 6 program executes with no exception like its .NET Framework 4.8 counterpart.

Actual behavior

A System.EntryPointNotFoundException is thrown while executing the program from the .NET 6 project.

Regression?

No response

Known Workarounds

No response

Configuration

SDK .NET :
 Version:   7.0.101
 Commit:    bb24aafa11

Environnement d'exécution :
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.101\

Host:
  Version:      7.0.1
  Architecture: x64
  Commit:       97203d38ba

Other information

The method which fails to be called:

runtime/src/libraries/Common/src/Interop/Windows/Version/Interop.GetFileVersionInfoSizeEx.cs

Line 10 in e49d7ec

[LibraryImport(Libraries.Version, EntryPoint = "GetFileVersionInfoSizeExW", StringMarshalling = StringMarshalling.Utf16)]

It seems that the issue could be also reproduced when calling methods from any of the DLLs here: https://github.com/dotnet/runtime/blob/e49d7ec7f04f84abc5b6ad35dd00b8d71347c811/src/libraries/Common/src/Interop/Windows/Interop.Libraries.cs

I just happened to get the issue when trying to migrate a project from .NET Framework to .NET, and having a dependency called "Version".

Author:	a-carvallo
Assignees:	-
Labels:	area-System.Runtime.InteropServices
Milestone:	-

[AaronRobinsonMSFT]

@a-carvallo Thanks for reporting this issue. After investigating this behavior we've determined this specific scenario, "version.dll" was working accidentally in .NET Framework and the general behavior is the result of the OS loader in Windows. Long story short, we can't do much about this given how the Windows OS loader operates.

The reason this worked in .NET Framework was because the start-up of the runtime loaded the Windows "version.dll" earlier than the user defined version and thus worked. However, in .NET Core that need no longer exists during start-up and is therefore deferred causing the issue being observe.

For example, if you have:

HMODULE mod1 = ::LoadLibraryExW(L"C:\\some\\path\\version.dll", NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
HMODULE mod2 = ::LoadLibraryExW(L"version.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32);

mod2 will be the same as mod1. This is the documented/expected behavior for the lib name parameter to LoadLibraryEx.