additionalProbingPaths uses the current directory instead of directory where .runtimeconfig.json is

[vladimir-cheverdyuk-altium]

It looks like relative paths in additionalProbingPaths are resolved using the current directory and not a directory where .runtimeconfig.json is.

As a result, when the application started from a different directory, it fails. I checked the source code and look like it is the case. But I'm not an expert and I would like to double-check that it is correct. If I'm correct then how app supposed to be used in general when the current path could be different from the directory where an executable file is?

I found it when I was writing CLR host but it is also reproducible on the usual app. I created a console app and in the different solutions, I created a regular class library project. Then I referenced compiled assembly of the class library from the console app. Then I copied all relevant files to a new directory and added additionalProbingPaths. When I start the application from the same directory, it works fine. When I start it from a different directory (for example from absolute path), it fails.

I can provide source code if needed, to save you time.

Thank you,
Vlad

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. 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

---

It looks like relative paths in additionalProbingPaths are resolved using the current directory and not a directory where .runtimeconfig.json is.

As a result, when the application started from a different directory, it fails. I checked the source code and look like it is the case. But I'm not an expert and I would like to double-check that it is correct. If I'm correct then how app supposed to be used in general when the current path could be different from the directory where an executable file is?

I found it when I was writing CLR host but it is also reproducible on the usual app. I created a console app and in the different solutions, I created a regular class library project. Then I referenced compiled assembly of the class library from the console app. Then I copied all relevant files to a new directory and added additionalProbingPaths. When I start the application from the same directory, it works fine. When I start it from a different directory (for example from absolute path), it fails.

I can provide source code if needed, to save you time.

Thank you,
Vlad

Author:	vladimir-cheverdyuk-altium
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

Your description is correct. The feature was originally introduced for local "development only" scenarios - SDK would write the property into .runtimeconfig.dev.json to point to NuGet cache locations, because it didn't copy all of the app's dependencies into the output. This behavior has been changed back in .NET Core 3.0 and so it's rarely used anymore.

Also, the feature doesn't work the way most people expect it to (the path it points to is not a simple directory with assemblies, it has to follow the NuGet cache folder structure). Ideally we would change this, but that would be too breaking to do.

It's not likely we will be able to change directory behavior as it is a breaking change and the benefits are arguable - yes, it makes it possible to use this to put parts of the app into a different location, but the problem with the weird directory structure remains.

We're starting to think about something similar as a general improvement here: #71282

[vladimir-cheverdyuk-altium]

Thank you @vitek-karas for checking this. I was wondering why they didn't work in my CLR host. Now I understand that.
I'v added custom attribute to .runtimeconfig.json for sake of keeping everything in one place. Host reads it and assigns values to APP_PATHS.

[vitek-karas]

@vladimir-cheverdyuk-altium I would be interested in what kind of changes you made to .runtimeconfig.json to get this to work.

[vladimir-cheverdyuk-altium]

Just to be clear, this code executes in in our native app that loads .NET runtime.

I created this block in .runtimeconfig.json:

    "additionalAssemblyPaths" : [
      ".",
      ".\\System\\DotNet\\AutoMapper.6.2.2",
      ".\\System",
      ".\\System\\DotNet\\Unity.Container.5.8.6",
      ".\\System\\DotNet\\DevExpress.Core",
      ".\\System\\Cef",
      ".\\System\\DotNet"
    ],

then host initialization code reads that block from .runtimeconfig.json file and assigns it to APP_PATHS using hostfxr_set_runtime_property_value_fn.
Basically it is kind of replacement of <probing privatePath> from .NET Framework .exe.config file.

[vitek-karas]

Got it - thanks.