dotnet-publish with --use-current-rid or --infer-rid option

[am11]

At present:

dotnet publish -c Release path/code -o path/app /p:PublishSingleFile=true

throws error:

error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. Please either specify a RuntimeIdentifier or set SelfContained to false.

which requires a fix like:

dotnet publish -c Release path/code -o path/app /p:PublishSingleFile=true -r osx-x64

It is fairly a common usecase to publish an app for platform with same RID as host.

However, the error is good to keep it an explicit and conscious decision of user; instead of falling back to some default value.

Please add --use-current-rid or --infer-rid option for automation and documentation convenience.

This way user will still explicitly specify RID option, without supplying platform specific value.

[TheButlah]

It would be awesome if this could be configured in the .csproj too

[livarcocc]

@peterhuene can you help out here?

[peterhuene]

@livarcocc as a feature for 5.0?

[livarcocc]

That's what I had in mind, though I imagine we should spend some time figuring it out exactly. cc @KathleenDollard

[dasMulli]

IMHO this is a reasonable request, the SDK already does some RID inferring, even for non-rid-specific builds, and generates a host in 3.0
Seems like a reasonable extension that PublishSingleFile or UseAppHost should also use an inferred RID by default or at least provide an option to infer the RID.
Could also be useful in multi-leg CI builds running off the same scripts.

[TheButlah]

For what its worth, the use case for me was that the codebase I was working with was being migrated from .Net Framework. It expected .exe files to be in certain locations. This meant that an rid had to be specified to get an actual executable file. On linux and mac, the executable was renamed to end in .exe

However, I want it so that simply doing a dotnet build will produce an exe, as simply building and producing dlls breaks the code as it expects to have executables. Hence, specifying inferCurrentRID in the .csproj would be helpful, as it would force the code to output actual executable artifacts during a build and not just when publishing or manually specifying the RID

Obviously hard coding the RID for a particular platform is not an option, as the code should be able to build and run on any os.

[tmds]

However, the error is good to keep it an explicit and conscious decision of user; instead of falling back to some default value.

+1

It's good to make explicit what rid the published artifacts are going to work on. Especially on Linux, where users may expect publish to mean linux-x64. If you're on Alpine (which isn't linux-x64, but linux-musl-x64) your published application won't work where you expect it to.

source-build .NET Core will be producing artifacts which are likely to not be compatible with linux-x64 either.

CC @dagood @omajid

[dasMulli]

I want it so that simply doing a dotnet build will produce an exe

Did you try the 3.0 previews already? You should get a .exe for non RID-specific builds as well.

Building / publishing for a specific RID and generating an apphost (.exe on windows, mach-o executable on macOS, ELF binary on linux) are not necessarily both necessary.

The SDK is capable of emitting a host binary for the current RID even for framework-dependent deployments so you don't absolutely have to build a RID-specific application if you just need an .exe file for some tools. It should be default as of now and can be opted into using by adding -p:UseAppHost=True to build/publish commands. (Or add an <UseAppHost>True</UseAppHost> to a property group in the csproj).

The difference is that assets restored from NuGet are filtered for the target RID and you may end up with platform-specific native and/or managed libraries for that target RID.

For example, you can add SQLitePCLRaw.bundle_e_sqlite3 to a .NET Core 3.0 console application and run dotnet publish -o ..\pub-out and you'll find an .exe and a .dll in there so you can run the .exe file on windows, but you'll also find a runtimes folder containing lots of assemblies for 32/64 bit windows, macOS and multiple linux variants so you could copy the output to another machine and run it with dotnet theapp.dll.
If you publish for a specific RID, only the assets for this RID will be deployed so publishing - e.g. a RID-specific framework-dependent app can be created with dotnet publish -r win-x64 --self-contained false -o ..\pub-out-win which also contains an .exe and a .dll, needs a .NET Core runtime installed, but only contains SQLite dll files for Windows.

[dasMulli]

Sadly there is no way (@peterhuene / @nguerrera correct me if I'm wrong) to specify a RID for the app host generation without forcing NuGet to create a RID-specific package / asset graph and e.g. create a framework-dependent deployment with a convenience host for different platform.