Publish .net core console App as FDD not an option?

Question

I have multiple small helper console apps written in C# using .net core. When I try to publish them through Visual Studio I only have the option "Portable" in target runtime. I cannot deselect it. This makes so the output includes runtimes which I do not need.

If I try to use the CLI to publish running only the "dotnet publish -c Release" command it still includes the runtimes.

I have tried to update the .net core SDK and app to 2.2, which did not give me more options and Google is no help either.

Following is a csproj of one of the console apps: .csproj file

Following is my publish options in VS 2017: publish options

I have searched google for countless hours trying to find a solution. But every solution I have tried still includes the runtimes when publishing.

So this is my last resort and really hope that someone here has a solution.

Answer 1

When I try to publish them through Visual Studio I only have the option "Portable" in target runtime. I cannot deselect it.

Portable is (as far as I am aware) the Framework-dependent deployment (FDD) option in Visual Studio 2017.

If I try to use the CLI to publish running only the "dotnet publish -c Release" command it still includes the runtimes.

This official Microsoft documentation on publishing .NET Core apps with the CLI clearly identifies dotnet publish -c Release as the FDD option for the command line.

[T]he output includes runtimes which I do not need.

A bare-bones "Hello World" console application ( dotnet new console ) created in .NET Core 2.2 and published with dotnet publish -c Release produces four files in its publish folder (eg appname.deps.json , appname.dll , appname.pdb and appname.runtimeconfig.json ).

In contrast, a fully Self-contained deployment (SCD) of the same default "Hello World" console application published with dotnet publish -c Release -r <RID> --self-contained true (RIDs listed here ) has approximately 217+ files (212-non program .dlls) and is ~66mb.

I am uncertain if you mean these 212 .dlls when you say you have unnecessary runtimes. But if these aren't what you mean, then as a suggestion, you may wish to look into your own code (or the Enums and SharedHelpers projects, for example) for more insight into this issue.

Another option might be to simply de-duplicate any runtimes produced (eg use the same runtimes for multiple applications, as applicable).