Dynamically lightup of injected packages as part of application closure

[gkhanna79]

Today, an application's closure is defined by its corresponding .deps.json file, which is statically computed and known at publish time. However, there are scenarios where certain packages may needed to be injected at runtime for them to become part of the application closure.

To support this, the entity wishing to inject packages would produce a lightup.deps.json and place it in a folder that mimic's the SharedFX layout. That is, the file will live in \Shared<SharedFXPackageName><SharedFrameworkVersion>\lightup.deps.json. The host will then be pointed to BaseFolder during application activation (either via an environment variable or command line argument) and will lookup lightup.deps.json using the SharedFX package name/version from the application's deps.json.

The contents of this file will then be part of the deps.json merge step in the host, where the app's deps.json will still override it incase of conflicting packages (like it does today for fx.deps.json).

CC @DamianEdwards @glennc @davidfowl @ramarag @cakine @eerhardt @Petermarcu @richlander @bleroy

[eerhardt]

@gkhanna79 - Can you give a more concrete user scenario?

[glennc]

@eerhardt When you deploy your application to Azure App Service it will automatically log to the right place, taking into account Azure specific configuration, without you needing to remember to explicitly turn it on or configure it before a problem occurs. That's one end goal that we would enable using this.

[gkhanna79]

Initial PR for this is at dotnet/core-setup#1727

[gkhanna79]

@eerhardt and I have been going over this feature and had few questions for @DamianEdwards @davidfowl and @glennc.

Issue 1
The information (SharedFX name and version) is only ever available for portable apps as that is carried in their runtimeconfig.json to indicate the version app wished to target. For standalone apps, this information is not available since, by design, they are standalone and contain everything.

Thus, they will not be able to use lightup components under a basedir - they will need to have an explicit path specified to the deps.json.

Issue 2
Even if we workaround Issue 1 above by special treating M.N.App details in deps.json of standalone app to force the lighup.deps.json lookup relative to a base folder, @eerhardt pointed out that the native assets of the lightup components will not be found since the RID fallback graph (which enables to perform correct fallback lookup for native assets) is only available in fx.deps.json that is part of a SharedFX installation and not in a standalone app (by design since standalone is self-contained for all applicable assets identified via nuget resolution).

Thus, the question for you is - do you expect to have standalone apps participate in lightup? It looks like a scenario that will likely not work for them .

[gkhanna79]

@davidfowl @DamianEdwards @glennc Do you have any thoughts on this?

[DamianEdwards]

@gkhanna79 I think it's fine for this feature to not be a capability of standalone apps. I think it's in keeping with the general ethos that standalone/self-contained apps are deployed that specifically because they don't want outside influences on them.

[gkhanna79]

@DamianEdwards, in that case, I would like to ensure that feature does not lightup for standalone scenarios. Are you fine with this enforcement?

Also, can you folks please chime in on dotnet/core-setup#1727 (comment) as well?

[DamianEdwards]

I'm fine with this not working for stand-alone apps.