Add a document with guidance on how to ship an .NET app or library on Linux

[dagood]

Other platforms have guidance docs for how to deploy applications and libraries on Linux, as part of the distro or as a third party app:

• https://fedora-java.github.io/howto/latest/
• https://docs.fedoraproject.org/en-US/packaging-guidelines/Mono/

.NET [Core] should have something similar.

@omajid looked into these and came up with some ideas:

This isn't something I have looked at in detail. That said, other similar programming languages have a ton of guides/policies we can learn from. Looking at https://fedora-java.github.io/howto/latest/ for a minute, it sounds like we basically need two set of rules: 1. my package is a library (or nuget package) 2. my package is an application

for 1, a distro would set up a common path as a nuget package repository and all (.net based) library rpm-packages should install into it. maybe something like /usr/lib/dotnet-repository/ or some such.

for 2, the application can probably install into /usr/lib/application-name (or, more appropraite for an app not part of the distro: /opt/application-name) and then install a script that does /usr/bin/dotnet /path/to/my/application.dll and copy that into /usr/bin/ (or /usr/local/bin, for app not part of the distro)
and an RPM package would just contain the concrete steps to build and install into one of these locations

---

Runtime-dependent apps using our packages (https://docs.microsoft.com/en-us/dotnet/core/distribution-packaging#recommended-packages) might be the obvious scenario to document, but it makes sense to give guidance for self-contained deployments as well. E.g. to run on distros that don't have .NET runtimes available as packages.

On the managed library side, there are some more complications:

• For the build-time dependency, there should be a standard place on disk to place NuGet packages. (We should establish one.) This is necessary when building a package to include in a Linux distribution, because we can't use nuget.org (prebuilts!).
• At runtime, it's wasteful to include a copy of every managed dependency DLL along with your app. It may be good to recommend deploying to the runtime store (https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store) to avoid this.

Originated at https://twitter.com/adanenrique/status/1247701126494990343 🙂 Thanks to Red Hat folks for helping with research and recommendations here.

/cc @richlander @leecow @nakarnam @dleeapho

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 85eba478-0374-bb9b-8fa7-d5cf7d520603
• Version Independent ID: 89967250-8c3b-1999-078f-94ad7518ed49
• Content: Application publishing - .NET Core
• Content Source: docs/core/deploying/index.md
• Product: dotnet-core
• GitHub Login: @Thraka
• Microsoft Alias: adegeo

[omajid]

cc @tmds

[tmds]

These global tools pack .NET Core apps as distro packages: https://github.com/qmfrederik/dotnet-packaging.

This is necessary when building a package to include in a Linux distribution

I would really like .NET Core apps to be able to ship as part of standard distro repos. Unfortunately, I think the effort to completely build real apps from source is significant, and I'm not sure who would want to invest.

Packing as a 'global tool' is also an option.

[omajid]

Packing as a 'global tool' is also an option.

Is there such a thing as "shared" or "machine-wide" global tools? AFAIK, they are only looked up in the users's ~/.dotnet/... directory, which makes it incompatible with the idea of packaging as a distro-package (rpm, deb, etc). AFAIK distro packages are explicitly not allowed (modulo hacks) to touch a user's $HOME on installation.

[tmds]

It's not an explicit mode like --local and --global. It should work when pointing --tool-path to a folder that is on PATH for all users, though it would be nicer if this was a first-class install location.

npm has a --global install option which means: install an app for all users. It adds a symbolic link under /usr/local/bin/, the app files are placed under /usr/local/lib/<command>/.

[tmds]

@KathleenDollard are there some plans to add an option to install a global tool so it is usable for all users of a system? Is there an issue that tracks such a feature?

[tmds]

are there some plans to add an option to install a global tool so it is usable for all users of a system? Is there an issue that tracks such a feature?

@KathleenDollard ping