[DllImport] on Windows fails to load library on case sensitive filesystem

[wikancz]

Description

[DllImport] on Windows fails to load library on case sensitive filesystem
System: Windows 10 (21H1)
.net version: 6.0
File system: NTFS with SetCaseSensitiveInfo enabled

Reproduction Steps

1. have Windows with case sensitive filesystem: fsutil.exe file SetCaseSensitiveInfo C:\folder\path enable
2. have somelibrary.dll - note all letters are lower case
3. use [DllImport("somelibrary")] without specifying extension
4. run project

Expected behavior

Project correctly loads somelibrary.dll.

Actual behavior

Project fails with exception:
DllNotFoundException: Unable to load DLL 'somelibrary' or one of its dependencies: The specified module could not be found. (0x8007007E)

Regression?

No response

Known Workarounds

Rename library to somelibrary.DLL.

Configuration

No response

Other information

No response

[danmoseley]

What are you expecting here -- for interop to try every possible casing of 'dll' ? It seems there either needs to be a convention (which is apparently "DLL" inadvertently or not) or the code importing the library needs to include the extension.

[wikancz]

Including extension will be problematic when writing cross platform project.
And according to this: https://docs.microsoft.com/en-us/dotnet/standard/native-interop/cross-platform it adds .dll and not .DLL.

[jkotas]

And according to this: https://docs.microsoft.com/en-us/dotnet/standard/native-interop/cross-platform it adds .dll

We depend on Windows OS to add the extension in this case.
https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya#parameters says that it adds .dll that does not match the actual behavior.

[AaronRobinsonMSFT]

@wikancz As @jkotas mentioned we are relying upon the Windows OS to append the extension. I've confirmed internally that the extension being appended is indeed ".DLL", which means this is the behavior. I will reach out to the owners to update the documentation in this area.

There isn't much the runtime can do other than try various permutations as @danmoseley mentioned above. While this approach is technically possible it isn't something we would be inclined to hard code into the runtime itself. I agree with you that ".dll" is the preferred casing but changing that at this point is likely untenable for Windows.

I will update this thread when I get a response but for now close the issue as it is really existing Windows behavior and a documentation bug.

[jkotas]

We do append the lower-cased .dll suffix ourselves in some corner cases:

runtime/src/coreclr/vm/nativelibrary.cpp

Line 597 in d603356

libNameVariations[varCount++] = NameSuffixFmt;

. A library with . in name will cause the runtime to append the lower-cased .dll instead of depending on the OS to do so. It means that we are inconsistent with the OS here.

I think we should either fix our handling of the corner-cases to be consistent with the OS, or we can take over and always append the lower-cased suffix as needed instead of depending on the OS. (I agree that the OS docs should be updated too.)

[AaronRobinsonMSFT]

We do append the lower-cased .dll suffix ourselves in some corner cases:

Boo. I thought we got rid of that logic and were always depending on the Windows OS. Blech.

Reopening and will update based on what I hear from Windows.

[AaronRobinsonMSFT]

@jkotas Thoughts on adding both the lowercase and uppercase? I'm not sure I like that but frankly the .dll is going to be the most common so that is "expected" and I'd like to also match users who are expecting the existing Windows .DLL behavior. This does contradict my statement about policy but I really thought on Windows we deferred entirely to LoadLibrary.

[jkotas]

Thoughts on adding both the lowercase and uppercase?

It doubles the amount of probing we would be doing in common case to handle a niche case. It does not sound like a good trade off to me.

If I were to pick, I would go with always appending the lower-cased suffix as needed instead of depending on the OS.

I expect that this issue is just a tip of the iceberg and number of other issues will show up if you try to run Windows .NET apps on case-sensitive file system. I do not think we need to worry about somebody depending on the existing Windows .DLL behavior.

[AaronRobinsonMSFT]

If I were to pick, I would go with always appending the lower-cased suffix as needed instead of depending on the OS.

Okay.

I expect that this issue is just a tip of the iceberg and number of other issues will show up if you try to run Windows .NET apps on case-sensitive file system.

I have the same feeling.

[danmoseley]

@wikancz just curious, how do you come to mount a case sensitive filesystem on Windows? What is the scenario here?

[wikancz]

@danmoseley Some of our coworkers tried to work with our repository on Linux machines but ran into problems with incorrect file references caused by casing.
I tried to solve it but instead of setting up my own Linux machine I just turned on case sensitivity.

[danmoseley]

gotcha, well thank you for reporting as I think this change is worthwhile.