New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically lightup of injected packages as part of application closure #1597

Closed
gkhanna79 opened this Issue Feb 28, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@gkhanna79
Member

gkhanna79 commented Feb 28, 2017

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

@gkhanna79 gkhanna79 added this to the 2.0.0 milestone Feb 28, 2017

@eerhardt

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Feb 28, 2017

Member

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

Member

eerhardt commented Feb 28, 2017

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

@glennc

This comment has been minimized.

Show comment
Hide comment
@glennc

glennc Feb 28, 2017

@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.

glennc commented Feb 28, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@gkhanna79

gkhanna79 Mar 14, 2017

Member

Initial PR for this is at #1727

Member

gkhanna79 commented Mar 14, 2017

Initial PR for this is at #1727

@gkhanna79

This comment has been minimized.

Show comment
Hide comment
@gkhanna79

gkhanna79 Mar 17, 2017

Member

@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 .

Member

gkhanna79 commented Mar 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@gkhanna79

gkhanna79 Mar 20, 2017

Member

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

Member

gkhanna79 commented Mar 20, 2017

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

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Mar 20, 2017

@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.

DamianEdwards commented Mar 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@gkhanna79

gkhanna79 Mar 20, 2017

Member

@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 #1727 (comment) as well?

Member

gkhanna79 commented Mar 20, 2017

@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 #1727 (comment) as well?

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Mar 20, 2017

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

DamianEdwards commented Mar 20, 2017

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

eerhardt added a commit to eerhardt/core-setup that referenced this issue Mar 31, 2017

DependencyContextLoader should load all dependency files given to it
After dotnet/sdk#1053 is merged, it is possible for an app to run on the shared framework, but not be "portable".  DependencyContextLoader should always load the "runtime" context, if it is present.

Also, with dotnet#1597, there may be other deps files for the app. It should load those as well.

Fix dotnet#1886
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment