Allows additional deps for self-contained apps

[vitek-karas]

The host currently ignores any usage of "Additional deps" (--additional-deps or DOTNET_ADDITIONAL_DEPS) in self-contained apps. Note that it doesn't fail, it simply ignores the command line option (or env. variable).

Historically this was done because some functionality was not possible to achieve. There's a good about this here:

runtime/src/native/corehost/hostpolicy/deps_resolver.cpp

Lines 624 to 633 in 87798e7

	// Additional deps.json support is only available for framework-dependent apps due to the following constraints:
	//
	// 1) Unlike framework-dependent Apps, self-contained apps do not have details of the SharedFX and Version they target.
	// 2) Unlike framework-dependent Apps, self-contained apps do not have RID fallback graph that is required for looking up
	// the correct native assets from nuget packages.
	//
	// Additional deps.json support is not available for libhost scenarios. For example, if CoreCLR is instantiated from a
	// library context (i.e. comhost) the activation of classes are assumed to be performed in an AssemblyLoadContext. This
	// assumption is made because it is possible an existing CoreCLR was already activated and it may not satisfy the current
	// needs of the new class.

The short version is:

1. Self-contained doesn't have information about frameworks and their versions
2. Self-contained doesn't have RID fallback graph

Additional deps was basically a way to enable plugins. But it required command line/env. variables and was relatively tricky to use correctly. Since then we implemented full plugin support in 3.0 (mostly). The new solution doesn't require command line options, instead it relies on managed APIs (AssemblyDependencyResolver). Along with this we solved all of the problems mentioned above.

1. Self-contained apps carry framework information in their .runtimeconfig.json, in the form of includedFrameworks property.
2. Self-contained apps carry RID fallback graphs (always)

So it should be solvable to implement full support for additional deps on self-contained apps. Alternatively as a half-step, we could implement support for just specifying full file path (.deps.json) in which case the framework information is not needed, only the RID fallback graph is. In that case the change is much simpler. It would also us to avoid the relatively troublesome "roll forward"/"roll backward" behavior implemented in the folder path case. See for more details: https://github.com/dotnet/runtime/blob/main/docs/design/features/additional-deps.md.

Note that any change here will be a slight breaking change. For now we ignore additional deps on self-contained apps, starting to honor it (even in limited version) could potentially break some apps. As such the change should be implemented for 6+ only. Open question is if this should be based on the version of the runtime the app uses, or on the app's TFM (note that so far the host doesn't really change behavior based on app's TFM, so this would be potentially problematic as another "first").

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

Issue Details

---

The host currently ignores any usage of "Additional deps" (--additional-deps or DOTNET_ADDITIONAL_DEPS) in self-contained apps. Note that it doesn't fail, it simply ignores the command line option (or env. variable).

Historically this was done because some functionality was not possible to achieve. There's a good about this here:

runtime/src/native/corehost/hostpolicy/deps_resolver.cpp

Lines 624 to 633 in 87798e7

	// Additional deps.json support is only available for framework-dependent apps due to the following constraints:
	//
	// 1) Unlike framework-dependent Apps, self-contained apps do not have details of the SharedFX and Version they target.
	// 2) Unlike framework-dependent Apps, self-contained apps do not have RID fallback graph that is required for looking up
	// the correct native assets from nuget packages.
	//
	// Additional deps.json support is not available for libhost scenarios. For example, if CoreCLR is instantiated from a
	// library context (i.e. comhost) the activation of classes are assumed to be performed in an AssemblyLoadContext. This
	// assumption is made because it is possible an existing CoreCLR was already activated and it may not satisfy the current
	// needs of the new class.

The short version is:

1. Self-contained doesn't have information about frameworks and their versions
2. Self-contained doesn't have RID fallback graph

Additional deps was basically a way to enable plugins. But it required command line/env. variables and was relatively tricky to use correctly. Since then we implemented full plugin support in 3.0 (mostly). The new solution doesn't require command line options, instead it relies on managed APIs (AssemblyDependencyResolver). Along with this we solved all of the problems mentioned above.

1. Self-contained apps carry framework information in their .runtimeconfig.json, in the form of includedFrameworks property.
2. Self-contained apps carry RID fallback graphs (always)

So it should be solvable to implement full support for additional deps on self-contained apps. Alternatively as a half-step, we could implement support for just specifying full file path (.deps.json) in which case the framework information is not needed, only the RID fallback graph is. In that case the change is much simpler. It would also us to avoid the relatively troublesome "roll forward"/"roll backward" behavior implemented in the folder path case. See for more details: https://github.com/dotnet/runtime/blob/main/docs/design/features/additional-deps.md.

Note that any change here will be a slight breaking change. For now we ignore additional deps on self-contained apps, starting to honor it (even in limited version) could potentially break some apps. As such the change should be implemented for 6+ only. Open question is if this should be based on the version of the runtime the app uses, or on the app's TFM (note that so far the host doesn't really change behavior based on app's TFM, so this would be potentially problematic as another "first").

Author:	vitek-karas
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

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

Issue Details

---

The host currently ignores any usage of "Additional deps" (--additional-deps or DOTNET_ADDITIONAL_DEPS) in self-contained apps. Note that it doesn't fail, it simply ignores the command line option (or env. variable).

Historically this was done because some functionality was not possible to achieve. There's a good about this here:

runtime/src/native/corehost/hostpolicy/deps_resolver.cpp

Lines 624 to 633 in 87798e7

	// Additional deps.json support is only available for framework-dependent apps due to the following constraints:
	//
	// 1) Unlike framework-dependent Apps, self-contained apps do not have details of the SharedFX and Version they target.
	// 2) Unlike framework-dependent Apps, self-contained apps do not have RID fallback graph that is required for looking up
	// the correct native assets from nuget packages.
	//
	// Additional deps.json support is not available for libhost scenarios. For example, if CoreCLR is instantiated from a
	// library context (i.e. comhost) the activation of classes are assumed to be performed in an AssemblyLoadContext. This
	// assumption is made because it is possible an existing CoreCLR was already activated and it may not satisfy the current
	// needs of the new class.

The short version is:

1. Self-contained doesn't have information about frameworks and their versions
2. Self-contained doesn't have RID fallback graph

Additional deps was basically a way to enable plugins. But it required command line/env. variables and was relatively tricky to use correctly. Since then we implemented full plugin support in 3.0 (mostly). The new solution doesn't require command line options, instead it relies on managed APIs (AssemblyDependencyResolver). Along with this we solved all of the problems mentioned above.

1. Self-contained apps carry framework information in their .runtimeconfig.json, in the form of includedFrameworks property.
2. Self-contained apps carry RID fallback graphs (always)

So it should be solvable to implement full support for additional deps on self-contained apps. Alternatively as a half-step, we could implement support for just specifying full file path (.deps.json) in which case the framework information is not needed, only the RID fallback graph is. In that case the change is much simpler. It would also us to avoid the relatively troublesome "roll forward"/"roll backward" behavior implemented in the folder path case. See for more details: https://github.com/dotnet/runtime/blob/main/docs/design/features/additional-deps.md.

Note that any change here will be a slight breaking change. For now we ignore additional deps on self-contained apps, starting to honor it (even in limited version) could potentially break some apps. As such the change should be implemented for 6+ only. Open question is if this should be based on the version of the runtime the app uses, or on the app's TFM (note that so far the host doesn't really change behavior based on app's TFM, so this would be potentially problematic as another "first").

Author:	vitek-karas
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-