dotnet new console, publish, makes a dll not an exe

[danmoseley]

C:\PLAy\asdf>dotnet --version
2.0.0-preview1-005694

C:\PLAy\asdf>dotnet new console
The template "Console Application" was created successfully.

C:\PLAy\asdf>dotnet restore

...
C:\PLAy\asdf>dotnet run
Hello World!

C:\PLAy\asdf>dotnet publish
Microsoft (R) Build Engine version 15.2.47.30403
Copyright (C) Microsoft Corporation. All rights reserved.

  asdf -> C:\PLAy\asdf\bin\Debug\netcoreapp2.0\asdf.dll

Shouldn't I have a console .exe? How do I run this dll?

[omajid]

Does dotnet bin\Debug\netcoreapp2.0\asdf.dll work?

Edit: dotnet publish --self-contained should generate an exe, though: dotnet/cli#6234

[benaadams]

If you add

<RuntimeIdentifier>win7-x64</RuntimeIdentifier>

you get a apphost.exe as only exe but when you run it it says it

This executable is not bound to a managed DLL to execute. The binding value is: 'c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2'
A fatal error was encountered. This executable was not bound to load a managed DLL.

and you have to run it with dotnet xxx.dll which isn't expected

e.g. if you were following UsingYourBuild.md#change-project-to-be-self-contained from coreclr

[danmoseley]

@omajid yes,

C:\PLAy\asdf>dotnet bin\Debug\netcoreapp2.0\asdf.dll
Hello World!

The project does contain <OutputType>Exe</OutputType> so I guess the bug is that it doesn't work.

[dasMulli]

.net core apps aren't supposed to be ".exe" files as this is a windows concept. When a portable app is published, the resulting .dll is supposed to be run on the target platform through dotnet app.dll which will then use the platform-specific runtime.

In project.json, the property was emitEntryPoint: true. In csproj, <OutputType>Exe</..> has existed before and should rather be interpreted as Executable rather than .exe file..

Tooling already exists for OutputType, yet it would be more clear if there was <Runnable>true</..> (which would internally just set the output type).

[livarcocc]

The important concepts here are that of a portable app (which is what you get by default) and self-contained apps (which are the ones for which an exe is produced).

A portable app is an application that runs independently of the platform and require that you have the shared framework installed. When you published it, the shared framework bits are not copied to the publish folder, including the native host. So, in order to run it, you need to do dotnet <path_to_your_dll>. dotnet in this case is the native piece, the host.

For self-contained apps, when you publish it you need to specify a RID (the distro you want to publish to, so that we know which native pieces to copy). In this case, because we will know your distro, we will generate an exe for you that you can then use for that specific platform.

This is a by design behavior.

[danmoseley]

Can we reduce the confusion somehow? I work on .NET Core and I was confused.

1. <OutputType>Exe</OutputType> reads exe but does not correspond to an exe. That's clearly confusing. Are we really out of options due to back compat? Why?
2. Console Application is the name of the template. For 15 years in .NET that has meant an .exe. Can we call the template something else, that's meaningful?

@terrajobst

[livarcocc]

Sorry for the confusion.
The concept of portable and self-contained applications are actually old concepts in the .net core world. We have had it for a while. I think one part of the confusion is the expectation that .NET Core should be similar to .NET Framework, which it is not.

You can read more about portable and self-hosted apps here: https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/.

Also, at this point, I don't see how we could make changes to this without causing breaks for everyone building applications for .NET Core right now.

[richlander]

@danmosemsft This isn't new ... was in 1.x, too. It also isn't a compat thing. We have choices here, but most of them come back to this experience as the best choice. It's one of those "this experience has three awesome characteristics (drawn as a triangle) ... pick 2".

Here are the characteristics you can choose from.

1. Cross-platform applications (meaning you can take the folder and run on Windows, macOS and Linux), provided .NET Core is installed there).
2. Produces an exe (whatever "exe" means on your OS) by default (what you are asking for).
3. Produces an app that doesn't require .NET Core installed.
4. Small apps.

You can have all of them, but not all of them can be the default. I also lied. You can pick two of the 4. So, today, the default is 1 and 4. Standalone gives you 2 and 3 and you give up and 1 and 4. We could have an experience that was 2 and 4 but we don't. We could do it in such a way that you don't give up on 1 (with scripts). It's all a question of what the base of the process should be.

I'm being somewhat vague because I want you to think about the characteristics and determine for yourself why this is the case. I'm not going to explain it. It's important to have the "a ha" moment on what "dotnet publish" really means.

Thoughts?

[danmoseley]

That all makes sense -- the same project will only make an actual .exe or equivalent iff you choose standalone aka self-contained. Once you make an .exe or equivalent, you made your app runtime specific.

I think @dasMulli 's suggestion that ideally <OutputType>Exe</OutputType> in the 2.0 templates could be <Runnable>true</Runnable> which the targets just translated. But I'm going to guess that would involve a VS update to know to write the new name.

It is unfortunate that I'm not the only person who will have to go through this learning process :) Feel free to close

[benaadams]

Would have gone for 2 for <OutputType>Exe</OutputType> and give a (very informative) publish error if target runtime not specified.

Rather than sticks a bunch of dlls in an output folder and not actually produce an "exe".

Windows world use case: publish; open folder, what to double click on to run?

[benaadams]

Do understand the difficulty that that "exe" wouldn't be portable though 😢

[benaadams]

Could you output multiple?

dotnet publish

outputs

MyApp.dll
MyApp.exe
MyApp rwxrwxr--

[richlander]

@benaadams Good idea, but I'd rather not. While, this would allow all scenarios by default, I think we'd have a different class of confusion. For example:

• Can I use MyApp on both Linux and Mac?
• Why doesn't MyApp.exe work on 32-bit windows?
• Why doesn't MyApp.exe work on Mac?

That all said, it's very obvious that the current situation is not great.

I'll put one stake in the ground ...

Deployment choices should not be specified in the project file. The corollary of this is that multiple deployment options should be possible from one project file.

I continue to think that the launcher case (and also the cross-plat scenario) should be the default and the exe case should be opt-in. That said, it should be much easier and intuitive to do so than it is now. Also, EXE and standalone don't need to be conflated.

Fair?