Native DLL load prefers app local over framework irrespective of file version

[nguerrera]

It appears the host/runtime will prefer an app local native dll over a framework native dll, irrespective of the native dll file version. This could break app roll forward if the roll forward takes the app from a framework that did not have a native dll inbox to one that does. Or from one that had an older version than a package used by the app to one that has a newer version.

Repro steps

NOTE: These are effectively the conditions that reproduce dotnet/aspnetcore#17973

Although the first layer, more urgent issue is that there is a missing entry in the platform manifest, which is being fixed as we speak, I believe there's a second layer issue that is turning the symptom of that from an extra file in the app dir to a crash on app startup. The scenario below is therefore contrived, but the roll forward case mentioned above would be a legitimate case where the same sort of conflict could occur.

With .NET Core SDK 3.1.100 and VS 16.4 installed:

1. mkdir repro && cd repro
2. dotnet new global.json --version 3.1.100 (to pin the problem which will eventually be worked around with a new platform manifest)
3. dotnet new web
4. dotnet add package Microsoft.AspNetCore.Server.IIS
5. devenv repro.csproj
6. F5 to run with IIS express which should be the default:
   

Expected result

App runs fine

Actual result

HTTP Error 500.30 - ANCM In-Process Start Failure"

If you debug, you can see that aspnetcorev2_inprocess.dll has been loaded from the app directory instead of the framework directory

This, despite the framework Microsoft.AspNetCore.App.deps.json having:

     "native": {
          "aspnetcorev2_inprocess.dll": {
            "fileVersion": "13.1.19320.0"
          }

And the repro,deps.json having:

    "runtimeTargets": {
          "runtimes/win-x64/nativeassets/netcoreapp2.2/aspnetcorev2_inprocess.dll": {
            "rid": "win-x64",
            "assetType": "native",
            "fileVersion": "12.2.19169.6"
          },

cc @vitek-karas @ericstj

[vitek-karas]

This has been discussed before: https://github.com/dotnet/core-setup/issues/4435

The main problem is determining file versions on Linux. If we can solve that problem in the SDK (and write those versions into the .deps.json) then solving the host/runtime becomes just a technical problem. The fix is non-trivial though, unfortunately the host/runtime interface makes this really hard today (we would have to change how it works).

[nguerrera]

Great point about Linux. Is there even anything we could sniff from the .so/.dylib files? If not, we could maybe introduce a way for a nuget package to say "asset X has version Y" and rely on correct package authoring.

[jkotas]

Great point about Linux. Is there even anything we could sniff from the .so/.dylib files?

Nothing reliably.

I do not think we want to be in the business of version unification of unmanaged libraries. It is a very complex problem, very niche scenario, and differs from OS to OS.

If folks want to make a roll forward like this work, they need to design for it without the SDK/platform help. For example, I believe that the ASP.NET could have solved the problem by renaming the unmanaged .dll as it was moved inbox.

[nguerrera]

@jkotas That's reasonable. I imagined it might come down to that in dotnet/aspnetcore#17957 (comment)

If this needs to stay this way in the runtime, we might need guidance like always rename a native dll if you pull it in to a framework from a package or something. Or only do this in a major version, but realize it is breaks major roll-forward for any app that used it in a package.

I, for one, could live with the resolution here being "by design" or "won't fix", particularly if we can capture appropriate guidance to avoid having it matter for framework authors. @Pilchie this would be something to add to the list that we've started working on in that case.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.