Added extra probing_paths to relative app directory

[matheusbach]

Added extra probing_paths to relative app directory. That way, if the necessary libraries are not found by searching the directory relative to workingDir, the code will look for the additional items that were introduced to the list.

For area-Host

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix this issue
Adapting this patch

For area-Host

Author:	matheusbach
Assignees:	-
Labels:	area-Host
Milestone:	-

[vitek-karas]

Thanks for the PR.

I want to make sure I understand what this is trying to fix:
#3525 is about .deps.json, but this fix seems to be about additionalProbingPaths in .runtimeconfig.json. There is some discussion about this in #3525 but it's definitely not the primary purpose of that issue.
So I assume this is trying to fix the fact that additionalProbingPaths are relative to current directory and not to the application directory.

As for the change, this could be considered a breaking change, so I don't think it can be done as-is. I can see two possible solutions:

• Add two probing paths if the value is a relative path
  • One where it's resolved against the current directory (current behavior, goes first)
  • One where it's resolved against the application directory (new behavior, goes second)
• Change the behavior only for .NET 6+, in which case the behavior would need to adapt based on the TFM of the app. I think this would be the first time we did something like that in the host, but it might work.

Personally I would probably prefer the second solution - only change this for .NET 6+. I do think that the current behavior is just wrong, so fixing this is great, but we can't break existing apps (Note that this code lives in hostfxr which is global, every version of .NET Core on the machine will use the latest hostfxr, so we must maintain backward compatibility for this component).

As for the actual code of the change:

• It doesn't compile for me - GetString is not a member of pal::string_t.
• Resolving relative paths by concatenation is very problematic, at the very least it should use append_path
• The code as-is will prepend the directory even to absolute paths, which will break
• The code should use application's directory as the base, not the directory of .runtimeconfig.json. While they are typically the same, they don't have to be. I think the correct behavior is for the paths to be relative to the app.
• Additional probing paths can also be specified on the command line. I think the behavior should be the same regardless of which way the probing path was added.
• To accept the change it will need tests to cover the new behavior (and in this case also validate the backward compatibility)

[matheusbach]

Sorry for the broken code.
Now I changed the code so that for each item added to the list of probing_paths it also adds a path relative to the app.
I still can't get the application path directly, so I'm still using the .runtimeconfig.json directory. I believe this must be changed.

Fixed the compilation issue and changed the way to join the directories as suggested. I also changed the PR title to not get too confused.

This code compiled and ran on my x64 windows, and was compatible in my tests on .NET Core 3.1 and .NET 5, which were the ones I tested. The code was able to find the libraries in the folders for both the current workingDir and the directory of .runtimeconfig.json.

[vitek-karas]

I thought about this some more and now I definitely prefer the solution where the behavior is different for .NET 6+. The change should be applied in fx_muxer.cpp in append_probe_realpath. This already handles the store path manipulation which is also TFM sensitive, so part of the state is already available there. It's also the one place through all probe paths go (which will make the behavior consistent between runtime config and command line).

[agocke]

This is looking stale -- I'm going to close it out for now.