How to share self contained runtime?

[Symbai]

I have two projects targeting the same runtime. I publish the first one as self contained and copy the second application into the same folder of the first one. But the second won't launch saying the required .NET Core runtime is not installed.

How can apps share the same self contained runtime?

area-Host

[ghost]

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

Issue Details

---

I have two projects targeting the same runtime. I publish the first one as self contained and copy the second application into the same folder of the first one. But the second won't launch saying the required .NET Core runtime is not installed.

How can apps share the same self contained runtime?

area-Host

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

[wfurt]

By definition self-contained app does not share. I think using shared .NET installation is best option for you @
Symbai . Note, that it does not need to live in default location.

[AaronRobinsonMSFT]

@Symbai I think this scenario was also discussed in #46990.

[Symbai]

@AaronRobinsonMSFT The discussion you linked to is about targeting different runtimes where it makes sense to say its not supported. But I target exactly the same runtime, where it makes no sense why it cannot be shared.

@wfurt Thanks but an installation is not an option. For example because on some machines you are not allowed to install. Self contained is just a simple whole .NET runtime copy to folder. If there is no support for having two applications using the same runtime yet, then it might be worth to add support for it.

Why shouldn't I be allowed to use the same runtime there but instead being told I have to install .NET runtime to a folder which is then shared by all applications. That not really makes any sense. I believe when self contained feature was created, nobody simply thought about this "issue" and so it currently doesn't work. But that doesn't mean it cannot be changed / fixed.

//edit: Funny, all it needs to make it work is editing two JSON files for the second application. App2.deps.json and App2.runtimeconfig.json and voila, it works. It would be great when you have both applications in one VS project and publish, you could just include the second application there and it creates the proper JSON files for the second application. But at least I've got a manually workaround.

[wfurt]

I'm perhaps wrong person to argue this but but sharing clearly breaks the self-contain app promise IMHO. How is putting runtime to separate directory different from bringing it with the app? You can even have tat directory be part of your application deployment. For sharing the runtime bits, the shared runtime strategy seems to be good fit.
You can make lot of things working by hacking @Symbai but the hard part IMHO is to make that work consistently correctly in all case cases.

[vitek-karas]

@Symbai - I agree that for simple apps there doesn't seem to be a problem - and if you published both as self-contained and then just copied app.dll/.exe/.deps.json from one to the other it will probably just work. But it doesn't mean it's easy to make this work reliably. Self-contained is not just about including the runtime:

• The SDK will resolve any collisions between assemblies in the app or nugets and what comes with the runtime (you can have a different version of an assembly in the app and in the framework).
• The SDK will resolved/figure out the right versions of all nuget references

If you "copy over" these things won't happen and it can easily break. For example if app1 has a dependency on MyDll.dll version 1.0.0.0, but app2 has a dependency on MyDll.dll version 2.0.0.0, you would have to carefully choose which one to use.
dotnet/sdk#14488 is a start on making some of this work by being able to build both applications together and publish them together. Currently it doesn't work for self-contained publishes though.

Also to fully support this, the result would need to support features like Ready2Run, Trimming and so on - none of these will just work.

For scenarios like yours where you have multiple applications and want to ship a shared runtime for them, I 100% agree with @wfurt . Building the apps as framework-dependent and packaging the runtime with both apps is currently the better solution. Right now it's possible but not easy:

• Either you need to wrap the app with some script or something which will set DOTNET_ROOT to the location of the custom runtime.
• Or you need to write a custom native host, small executable which will start the apps using native hosting APIs, in which case you have full control over specifying where to look for the runtime.

In both cases there's an additional complexity of getting the right runtime downloaded (you want the zipped version for the right platform) and shipping that with your app - but since it's just xcopy deployment, it should not be that hard.

The advantage of this approach is that:

• Each app can bring its own dependencies - no issues with resolving nuget versions between the apps
• No need to bend the SDK in any weird way - both apps are stock framework dependent apps
• Allows for an easier way to update the runtime for both apps - potentially you could even have more than one runtime version and share that between multiple apps

We're thinking about adding better support for this kind of scenario in future versions. It would help us if you could describe what type of apps you're building, why is it OK to package them together and why do you want custom runtime copy. Just so that we have our reasoning correct.

[Symbai]

Ok I didn't thought about assembly versions, that makes sense. In my case I have an app and a standalone updater (console application) that overwrites the main application files if there is an update available. Very simple but necessary.

I think that writing an own native host is a bit over the top. And I think that my request can still be done. The versions / conflicts can be checked and a publish error can be thrown if there is a conflict. Alternatively there should be an easier way to tell the native host where the runtime is located, this will also solve the other issue about file clutter where people requested to move runtime files into a different folder. Maybe this can be done via a build command line which "patches" the native host. Something like:

dotnet build --runtime-path ".\"

Then I can publish the first application self contained. And use the args above on the second application publishing it framework dependent and copy it over.

[vitek-karas]

Both solutions are doable, it's just a question of cost (not just the work, but if it's worth the future maintenance and added complexity).

Then I can publish the first application self contained. And use the args above on the second application publishing it framework dependent and copy it over.

This would still not work, even if the apphost can point to a different location for the runtime. Again, it could be made to work, but I don't think that is desirable. It would be much cleaner to have both apps as framework dependent but share the same runtime folder.

[Symbai]

It would be much cleaner to have both apps as framework dependent but share the same runtime folder.

Still need that build argument above. And something that copies the runtime to that folder as well. Then I'm absolutely fine with its being framework dependent.

[agocke]

Closing in favor of #53834