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

Enable shared libraries and runtimes for a software suite #71282

Open
richlander opened this issue Jun 25, 2022 · 23 comments
Open

Enable shared libraries and runtimes for a software suite #71282

richlander opened this issue Jun 25, 2022 · 23 comments
Milestone

Comments

@richlander
Copy link
Member

richlander commented Jun 25, 2022

Today, we support two scenarios quite well:

  • FDD: App (with all its dependencies) depends on shared globally-installed runtime
  • SCD: App (with all its dependencies) includes the required runtimes (possibly trimmed).

Single file is just a variation on those themes.

The scenario we are missing:

  • Suite of apps share locally-installed runtimes and libraries.

It's intended as a mid-point between FDD and SCD for a software suite. It's like FDD since none of the apps are self-contained, but like SCD since the apps don't rely on a globally installed runtime. Perhaps we could call it "LSD: Locally Shared Deployment". I'm certain people would use LSD if we delivered it to them.

The shared library scenario is similar, in that many software suites use a common set of libraries across apps. Those libraries can be single-instanced (essentially a third-party framework) in a location that is local to the suite. This is not a proposal for the GAC.

This proposal has a soft bias to desktop client apps. However, it could equally apply to hosted server apps, even in containers.

Specific use cases:

@elinor-fung @vitek-karas

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Jun 25, 2022
@ghost
Copy link

ghost commented Jun 25, 2022

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

Issue Details

Today, we support two scenarios quite well:

  • FDD: App (with all its dependencies) depends on shared globally-installed runtime
  • SCD: App (with all its dependencies) includes the required runtimes (possibly trimmed).

Single file is just a variation on those themes.

The scenario we are missing:

  • Suite of apps share locally-installed runtimes and libraries.

It's intended as a mid-point between FDD and SCD for a software suite. It's like FDD since none of the apps are self-contained, but like SCD since the apps don't rely on a globally installed runtime. Perhaps we could call it "LSD: Locally Shared Deployment". I'm certain people would use LSD if we delivered it to them.

The shared library scenario is similar, in that many software suites use a common set of libraries across apps. Those libraries can be single-instanced (essentially a third-party framework) in a location that is local to the suite. This is not a proposal for the GAC.

This proposal has a soft bias to desktop client apps. However, it could equally apply to hosted server apps, even in containers.

Specific use cases:

@elinor-fung @vitek-karas

Author: richlander
Assignees: -
Labels:

area-Host, untriaged

Milestone: -

@MeikTranel
Copy link

MeikTranel commented Jun 25, 2022

I've been dreaming about this for a while now - i wrote a rough proposal for how things could be designed in regards to sharing between projects and how it's deployed - see this comment and the resulting discussion - i think we discovered some important pain points there:
#53834 (comment)

@richlander
Copy link
Member Author

Thanks for all the design thinking already. Happy to host a call(s) on this at some point with anyone who wants to participate.

@MeikTranel
Copy link

i'll be happy to participate - since y'all are already used to thick potato accents i don't have to be all that embarrassed.
EyebrowsAdventureTimeGIF

Maybe we should spin up a design proposal PR to get a grip of what we (as in maintainers and the community) are actually looking for and what is a non-goal - i think i have a good understanding but i'm honestly a little overwhelmed with the complexity of the runtime components involved.

@richlander
Copy link
Member Author

I never met a potato i didn't like!

I will start a design discussion over at dotnet/designs shortly. We can start with the basics and go from there.

Thanks for the support!

@rickbrew
Copy link
Contributor

LSD might not be the best acronym? 😂

@richlander
Copy link
Member Author

And people say Microsoft is bad at naming! This naming is so good, it's psychedelic!

@Splitwirez
Copy link

Never thought I'd see a .NET discussion about getting high on marketing...lol

Jokes aside...just wanted to share my two cents on this: It'd be great for something I've been working on...granted, I have my doubts I'd have the luxury of moving runtimes (.NET Core 3.1 is enough of a gamble under WINE and Windows 7 SP1 without ESUs as-is)...but hey, I can dream. Hopefully others who may have use for this will be more fortunate.

@normj
Copy link

normj commented Jun 26, 2022

As someone that has abused dotnet store for more than it was ever meant I would be very excited about this. Happy to participate in design discussions.

A big requirement I would need is configuring the location of the shared libraries at runtime of the LSD app. For our use of dotnet store we configure the location with the DOTNET_SHARED_STORE environment variable.

Obviously I would like the ability to R2R for a particular runtime the shared assemblies.

@richlander
Copy link
Member Author

@normj -- does that get set from a custom host today?

@normj
Copy link

normj commented Jun 26, 2022

@normj -- does that get set from a custom host today?

Basically yes. In AWS Lambda there is a host that is in charge of setting up the compute environment for the .NET code similar to a container and part of that host's job is setting user supplied environment variables.

@richlander
Copy link
Member Author

The big distinction is whether those ENVs are set before or after the the runtime is loaded.

DOTNET_STARTUP_HOOKS is also related, if managed code needs to be used: https://github.com/dotnet/runtime/blob/main/docs/design/features/host-startup-hook.md

That's not suggesting a specific design direction, but cataloging interesting options.

@normj
Copy link

normj commented Jun 26, 2022

For my use case I just need support for the ENV being set before the .NET runtime is started. I could see some value in other use cases for setting it at the AssemblyLoadContext level.

@richlander
Copy link
Member Author

Ya. That all makes sense. That's well within the bounds of what I have in mind.

@richlander
Copy link
Member Author

Related: dotnet/msbuild#3996

@vitek-karas
Copy link
Member

Might be beneficial for SDK - since it basically already ships with the runtime. We could get rid of every process being dotnet.exe and actually use apphosts to name them appropriately.

@RussKie

This comment was marked as off-topic.

@liesauer
Copy link

I've been dreaming about this for a while now - i wrote a rough proposal for how things could be designed in regards to sharing between projects and how it's deployed - see this comment and the resulting discussion - i think we discovered some important pain points there: #53834 (comment)

you can check this out on how NetBeauty2 shares runtimes between apps, https://github.com/nulastudio/NetBeauty2#shared-runtime-structure

@eabramczyk-mxtr
Copy link

Is this going to go on the roadmap for .NET 8? Per normj in this issue discussion the shared pre-compiled library functionality of .NET Core 3.1 was extremely valuable for AWS Lambda Layers for .NET and greatly improved my company's code's cold start times in a serverless environment, would love to have this functionality back in this LTS cycle.

@agocke
Copy link
Member

agocke commented Mar 6, 2023

At this moment, I don't think we have a complete design for a feature set here, so I can't commit to .NET 8.

Once we have a feature design, I think we can discuss planning milestones.

@agocke agocke removed this from the 8.0.0 milestone Mar 6, 2023
@agocke agocke added this to the Future milestone Mar 6, 2023
@agocke agocke changed the title .NET 8: Enable shared libraries and runtimes for a software suite Enable shared libraries and runtimes for a software suite May 12, 2023
@OptiStrat
Copy link

This would be a great option for a suite of xcopy-deployed WinUI apps, which could then share C# projections.

@japj
Copy link
Contributor

japj commented Mar 18, 2024

Is there any work ongoing to finish a design document?
We’ve been running into this issue and I would like to understand where dotnet is heading before colleagues start implementing their own “solution”.

@agocke
Copy link
Member

agocke commented Mar 18, 2024

This is in the backlog, but it has not reached planning priority yet. I would not expect anything for .NET 9.

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