Enable shared libraries and runtimes for a software suite

[richlander]

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:

• Finally provide a replacement for dotnet store.
• Shared libraries with COM
• Add-ins whose dependencies (at least in part) are guaranteed to be satisfied by the host app.
• This has come up many times within Microsoft, from various teams.

@elinor-fung @vitek-karas

[ghost]

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:

• Finally provide a replacement for dotnet store.
• Shared libraries with COM
• This has come up many times within Microsoft, from various teams.

@elinor-fung @vitek-karas

Author:	richlander
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[MeikTranel]

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]

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]

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.

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]

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]

LSD might not be the best acronym? 😂

[richlander]

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

[Splitwirez]

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]

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]

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

[normj]

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

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]

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]

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

[richlander]

Related: dotnet/msbuild#3996

[vitek-karas]

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.

[liesauer]

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]

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]

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.

[OptiStrat]

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

[japj]

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]

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

[chrarnoldus]

It seems this was implemented in .NET 9: https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli#configure-net-install-search-behavior

[richlander]

That's part of it. That's the runtime. We're still talking about the shared library scenario.