.NET Core console app fails to run on Windows Server

Question

I have a relatively simple .NET Core console app. It has no external dependencies. I build it using the following:

dotnet publish -c Release -r win10-x64

It generates a \bin\Release\netcoreapp2.2\win10-x64 folder structure. This folder contains the a number of files and a publish folder:

I copy this entire structure to a Windows Server 2016. According to the dotnet --list-runtimes commands the server has the following runtimes installed:

Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

However, when I run my .exe file (netcoreapp2.2\win10-x64\LayoutAutomation.exe), I get the following error:

Error:
  An assembly specified in the application dependencies manifest (LayoutAutomation.deps.json) was not found:
    package: 'runtime.win-x64.Microsoft.NETCore.App', version: '2.2.0'
    path: 'runtimes/win-x64/lib/netcoreapp2.2/Microsoft.CSharp.dll'

If I try to run the exe from the publish folder (which seemingly has the entire .NET Core installation), it runs fine.

So how can I can't run the exe from the netcoreapp2.2\win10-x64 folder? The .NET Core is installed on the box - it should run.

@ATL_DEV Contents on [LayoutAutomation.deps.json](https://pastebin.com/pJBeThYA) — AngryHacker, Feb 05 '19 at 01:55
Possible duplicate of [Deploying .Net core console application to Debian server](https://stackoverflow.com/questions/49755677/deploying-net-core-console-application-to-debian-server) or [Published .Net-Core App won't run](https://stackoverflow.com/q/50735749/150605) or [Error Running .net core on Debian](https://stackoverflow.com/q/49179801/150605) — Lance U. Matthews, Feb 05 '19 at 18:06
@BACON I strongly believe this question is not a duplicate. Two of those questions are non-Windows related and one has a completely different solution. Although the Q&A maybe the same for multiple platforms, we shouldn't expect SO users and OPs to understand the similarities and differences between platforms to properly assess whether an answer applies to their particular platform. — ATL_DEV, Jan 11 '20 at 19:32
@ATL_DEV Why should it matter that those are non-Windows questions when neither .NET Core nor the problem described here are Windows-specific? Yes, if the author knew that they might not have needed to ask the question but, by the same token, tagging a question as a Windows as if that is significant to the question does not necessarily make it so; the community can make that determination much the same as they can provide an answer. Also, I know they changed the duplicate text recently, but at least on mobile it still indicates it's the answers, not necessarily the question, that are the same. — Lance U. Matthews, Jan 11 '20 at 19:52
@BACON, Assume this question didn't exist but the other two did. A Haiku OS user with no Linux experience would ignore it, since they believe it doesn't apply to their particular platform. Should the Haiku OS user be expected to understand the differences between the various platforms to determine whether the answer applies to their oddball OS? (I'm being very hypothetical here. Anyone goofing around with Haiku OS knows a enough to about other platforms.) — ATL_DEV, Jan 11 '20 at 20:02
@ATL_DEV _Would_ such a user necessarily ignore those questions? These are all .NET Core questions. .NET Core is cross-platform. So why would a user of .NET Core assume the `dotnet` command works differently on different platforms, or that a .NET Core question for a different platform _doesn't_ apply to their problem? Again, I'm not saying an author needs to know that before asking (they probably should, but learning is why this site exists, after all), but I do think it's fair for the community to respond with effectively "You may not think these problems are the same but they are." — Lance U. Matthews, Jan 11 '20 at 20:51
@ATL_DEV Also, this question is tagged with C# despite no mention of C# code or files in the body. If the exact same question were asked but for a VB.NET project would that be a duplicate or not? How about a client version of Windows or a Server version other than 2016? Or 32-bit Windows? Or .NET Core other than 2.2? Where does it end? At what point do these details serve to differentiate a question versus distracting from the real problem? (I'm not saying, of course, that people should provide _less_ details in their questions, just that not every detail or tag makes it a unique question.) — Lance U. Matthews, Jan 11 '20 at 20:52

score 10 · Accepted Answer · edited Feb 05 '19 at 04:03

The Publish command is one of the rare cases where Microsoft tools do what they claim to do—namely, publish the application to a specified location.

The files under the bin/release are compilation artifacts with local dependencies. Your server can't find the dependencies because those files are meant to be executed on your development machine. Those dependencies can be located in a variety of places and the compiler consolidates them in release folder.

The files under Publish are built for deployment, and depending on your publish settings, can be self-contained (default) or framework-dependent. You should copy the Publish folder's contents (or the entire folder) to your final deployment path. If you want to publish your application as framework-dependent, then modify your publish command like so:

dotnet publish -c Release -r win10-x64 --self-contained false

You can also add the -o flag to specify a deployment path.

.NET Core console app fails to run on Windows Server

1 Answers1