1

I have a .NET Core 6.0 self-contained application (not a single file deploy).

My app.runtimeconfig.json configuration file contains this setting:

"runtimeOptions": {
        "additionalProbingPaths": [
        "lib",
        "Lib"
        ],

It's because I want to redirect the dll probing to a subfolder to avoid the mess a self-contained application generates on its root.
This way my root contains only these files:

  • app.exe
  • app.dll
  • app.runtimeconfig.json
  • app.deps.json
  • hostfxr.dll
  • hostpolicy.dll

All the runtime dependencies are inside 'lib' folder.

With this configuration the application works perfectly in every scenario with a very relevant exception: if I start it during the Windows startup, it fails.
I think it's not important for the purposes of the bug description but I start the program with a registry entry in HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

I enabled the .NET tracing and compared a trace of a successfull start (double click on the executable) and a trace of an unsuccessfull one (auto start with the registry key).

These are the outcomes:

Successful start with double click:

Runtime config [D:\App\App.runtimeconfig.json] is valid=[1]
Executing as a self-contained app as per config file [D:\App\App.runtimeconfig.json]

Unsuccessful start with autorun:

Runtime config [D:\App\App.runtimeconfig.json] is valid=[1]
Ignoring additional probing path lib as it does not exist.
Executing as a self-contained app as per config file [D:\App\App.runtimeconfig.json]

As you can see if the application runs during the Windows startup, the runtime is not able to find the additional probing path.

The two trace files are identical until this point, then, the lacking of an additional probing path, is causing all the runtime dll files are not found during the failed attempt.

Tested on Windows 10 (x64)

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
epikarma
  • 41
  • 1
  • 7
  • Does this answer your question? [Use registry to startup a program, and also change the current working directory?](https://stackoverflow.com/questions/2822951/use-registry-to-startup-a-program-and-also-change-the-current-working-directory) – Panagiotis Kanavos Jan 28 '22 at 08:33
  • This isn't a .NET or Windows bug. You only specified *relative* paths. A relative path is relative to the working directory, not the application. Starting a program doesn't change the current directory to the program's location. If you tried to execute your program from the console using an absolute path from a different folder you'd get the same error. The duplicate shows how to specify an application's working directory in the registry – Panagiotis Kanavos Jan 28 '22 at 08:36
  • Why not deploy a self-contained *and* single-file application? The size will probably be smaller. If you need to use any native libraries there are ways to package them in the single file bundle – Panagiotis Kanavos Jan 28 '22 at 08:37
  • Single-file is not an option in my case, but your others solutions suggest me a simple workaround. If the problem is the wrong working dir caused by the registry execution, I can create a shortcut in %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\ where I can define a proper working dir. I don't care how the program auto runs, I only need this feature works. – epikarma Jan 28 '22 at 09:02
  • Congrats on 100k @PanagiotisKanavos! – DavidG Jan 28 '22 at 09:11

1 Answers1

0

Thanks to panagiotis-kanavos I understood the problem was related to the 'lib' relative path resolution.
The execution from the registry doesn't imply the working dir is the same of the executable file so that the relative path resolution can't succeded.

I solved the problem moving the autoruns feature from registry to a proper Windows shortcut created in %AppData%\Microsoft\Windows\Start Menu\Programs\Startup. Since with a normal shortcut I can define the correct working directory, the execution and the relative path resolution now succeded.

epikarma
  • 41
  • 1
  • 7