-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Comments
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsToday, we support two scenarios quite well:
Single file is just a variation on those themes. The scenario we are missing:
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:
|
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: |
Thanks for all the design thinking already. Happy to host a call(s) on this at some point with anyone who wants to participate. |
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! |
LSD might not be the best acronym? 😂 |
And people say Microsoft is bad at naming! This naming is so good, it's psychedelic! |
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. |
As someone that has abused A big requirement I would need is configuring the location of the shared libraries at runtime of the LSD app. For our use of Obviously I would like the ability to R2R for a particular runtime the shared assemblies. |
@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. |
The big distinction is whether those ENVs are set before or after the the runtime is loaded.
That's not suggesting a specific design direction, but cataloging interesting options. |
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. |
Ya. That all makes sense. That's well within the bounds of what I have in mind. |
Related: dotnet/msbuild#3996 |
Might be beneficial for SDK - since it basically already ships with the runtime. We could get rid of every process being |
This comment was marked as off-topic.
This comment was marked as off-topic.
you can check this out on how NetBeauty2 shares runtimes between apps, https://github.com/nulastudio/NetBeauty2#shared-runtime-structure |
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. |
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. |
This would be a great option for a suite of xcopy-deployed WinUI apps, which could then share C# projections. |
Is there any work ongoing to finish a design document? |
This is in the backlog, but it has not reached planning priority yet. I would not expect anything for .NET 9. |
Today, we support two scenarios quite well:
Single file is just a variation on those themes.
The scenario we are missing:
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:
dotnet store
.@elinor-fung @vitek-karas
The text was updated successfully, but these errors were encountered: