Skip to content
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

Support pay-for-play runtime properties/services #3673

Open
vitek-karas opened this issue Jul 8, 2019 · 1 comment
Open

Support pay-for-play runtime properties/services #3673

vitek-karas opened this issue Jul 8, 2019 · 1 comment
Milestone

Comments

@vitek-karas
Copy link
Member

Currently the only way to pass information between the host and the runtime is the "runtime properties" array. This array is not pay-for-play, all the properties which the runtime will ever know must be in it. This means that if there are properties which are filled by the host itself (like TRUSTED_PLATFORM_ASSEMBLIES), all the applications will pay the price to create the property and pass it to the runtime.

The cost associated with the property is non-zero, there are 3-4 copied of the property names and values made during startup.

It would be beneficial to have a pay-for-play mechanism of getting information from the host, and eventually not just information by entire services. The host could expose useful information (which is useful for a very limited set of apps though), like:

  • Path to the muxer used to runt he app (if there's any)
  • Path to the .runtimeconfig.json used by the app (if any)

As for services we're already running into this problem today. The AssemblyDependencyResolver relies on services provided by hostpolicy. Today the communication is done via special APIs on hostpolicy, which means the runtime/corelib have hardcoded dependency on hostpolicy itself. This prevents hosts which are not using our hosting libraries unable to provide such services. (This is not very common and in general we encourage users to always rely on our hosting components, but the direct hosting API still exists and is supported).

@msftgits msftgits transferred this issue from dotnet/core-setup Jan 30, 2020
@msftgits msftgits added this to the Future milestone Jan 30, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@jeffschwMSFT jeffschwMSFT removed the untriaged New issue has not been triaged by the area owner label Feb 24, 2020
@agocke agocke added this to AppModel Jul 28, 2022
Copy link
Contributor

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

@dotnet-policy-service dotnet-policy-service bot added backlog-cleanup-candidate An inactive issue that has been marked for automated closure. no-recent-activity labels Aug 25, 2024
@elinor-fung elinor-fung removed no-recent-activity backlog-cleanup-candidate An inactive issue that has been marked for automated closure. labels Aug 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

5 participants