Self contained application does not start when the current directory is the application directory and current directory containing {appname}.runtimeconfig.json but does not contain {appname}.deps.json

[TalAloni]

Description

I have a self-contained application without ".runtimeconfig.json" and without .deps.json.
I recently needed to start using ".runtimeconfig.json" (for the purpose of setting 'System.GC.Server').

The inclusion of the ".runtimeconfig.json" file changed the behavior of the (self-contained) application and now it can no longer be started when the current directory is the application directory.
I have to change the current directory in order for me to start the application.

After investigation, I have came across this in fx_muxer.cpp:

runtime/src/native/corehost/fxr/fx_muxer.cpp

Line 326 in bc6d349

// Name of runtimeconfig file; since no path is included here the check is in the current working directory

runtime/src/native/corehost/fxr/fx_muxer.cpp

Line 329 in bc6d349

return (deps_exists || !pal::file_exists(config_in_cwd)) && pal::file_exists(host_info.app_path) ? host_mode_t::apphost : host_mode_t::split_fx;

As can be seen, the presence of '{appname}.runtimeconfig.json' in the current directory, affect whether the self-contained application will be detected as a "standalone apphost" or "legacy split mode".

Reproduction Steps

1. Create a Console application
2. Set "GenerateRuntimeConfigurationFiles" and "GenerateDependencyFile" to false.
3. Publish the application and set self-contained to true.
4. Add a minimal {appname}.deps.json to the application directory containing just "{}".
5. Attempt to launch the application when the current directory is the application directory.

Expected behavior

The application should launch successfully.

Actual behavior

The following message is displayed

Could not execute because the application was not found or a compatible .NET SDK
 is not installed.
Possible reasons for this include:
  * You intended to execute a .NET program:
      The application '/RUNASAPPLICATION' does not exist.
  * You intended to execute a .NET SDK command:
      It was not possible to find any installed .NET SDKs.
      Install a .NET SDK from:
        https://aka.ms/dotnet-download

Regression?

No

Known Workarounds

Change the working directory

Configuration

Tested .NET Core 3.1 / .NET 5 / .NET 6.0.1

Other information

No response

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

Issue Details

---

Description

I have a self-contained application without ".runtimeconfig.json" and without .deps.json.
I recently needed to start using ".runtimeconfig.json" (for the purpose of setting 'System.GC.Server').

The inclusion of the ".runtimeconfig.json" file changed the behavior of the (self-contained) application and now it can no longer be started when the current directory is the application directory.
I have to change the current directory in order for me to start the application.

After investigation, I have came accross this line of code in fx_muxer.cpp:

runtime/src/native/corehost/fxr/fx_muxer.cpp

Line 326 in bc6d349

// Name of runtimeconfig file; since no path is included here the check is in the current working directory

As can be seen, the presence of '{appname}.runtimeconfig.json' in the current directory, affect whether the self-contained application will be detected as a "standalone apphost" or "legacy split mode".

Reproduction Steps

1. Create a Console application
2. Set "GenerateRuntimeConfigurationFiles" and "GenerateDependencyFile" to false.
3. Publish the application and set self-contained to true.
4. Add a minimal {appname}.deps.json to the application directory containing just "{}".
5. Attempt to launch the application when the current directory is the application directory.

Expected behavior

The application should launch successfully.

Actual behavior

The following message is displayed

Could not execute because the application was not found or a compatible .NET SDK
 is not installed.
Possible reasons for this include:
  * You intended to execute a .NET program:
      The application '/RUNASAPPLICATION' does not exist.
  * You intended to execute a .NET SDK command:
      It was not possible to find any installed .NET SDKs.
      Install a .NET SDK from:
        https://aka.ms/dotnet-download

Regression?

No

Known Workarounds

Change the working directory

Configuration

Tested .NET Core 3.1 / .NET 5 / .NET 6.0.1

Other information

No response

Author:	TalAloni
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

This is not really surprising, applications without .runtimeconfig.json are not really supported. I agree that this could/should probably be fixed, but I would strongly advise against removing .runtimeconfig.json. Similarly for .deps.json, the behavior without .deps.json is relatively well defined, but there are still potential issues.

Just curious: Why did you decide to remove the .runtimeconfig.json (and the .deps.json) ?

[TalAloni]

Thanks, so just to be clear, I don't mind having .runtimeconfig.json but I wish to keep avoiding .deps.json.
I found out that when .deps.json is present I am not able to dynamically load any pre-generated XmlSerializer DLL (generated using 'Microsoft.XmlSerializer.Generator').

Once I removed .deps.json, this issue forced me to remove .runtimeconfig.json.

It would be great to have this fixed as the current behavior is baffling at best.

[timo352]

Commenting on this since we are running into similar problems at our organization on .NET 8.
The "error" message displayed now is the dotnet help text instead of an actual error.

runtime/src/native/corehost/fxr/fx_muxer.cpp

Line 328 in 0fb0188

return (deps_exists || !pal::file_exists(config_in_cwd)) && pal::file_exists(host_info.app_path) ? host_mode_t::apphost : host_mode_t::split_fx;

The workarounds that we have found make the issue seem more like a bug than a legacy feature:

1. Run from a different directory. Changing behavior based on cwd seems wrong.
2. Call dotnet *.dll instead of calling *.exe directly. This requires having dotnet installed on the machine, partially defeating the purpose of self-contained apps.
3. Move runtimeconfig.json to a different folder and provide the runtimeconfig <path> option

For a few reasons [mainly the way that we deliver and support customized patches to previously deployed software] we do not want to rely on shipping the deps.json file. However, there are settings in runtimeconfig.json that are necessary for our application to work. We are able to get around it for now with workaround 2 with an IIS deployed application. We plan on adding support for Unix soon. In which case, we can't rely on workaround 2 since we will not want to install the dotnet runtime separately from our app.

We'd gladly volunteer time to fixing it if we could get more details on what the "legacy split/fx mode" use case is. I'm not sure what existing behavior for .NET Core 1.x apps we need to avoid breaking. In my tests, this same workflow also fails for .NET Core 1.0 builds. Only running split_fx mode if the cwd is different from the application dir seems like a possibility.