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

[danmosemsft]

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: https://github.com/dotnet/cli/pull/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

[danmosemsft]

@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 . 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.

[danmosemsft]

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?

[danmosemsft]

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?

[richlander]

@danmosemsft The primary problem isn't VS updates. It's that the EXE output type really means "application". It's the entry point into a variety of publishing types. It doesn't mean ".exe". If we're going to change something, I'd make it "app", which would make it clear that we are talking about a logical concept. Hey, that's a good idea!

The primary issue, as I said above, is that this choice isn't a project-level concern.

[benaadams]

dll launcher is covered; self-contained is covered; however I'd argue that there is an expectation for a targeted shared runtime exe (as you get from full framework and netcoreapp1.0-1.1)

The biggest issue with not having a local exe is the OS limitation on expressing what is running I raised as issues https://github.com/dotnet/cli/issues/6279, https://github.com/dotnet/core-setup/issues/2007

This is where the OS picks up info about what is running from the exe file e.g.

The exe provides an entry point for process name, process description and icon which is lost with just the launcher

[svick]

Would it make sense to include a platform-independent launcher with a framework-dependent application?

I can imagine doing that by creating a shell script that calls dotnet (for Unix) with a unique extension (for Windows).

Specifically, running dotnet publish for framework-dependent deployment would create something like MyApp.dotnet with the contents of:

#!/bin/sh
dotnet MyApp.dll

On Linux and macOS, this should run the installed version of .Net Core. On Windows, the .dotnet extension would be registered with dotnet.exe, which would ignore the contents of the file and execute MyApp.dll.

This way, double-clicking MyApp.dotnet on Windows and ./MyApp.dotnet on Unix would both work.

[mellinoe]

It's a clever idea, but I don't know if it's worth it for the relatively small benefit. I'm also worried that getting into the business of OS file associations is going to be clunky and bug-ridden, but maybe that's just my pessimism. 😄

[benaadams]

Actually, still not sure why this doesn't produce an exe

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <IsPackable>false</IsPackable>
    <OutputType>exe</OutputType>
    <NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-*</RuntimeFrameworkVersion>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  </PropertyGroup>

</Project>

Really not sure why it also outputs a apphost.exe that errors when you run it

publish>apphost
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.

[benaadams]

Ok updating to newest nightly and creating with dotnet new does create the exe

All good...

[JoseFMP]

So what is the key tag to get the exe? I really do not care to run "dotnet acool.dll" but legacy tools are expecting my application to have an exe file.

[borgdylan]

@benaadams On Linux, I am getting an apphost binary that fails as mentioned previously.

What happened to just renaming the coreconsole binary to get a working self-contained app? This new apphost methodology is a regression :/ .

[damircolak]

Same question here, I do dotnet publish -c Release -r win7-x64 and I get ONLY DLL.

How to create an EXE file?

If I target win10-x64 I do get an .EXE file but it won't run on Windows 7 because of this error:

Error: assembly specified in the dependencies manifest was not found -- package:
'microsoft.codeanalysis.common', version: '1.3.0', path: 'lib/netstandard1.3/Microsoft.CodeAnalysis.dll'

After googling for hours I still don't know how to fix that error.

Does building a simple EXE file really have to be this complicated?

What have become of the mighty Microsoft?

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>

    <RuntimeIdentifiers>
        <RuntimeIdentifiers>win10-x64;osx.10.11-x64;win7-x64;ubuntu.14.04-x64</RuntimeIdentifiers>
    </RuntimeIdentifiers>

  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
  </ItemGroup>
</Project>

[danmosemsft]

@livarcocc for feedback above (since issue is closed)

[damircolak]

Why did you close issue when it was not fixed? See my post for more details. I did check @livarcocc and it did not help at all.

[danmosemsft]

@damircolak I cited @livarcocc so he could see your comments. I think it would be better for you to open a new issue for what you're encountering.

[mattcanty]

@damircolak did you open a new issue for this? I am experiencing the same problem.

[AronParker]

Same problem here, is there a new issue regarding this yet?

[mattcanty]

@AronParker try the following:

dotnet publish -c Release

Now navigate to bin/Release/netcoreapp1.x/publish and you should see the exe in there.

Alternatively see if it's worth going up to .Net Core 2.0 as it appears to be supporting standalone applications as a flag on publish:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish?tabs=netcore2x

[AronParker]

@AronParker try the following:

dotnet publish -c Release

Now navigate to bin/Release/netcoreapp1.x/publish and you should see the exe in there.

Alternatively see if it's worth going up to .Net Core 2.0 as it appears to be supporting standalone applications as a flag on publish:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish?tabs=netcore2x

@mattcanty Thanks for your response! Although I still see .dll files even when compiling with dotnet publish -c Release, could that be because I'm on .NET core 2.0? And yes indeed I've seen that you can make a standalone package which does an exe, however it contains the entire .NET core files which I don't really want.

[ghost]

I agree with @AronParker . Exactly the same things happen to me. Why is this closed?

[danmosemsft]

Reopening just so @livarcocc and @richlander can see the feedback. Although, this is by design - see @richlander 's explanation: https://github.com/dotnet/cli/issues/6237#issuecomment-293425139

[tasoss]

sigh...thanks @danmosemsft

[dasMulli]

I wonder if sth simple can be done here to help out. The scenario seems to be "I want to double-click something" (correct me if I'm wrong) which can be easily done by creating a .cmd and .sh file calling dotnet foo.dll..

[mattcanty]

Am I missing any special reason why everything cannot be bundled up inside
the executable somehow.

Coming at this from a totally naive viewpoint...

If you wanted an executable package containing the supporting libraries,
why would you ever want those as individual files that you also have to lug
around.

On Mon, 28 Aug 2017 at 20:10 Martin Andreas Ullrich <
[email protected]> wrote:

I wonder if sth simple can be done here to help out. The scenario seems to
be "I want to double-click something" (correct me if I'm wrong) which can
be easily done by creating a .cmd and .sh file calling dotnet foo.dll..

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/6237#issuecomment-325449456, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB_ibRjTwEa5udh5x8USruiqfIHkziDQks5scxCRgaJpZM4MyTtj
.

[warrenrumak]

Gotta say, I'm scratching my head over this one too.

This isn't a new problem. Wrapper creators for .jar files that package them into Windows/Linux/macOS executables have existed for 15 years.... JSmooth, Jar2exe, launch4j, and others are all are actively developed and used in the Java world.

These tools exist because it has long been understood that it is necessary to provide a smooth execution experience for end-users. This is doubly true for people who write command-line utilities. If that tool isn't easy to reach, folks just won't use it.

Asking people to type "dotnet" before running my command-line tool would be like asking a gamer to type "directx" or "unity" before running my game.

Ideally, "dotnet publish" would provide these wrappers based on the requested RID(s).

[mellinoe]

Asking people to type "dotnet" before running my command-line tool would be like asking a gamer to type "directx" or "unity" before running my game.

Ideally, "dotnet publish" would provide these wrappers based on the requested RID(s).

This does happen. If you publish for "win-x64", you will get a native Windows executable which can be run by double-clicking it. If you publish for "linux-x64", you will get a native Linux executable (extensionless ELF file) that can be run directly.

[livarcocc]

@mattcanty that is not possible because an executable that works in one platform won't necessarily work in another (like a windows executable and a linux one).

@warrenrumak If you provide a RID and are building a self-contained application, we will publish an executable with the application name in the publish output folder.

[livarcocc]

See now that @mellinoe posted with me!

cc @KathleenDollard

[danmosemsft]

Maybe it's just a discoverability/convenience issue. I didn't originally discover dotnet.exe publish -r win-x64 and we don't seem to expose the list of RID's in the help.

[benaadams]

Or the just to be sure:
dotnet.exe publish -c Release -r win-x64 -f netcoreapp2.0

RIDs in help
TFM in help

Maybe cli should offer common selection on a help param; with link to look up more?

[danmosemsft]

Yeah, I meant -? help.

[dasMulli]

There is probably a distinct scenario here: wrappers to allow calling ./theapp in a RID-specific but not self-contained publish. While it is currently possible to creat such a deployment (dotnet publish -r RID --self-contained false), there is room for a few extras here:

1. .bat file for windows which just calls dotnet exec theapp.dll and an extensionless shell script to do the same on *nix
   
   
   
   • These can also be used for portable applications since they don't conflict with each other.
   
   
2. RID-specific executable (PE/ELF/mach-o) that contains a build of core-setup that acts like the muxer assembly to use hostfxr to boot the desired runtime. This could work similar to the current msbuild sdk resolver which looks for the muxer in the PATH.

That could be called via dotnet publish -c Release -r win-x64 --self-contained false --create-launcher.

[warrenrumak]

@mellinoe

It sure does, then I have to package, what, 60MB of DLLs with each executable? No thank you. You cannot convince me that this is a good path forward, especially if I want to build several command-line tools or small GUIs. Now instead of asking the user for, say, 1MB of disk space for ten small tools, I'm asking for 600MB?

What's being asked for here is a middle-ground between -f and -r: An executable that uses the installed runtime. You know, like we did successfully for 15 years....

[mellinoe]

@livarcocc Isn't there a way to produce a framework-dependent deployment but still get an executable launcher?

[livarcocc]

@eerhardt will the feature you implemented address this?

[eerhardt]

No unfortunately not. Even when you publish '-r RID --self-contained false', you still run on the shared framework. And today to run on the shared framework, you need to be invoked with the 'dotnet' host executable.

We could add a feature to the apphost executable to know where to find the shared framework when it is invoked and the coreclr doesn't exist in the same directory. An issue with that is there is no "global" location on non-Windows. We have %PROGRAMFILES% on Windows, but there isn't currently the same well-known global location on Unix.

[AronParker]

How about adding a custom file extension called .dotnet, which will be registered to run the runtime with the specified file?

[sporty81]

How about on any build or publish you just automatically create a ".bat", ".ps1" or some other file that does the "dotnet myfile.dll".

It could even be named myfile.exe.ps1

On publish if you wanted to auto-create a Linux flavored one, you could do that too.

[keith-miller]

Might be a dumb question, but is there a .Net Core 2.0 version of this document?

https://docs.microsoft.com/en-us/dotnet/core/deploying/

We're working on cross-platform standalone build and would like to know the right way to keep dotnet build working and building a proper DLL and have dotnet publish create the standalone executable. As it stands right now I can only seem to make a DLL that works fine with dotnet my_app.dll or a standalone executable with dotnet publish but the build DLL complains about missing libraries.

Thanks!

[keith-miller]

Ok, so part of my issue was that dotnet restore wasn't being called. That solves the dotnet build issue. But running dotnet publish -r osx.10.12-x64 with OutputPath set builds a standalone executable without dependencies in the OutputPath that doesn't work, and under that in publish a standalone executable with dependencies that does. I can work around that but it seems odd to have both.

[btory]

I'm surprised that there aren't more people complaining about this.

Currently a self-contained deployment appears to be the _only_ option if you want an executable. What if you don't want your deployment to include potentially hundreds of megabytes worth of .NET Core components though? Why is there no ability to generate a RID-specific app host executable that uses shared components?

[benaadams]

Why is there no ability to generate a RID-specific app host executable that uses shared components?

Guessing discovery of the shared components? They are relative to dotnet in path; or relative to exe for selfcontained

[ms0713]

@btory Why is there no ability to generate a RID-specific app host executable that uses shared components? I agree. I m able to do the same for 32bit RID only. For 64bit RID, it gets build successfully, but I m not able to run it. Let me know if you find any other solution to make it work.

[eerhardt]

Why is there no ability to generate a RID-specific app host executable that uses shared components?

Guessing discovery of the shared components? They are relative to dotnet in path; or relative to exe for selfcontained

Correct, that is what is blocking this scenario - See my comment above

[dasMulli]

We have %PROGRAMFILES% on Windows, but there isn't currently the same well-known global location on Unix.

I guess it could be done similar to how the msbuild sdk resolver works - find a dotnet on the PATH and try from there (IIRC).

[ms0713]

My .net core 2.0 console application runs properly in Windows OS. But I m having problem running it on RHEL7.

In my .sln file, I have 6-7 projects (.Net Stansard Library 2.0). Some projects depends on some other. But my solution file does not contain any word like postProject.

When I run following command, it gives no error and command prompt comes back without doing anything. Also it gives no error or nothing.
$ dotnet AppName.dll 1
1 is command line argument.

My application uses SQL connection, Reflection, Third Party dlls( developed in c++), socket connection etc.

I also tried running a demo application with command line arguments, SQL connection. It works fine in RHEL7.
My application dll has version like 1.2.3.4.
While Publishing my code, it gives target runtime as Portable. But another sample with target runtime as Portable wotks fine in RHEL7.

What could be the problem? If you have any idea regarding this please share.

[danmosemsft]

@ms0713 please open a new issue for this instead. Try setting COREHOST_TRACE (export COREHOST_TRACE=1) and then running again. do you get extra output?

[danmosemsft]

Oh, I see you already did.

[CharlesOkwuagwu]

VS2017 should really provide a simple way to generate a console application (.EXE) regardless of the selected framework, .NetCore 2.0, Full, Standard, etc.

Just a thought ...

[gbfromhb]

Did I read this whole thing right? There is no easy way to make a .net core console exe file from Visual Studio without all the .net core files that are already on the machine it is getting deployed to?

I see all this other stuff about other operating systems, and that is good and all, but you have a loyal base of programmers who have been working at this in a completely Windows environment for many years, and if you can't get this to work as easy or close to as easy as it has been, and it is very time consuming to migrate. You open the door for people to look at other solutions besides .net Core.

[KathleenDollard]

Thanks for the ongoing feedback. We're continuing to contemplate improvements to the confusion on Windows.

[gbfromhb]

Thank you for your response @KathleenDollard. figuratively speaking I may have been on the back end of one more thing I could not copy and paste code from an old project since I've been working with .net core. The statement may have been a little over the top. I started a fairly large new project and made the call to jump early thinking the early adventures would still be less then refactoring later. Well it has been a tough haul, and until 2.0 I was concerned I made the wrong choice.

I've been at this core adventure since 1.1 and a big advocate. With more then a few times colleges asking me why something is taking so long as I had to learn a new way of doing something or find a workaround in the early days for more then a few things, and I would say it is all going to be worth it.

I understand the quest of making everyone working on all operating systems feel that an equal effort is being put forward for the operating system they work on, however there is a base of customers that need to be able to feel like what was as easy as before, will be close to being as easy as it was. This experience feels like when John Sculley started running Apple and they had a huge base of customers that were in the Graphic arts and artistic industries and he went after the big business community with a broader swipe, and their base customers felt they were not being listened to and I'm sure this was not the only reason as to why it did not work out for him at Apple, but I think it was a factor. Yes, I've been around this long.

Don't think I'm not going to embrace being able to port my code to other operating systems. I have about 12 Raspberry Pis around the house doing everything from Media players, a MySql database server for the media players, security cameras, a security hub, to running Samba as domain controllers with Active Directory. When I have time I'm going to be putting together my first .net core app to run on a Raspberry Pi, and I can't wait. I guess what I'm saying is this has to be easier and more productive for existing .net users to move from the old .net to the new.

[tamusjroyce]

So .net core console app does not package any native executable launchers? Without being able to directly launch anything, it is not a console app. You could, however, include a OS specific script to act as a launcher. Could also include OS specific executable to launch it. Or change Mac, Win, and Linux to recognize and launch it as an assembly through a runtime.

But as-is, this project type's intended purpose is broken. I am hoping someone sees this as an oversight and corrects it.

[benaadams]

So .net core console app does not package any native executable launchers?

It does if you specifically target a platform as a standalone app; but then it also includes the whole runtime so increases the size 40-90mb (depending if you illink it or not)

[tamusjroyce]

If you target .NET framework standard, often using preprocessor directives, it is no longer .NET core. Still broken. Unless you mean something different?

[tamusjroyce]

Possible work-around: Would it be possible to have three separate .NET standard projects, each targeting Linux, Mac, and Windows respectively? And those each reference your .NET core console app? Will this add the native launchers?

[manigandham]

@tamusjroyce

.NET Core being cross-platform means the final executable varies and is excluded from the normal build. This allows the output to be used across any platform and run via the dotnet command.

If you definitely know the platform you want (ie: Windows), then you can generate the executable by specifying this in the build command: dotnet.exe publish -r win-x64 will give you an executable file for Windows. You can pick the "RID" for the platform(s) you want to generate executables for from the full catalog available here: https://github.com/dotnet/docs/blob/master/docs/core/rid-catalog.md

The side effect is that the runtime is also included (more DLLs) along with the executable, so the published output folder will be larger.

[dasMulli]

There already is a host that can run a non-selfcontained RID-specific build output. If a user does a dotnet build -r win-x64, the bin/{Configuration}/{TFM} folder already contains a {project}.exe and "only" a hostfxr.dll and hostpolicy.dll.

While a dotnet publish -r win-x64 --self-contained false creates a RID-specific build, it does not include this host, --self-contained true (default) adds that host but also the full framework.

Maybe this can be extended to allow something like dotnet publish -r win-x64 --self-contained false --include-apphost to perform a RID-specific build with publish semantics that includes a host (exe + hostfxr/hostpolicy) but not the entire framework.

The current workaround would be to do a dotnet publish -r win-x64 --self-contained false followed by dotnet build -r win-x64 and then manually copying the .exe and hostfxr/hostpolicy to the publish output.

[gbfromhb]

From within Visual Studio was what I was talking about, not command line.

[AdamJamesNaylor]

Just wanted to add to the demand here. I was surprised to see no .exe in the output folder.

My ideal use case would be a console app that gets compiled to an .exe (when requested) and runs against the shared framework. (Appreciate your comments above about the difficulty in locating the framework outside of windows)

[agnibos]

everything described here makes sense, including the necessity to do a dotnet bootsrapper for cross-platform dll entry point, however, a PRACTICAL solution would have been an option in tooling to auto-generate myapp.exe for win and myapp(sh) for *.nix automatically, in this case you would have generated:

• myapp.dll - a clr code image
• myapp.exe - 4kb bootsrapper for win64x
• myapp - 2 line sh script that does dotnet myapp.dll ...

[KathleenDollard]

@agnibos,

Clarification: Do you want two outputs? Do you want better switches so you have these options via switch? Do you want all three by default?

Thanks, We have this on our mind as well, but we want to get this right.

[dasMulli]

@agnibos any reason to have the .exe instead of a bat/cmd file like the sh script for *nix?
That way the PATH on windows will also affect the resolution of the framework which is useful for build scripts or custom ENV setups when you just add some local copy / dev build etc. to the PATH and get going. Same for 32 vs 64 bit - whichever is on the PATH first will be chosen.

[itadapter]

@dasMulli the only thing to be careful about, and maybe it is not an issue at all (which I cant judge about of the top):
if you do a .bat/.cmd wrapper then gotta make sure that all args and stdio streams get handled as-if cmd did not exist, that is, consider something like: tool.exe a1 a2 -abcd | tool2.exe --fast < myanswers.txt

still it would have been awesome to have a native stub a-la .NETf *.exe named the same as "exe" dll,

• myapp.dll
• myapp.exe <--- have a simple switch or task in build to create the executable like or something, then if you add it, it creates a stub without "bat files"

[agnibos]

@KathleenDollard
let me give some practical reasoning based on net core adoption patterns.

what we have seen in our dev user group - the first and primary "shock" of net core vs/tooling demo (for seasoned .NET devs) is not the lack of some win-specific stuff but that folks can not get exes to appear.
It is a culture shock!!! especially for legacy windows devs who have been around since 2000s.

What would be nice is a msbuild step/target (or whatever is the proper MSBuild lingo) that would pack the win-specific entry point AND it does not have to be as complex as RID-specific "publish" process.
Basically, in java there are cli bundlers for making an exe out of jar files.
Can we just not create this as a build step? it is important to have this as a part of "f5" in VS :)
This is very important to curb the initial netcore adoption fear for businesses. It is silly, but it is what it is.

There gotta be some kind of quick EXE gen way especially for scenarious like we have: we build whole solution using msbuild/vs, deploy the /out/fx folder without any dotnet steps. And everything works. What sucks is req to type-in dotnet mytool.dll every time, whereas in /out/netf we just type tool -abc

However, there are other issues in case of EXE stub to be concerned about. Firstly, the EXE header flags, stack size, linking address all of that stuff. If we use EXE merely as a shortcut to dotnet *.dll then we need to think what this EXE and consequential process attributes are going to be... i.e. we can not just create a 32bit process that forks to 64 bit dotnet host.... so probably the msbuild task/step has to take some exe-specific options.
On the other hand, someone mentioned that win-specific EXE would contradict *nix etc.. it does not, as we can take the files built on Linux and put it on Windows to run.... otherwise dot include the EXE option in build

[KathleenDollard]

@agnibos Thanks for your input.

The dotnet foo approach runs a patched version if available. The .NET Full Framework (.NET 4.x) also runs patches. This seems important, do you agree?

One solution to the dotnet version issue is a script (batch file). But would that solve the confusion you describe?

[gbfromhb]

No.

[dasMulli]

@KathleenDollard even the rid-specific host that is put into the RID-specific build (not publish) output should also roll forward since that logic is afaik implemented in the hostfxr.dll that is included in the build output.

Maybe core-setup could produce a statically linked version of the hosts so you don't need to copy the two dlls (hostfxr.dll, host policy.dll) around.

To be clear, the dotnet flags (-r win-x64 etc.) I posted earlier can all be set as defaults in the csproj files (=> <RuntimeIdentifier>win-x64</…>), VS just doesn't have UI for most of them.

[warrenrumak]

Batch files can't have an icon, can't be used as a Windows Service, can't be pinned to Start, can't be a Taskbar item, can't have Compatibility settings, can't have a version number applied to it, can't be digitally signed, can't be the target of a call to ShellExecute()......

It's not a solution.

[itadapter]

When we run classic .NET exes, how does the system load proper CLR? Why can't that be the case with centrally-installed dotnet core? I think there is confusion with self-contained runtime deploys. What most of devs want is similar behavior to regular NET: you have a machine wide core installed, and have exe that you run it locates the latest entry point and launches it, and yes, it is Win-specific, would be nice to have symmetrical ELF stub on Linux

[dasMulli]

The current exe stub is linked against a dll shipped in windows which finds&loads a CLR or prints an error message.

Problem is that "a machine-wide" install isn't how .net core works. "a" > multiple side-by-side versions, "machine-wide" > a folder with a dotnet.exe somewhere that is in the PATH

I hope I don't confuse "self-contained" with "RID-specific" too much.

[itadapter]

@dasMulli thats all understood, but in many cases this complexity (side-by-side fxs) is not needed. In many case you want to have one core on machine a-la one clr. that simple. Is this not how .core install works now? This is how we use it. Install the runtime, test everything and use it.
Then the EXE/ELF stub should work exactly as classic .NET worked - it should find the dotnet in path and use that, whatever version it is. Otherwise, override your DOTNET-PATH var or something.

[dasMulli]

Agreed, this is what the current RID-specific non-self-contained host does (.exe with the 2 dlls that) does (and what doesn't work with dotnet publish well right now).

At the moment, the side-by-side install is probably most needed for .net core 1.* vs 2.*. Major versions don't roll-forward at the moment. In Full .NET, this is similar to the 2.0 vs 4.0 CLRs, but now that 2.0 isn't really used anymore and 4.0 has a good level of compatibility, it hasn't caused much dev concerns lately.

It's going to get a little more complicated now that ASP.NET Core is moving from a runtime store to a shared framework similar to .net core itself (So you'd get another folder next to Microsoft.NETCore.App in the shared folder next to dotnet.exe) which has similar loader concerns. Since this will be transparent with an update to dotnet.exe/hostfxr/hostpolicy in the global install, apps run with dotnet foo.dll won't notice any difference but the RID-specific host I talked about will need an update. So as long as parts like this change every year or so, it's going to be difficult to ship native binaries that work against the "global install".

[agnibos]

The "one central core" logically is what many users need. same way it was in .net, t4 it makes sense to create a entry exe without all those rid complexities. Also, please make it an option that it creates it on build from VS/vscode without having to run any command line packers manually

[Genbox]

Self-contained applications should produce an EXE file on Windows which replaces the DLL file entirely. There is no need for distributions to have both, and it only creates problems like this one https://github.com/dotnet/cli/issues/7452

Similarly, it should be ELF on Linux and Mach-O on Mac OS.

[gforceg]

I can generate an exe easily enough w/ a command like: dotnet publish -o pub --self-contained -r win10-x64, but unfortunately when I move that "self-contained" binary into a folder in my path and try to run it I get the error: A fatal error occurred, the required library hostfxr.dll could not be found at <a directory in my path>

I guess self-contained means "self contained across many files in the same directory?" I don't want to pollute the folder with a bunch of .dll files. Publishing as a dll doesn't seem to help either. If the dll is placed into my path, dotnet can't find it ('dotnet myApp.dll') unless myApp.dll is in the same folder I'm working in.

The work around seems to be, create a whole new folder and add THAT folder to my path then publish to that folder. (this is messier than I'd like)

is there another publish flag I can use to get an exe that will run in windows w/o any dependencies that live in the same folder?

[benaadams]

Could install of runtime/sdk set the common path in an environment variable? Then use the environment variable for platform specific exes; that aren't self contained? (e.g. where the common/shared runtime dlls are)

[Genbox]

@gforceg self-contained just means the runtime is published with your application. You have to go to the publish folder within the win10-x64 folder to see the self-contained version. For now, .NET Core does not officially support static compilation (compiling all the DLL files to a single EXE file).

You might find this blogpost helpful: https://ianqvist.blogspot.com/2018/01/reducing-size-of-self-contained-net.html

The only other alternative is to create an installer for your application.

[tamusjroyce]

I still see having compiled code without an individual launcher is not a usable program. And thus an issue. The launcher could be a script or executable. Those are details I would rather leave up to the person(s) who to resolves this.

Whatever is decided, I would like it to be robust? And I really like the idea of being able to targeting one or more systems based on a selection. Or even with each targeted system, being able to select a scripted launcher, an executable launcher, or both. To be fully featured. Not necessary to resolve this issue. But would be greatly appreciated.

I also appreciate that there is a desired feature for .NET core to combining multiple assemblies into one. I don't believe that has bearing on this issue. But good to know!

Note: Powershell could be a cross compatible dependency to the launcher. Or bash, with msys or bash for windows.

[livarcocc]

@benaadams if the runtime could be acquired only through an installer, that would solve the problem, but what about the archive scenario? I am not sure we want to build a runtime experience for things that work only when the PATH is set in a particular way.

[warrenrumak]

@Genbox Of course, one of the many problems of doing static linking is that security issues (like the one released this month for .NET Core) require you to recompile and redistribute your application. The unpatched vulnerability might also not be picked up by various scanner tools.

Also, more significantly, it cannot take advantage of the Windows NT memory manager's capability to share pages between multiple processes. It's fine if you're running multiple copies of the same program, but if you had, say, a dozen different utilities installed that each took a dependency on their own local copy of .NET Core, memory usage will be massively higher and load times will be longer.

[livarcocc]

cc @steveharter

[Genbox]

@warrenrumak You are completely right. However, every piece of software has different use cases, and in some of them, it does not make sense to deploy a bulky set of assemblies. I'm not at all a proponent of doing things inefficiently like having all applications statically compiled, but I have run into many environments and deployments where I had to find a workaround to deploy a .NET application, where static compilation would have been the right solution.

Static compilation is not the subject of this issue though, so let's keep it on topic.

[Genbox]

@livarcocc Java chose to create a handler for .jar and setting the environment variable JAVA_HOME. It is far from optimal but as long as applications are not registered in an ecosystem with an identity you can count on (like UWP apps) on different platforms, it is going to be a problem that can't be solved in a way that supports all use cases.

[itadapter]

can we just return the traditional .Net behavior with a simple exe stub loading whatever FX is on the machine? make this optional, just like a build step - a wrapper that calls dotnet under the hood

[fanoI]

I think the idea to simply create .net / .dotnet archive as does Java with .jar files has merits:

1. It is not biased on Windows, a .exe file on Linux / Mac OSX it is not "elegant" to see
2. Creating a stub .elf for any Linux distribution will be hell as any release of the kernel make the executable incompatible (it libc changes for example)
3. It is simple: net core on installation adds to the OS to execute .net files the OS must call "dotnet run .net". Side by side installations of dotnet should work in the same way they would do if I did "dotnet run .net" on the shell

I add another scenario in which a simple executable format will be needed: Cosmos OS.
A "self-contained" application would not have sense there as the .NET run time is part of the OS itself we will have a file of 3 MB for a simple "dir" command and we should discard / ignore the 90% of it.

[FrederickBrier]

A lot of this confusion seems to come from Microsoft documentation that tells how to generate an exe. Or this one that explicitly shows how to write and then register a ASP.NET Core app exe as a Windows service. Until I started reading this github issue, I was puzzled (and a bit frustrated) why all the doc about inserting and XML elements was not generating an EXE.

Since my interest is in deploying my .NET Core web app as a Windows service, and if generating an EXE is not an option, I tried to create my service with a command line that looks like this:

sc create MyWebApp binPath= "C:\Program Files\dotnet\dotnet.exe c:\MyAppDir\MyWebApp.dll"

So far, it seems to work.

[FrederickBrier]

I do like the idea of Self-Contained Deployments. I am currently using preview releases to gain access to the owned type facility in EF Core. Unfortunately, while EnsureCreated() works in my Visual Studio environment, when I deploy to the server, it seems to be using an older EF Core assembly included in the .NET Core SDK 2.1.0/2.0.5 installer and throws exceptions. Beyond the:

    <OutputType>Exe</OutputType>
    <RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>

What else do I need to do to have the app deployed as an SCD? Thank you.

[livarcocc]

@FrederickBrier You can either have RuntimeIdentifier (singular), which will make your app always self-contained. Or, you can pass -r win10-x64 (or some other rid) to the publish command when publishing your app.

[eerhardt]

See https://github.com/dotnet/core-setup/issues/3720 for the proposal on making the runtime support this scenario.

Note that there will need to be additional SDK/tooling work on top of the runtime support to enable the feature end-to-end. But having the runtime support is the first step.

[honkmother]

I just want to add my two cents to this issue so that the dev team understands how I feel: hhhhhhhhhhngggghhhhasdffffffffaaaaaaagfgnggggggggggghhhhhhhhhhhhhhhhgnnnnnnnghhhhhhhhhhhhhhhhhhhhh

[A9G-Data-Droid]

Following the documentation for making a SCD leads to just a DLL for console app. I see people complaining about having a to deploy a DLL with their EXE but I can't even get that. This process is broken and unclear.

https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-vs

[livarcocc]

Where are you looking at that you see only the dll? Note that in .net core, the build output is different from the publish output, if you are publishing your app and trying to distribute it, you should look at the publish folder.

[A9G-Data-Droid]

Yeah, I definitely looking at the publish folder. I cleaned everything up and tried multiple times with multiple settings. Then I just made my class library project target .netstandard instead. The console app is now targeting Framework 4.6.1. This way, my class library can be used in any project and my console app works as expected. After reading more about it I'll likely never touch .net core ever again.

[peterhuene]

@A9G-Data-Droid with .NET Core 2.0, an executable (we call it an "application host") is created for Exe project types if you build with a runtime identifier specified (the -r|--runtime option):

An example:

> dotnet new console -o example
> cd example
> dotnet build -r win-x64
> bin\Debug\netcoreapp2.0\win-x64\example.exe
  Hello World!

Currently, if you publish with a runtime identifier specified, i.e. dotnet publish -r win-x64, it automatically becomes a self-contained deployment, and the runtime-specific publish folder (e.g. bin\Debug\netcoreapp2.0\win-x64\publish) should contain an executable, as well its dependencies and the runtime.

We currently do not support publishing a framework-dependent application with an application host, but that is something I'm currently working on addressing.

[oliverjanik]

Can we get these instruction documented somewhere visibly?

Why do I have to hunt down the answer in some obscure Github issue.

Also I work form visual studio. Give me the stupid dll if you have to and the bloody exe for my current platform i'm on.

This project is infuriating. Death by thousand paper cuts. Everyone on dot net team needs to fired.

[oliverjanik]

Also your instructions are broken for me:

C:\Program Files\dotnet\sdk\2.1.201\NuGet.targets(114,5): error : Failed to retrieve information about 'runtime.win-x64.Microsoft.NETCore.DotNetHostPolicy' from remote source {private nuget repo}. [{my project}]
C:\Program Files\dotnet\sdk\2.1.201\NuGet.targets(114,5): error :   Response status code does not indicate success: 401 (Unauthorized). [{my project}]

Why, oh why, does it talk to my private package repository for and internal package??? Why doen't it just fetch it from nuget or wherever you expect it?

[livarcocc]

Documentation can be found here: https://docs.microsoft.com/en-us/dotnet/core/deploying/.

As for the error you are getting, NuGet does not discern feeds, it tries all feeds because you may have a better package in one of them and it won't know that until it has looked there.

Also, please keep the conversation civil and polity. We are all doing our best here.

[itadapter]

@oliverjanik I share your frustration, but dude you gotta give MSFT people some credit. They have rolled up pretty cool stuff very quickly and I can judge as I have been using MSFT toolset since 1994 Vb3/VCPP days :)

For these very reasons that you experience, I advise my customers to convert code to .NET Standard 2+ today, but host code in .NET framework process for now using Windows (it is in the company bloodstream anyway). I am sure MS will make this just right in 6-12 months! Right guys?

Thank ya all!

[peterhuene]

With the upcoming .NET Core SDK 2.1.4xx (release/2.1.4xx branch), we've added a --mode option to dotnet publish that has the following options:

• self-contained - publishes a self-contained application (same as
  --self-contained option). Requires a RuntimeIdentifier (i.e. --runtime) to be specified.
• fx-dependent - publishes a framework-dependent application. If a RuntimeIdentifier is specified with a target framework >= netcoreapp2.1, then it also creates an executable to launch the application with.
• fx-dependent-no-exe - publishes a framework-dependent application without an
  executable. This is the same as --self-contained=false.

The default when publishing without a RuntimeIdentifier specified (e.g. dotnet publish) is
fx-dependent-no-exe.

The default when publishing with a RuntimeIdentifier specified (e.g. dotnet publish --runtime win-x64) is self-contained. This is for backwards-compatibility reasons.

Unlike the .exe files created for Exe type projects when using the .NET Framework (which are always Windows PE files), executables created by .NET Core are PE on Windows, Mach-O on macOS, and ELF on Linux. This is why we need to know the target runtime to create the executable. Without it, the application is assumed to be portable and you can run on any compatible .NET Core runtime with dotnet app.dll.

We still have a review in progress for this feature, so the above may still change for 2.1.4xx, but we believe this will help users that desire framework-dependent applications with an executable to launch with.

So to amend the root example using a future 2.1.4xx .NET Core SDK:

$ dotnet new console
$ dotnet publish --runtime $RID --mode fx-dependent

Where $RID might be any supported runtime identifier. This would publish the application as framework-dependent (meaning a matching shared framework needs to be installed on the target machine), but with an executable you can use to run the application so you don't have to use dotnet foo.dll.

As such, I'm closing this issue as fixed with a new feature in 2.1.4xx. Please re-open or comment if you have any questions/concerns/feedback. Thank you!

[HenrikTP68]

My big confusion about this whole scenario is:

If I produce a framework dependent deploy then I need to install the framework runtime on target machine but as far as I can see the CLI is not part of the runtime installation, only the SDK includes the CLI so it's not possible to use runtime for framework dependent deploy?

If I need the SDK for a framework dependent deploy and nothing for a self-contained deploy, then where is the runtime installer used?

[dasMulli]

you only need the SDK (which is the branding of the CLI) to create the framework-dependent deploy (dotnet publish)

You only need the runtime to use the framework-dependent deploy on the target machine.

[HenrikTP68]

That's where I am confused.

When I make a framework dependent deploy of my app I end up with a .dll.
To start an app dll I need to run "dotnet myapp.dll" but dotnet.exe is not part of runtime install.

[dasMulli]

dotnet.exe is part of the runtime installers you will get from https://www.microsoft.com/net/download.
if it doesn't work for you, please open another issue where we can take this discussion.

[HenrikTP68]

Ah, ok - I will definetly look into that.
Every time I install runtime I have no dotnet exe or cmd anywhere on my pc (no diff if im installing on my home win 10, my work win 10 pro or my server 2016 datacenter or linux for that matter).

[wli3]

By default it should under C:\Program Filesdotnetdotnet.exe

[ghost]

@eerhardt @livarcocc @KathleenDollard

I think the real problem after reading this thread is that the runtime system wasn't designed with the same thought process you would have used inside your software code (as a programmer). You missed using crucial patterns, because you tried to shove _universal_ into a single box -- in the same way a bad program would shove too much into a single class.

The .NET Core dll project should be just that, a dynamic linked library. The library code written in .NET Core ready to run regardless of the platform. _Nothing more._ Alone, it cannot be run by any platform although it certainly contains the program's entry, hot path, main loop, whatever you call it.

We should also then be required to create templated bootstrap projects for each platform we want to publish against. We should NOT/NOT use confusing config files with ambiguous acronyms and abbreviations that push us into a single direction with the hope of _universal_ on the other end.

Bootstrap projects should be small and clean for us to write, but extremely helpful (i.e. key) to the builder and publisher to signal our intentions. The builder creates the published programs in whatever the need and is a best practice for that OS. If that bootstrap project directs the whole project to be wrapped in an exe file and uses Windows installed frameworks then that's how it should roll out of the build and publish. Other platforms get their own customized builds that work best for their circumstances.

That gives us the opportunity to write programs for _our_ intended audience. Not what you guessed our intended audience would be in 2017.

First, I know you have some dream of a single download that works on any platform. What you have now doesn't do that properly anyway. It also creates more headaches for us and for our users. Finally, platform specific downloads isn't a serious problem. It's minor issue compared to the mess created by this system.

Is using a bootstrap project for each platform a little more work? Sure. A little harder for us, but easy on our users. It will work as we intended. It's also explicit. It's also not brittle. What do you plan to do when another operating system or platform rises up? Will you expand your config file with more nearly secret codes? Is that the pattern you would use if we were just talking about a single software application with different domains?

Bring the pain now to fix this issue. It will not get better with age.

(as an aside, who would think a dll is _executable_ program or a _script_ after decades of it being a dynamic linked library?)

[svick]

@TheRealMal

The .NET Core dll project should be just that, a dynamic linked library. The library code written in .NET Core ready to run regardless of the platform.

How is that different from framework-dependent deployment?

We should also then be required to create templated bootstrap projects for each platform we want to publish against. We should NOT/NOT use confusing config files with ambiguous acronyms and abbreviations that push us into a single direction with the hope of universal on the other end.

How is that better than looking up the Runtime Identifier in the documentation for self-contained deployment? How would such project look like and how would it identify the target OS?

[tamusjroyce]

It isn't about identifying the target OS. But rather, launching the program. The question is, what is launching it? sh, bash, cmd, powershell, IIS, Apache, nginx? There are only a few mainstream ones that need supported. Why is this still be debated?

All a .exe extenion does is tells cmd to launch it as an executable. If it were me, for command line apps, I would make a launcher for sh and a launcher for cmd when making the project. And when you click play in visual studio, it runs either of those launchers and you can then debug and tune your application. Just like asp.net core uses it's own launcher.

May I ask why is any detection needed? Two launchers, sh and .bat, and one .dll that gets launched. (there may be several other dlls depending on how you build...but those details shouldn't effect much)

[ghost]

You're confusing an engineering problem with a user/audience concern. In so doing, you're making engineering arguments for what is really an issue about user (e.g. client) expectations.

I don't care if it's a target OS, xbox platform, whatever.

We need access to _instructions_ that direct the build and publish commands to a specification... regardless of sh, bash, cmd, powershell, IIS, Apache, nginx. Making those build/publish instructions work in a compatible way with those other systems is our job. Why? Because we (as the client facing developer) understand our audience, their needs, and their expectations.

Don't _assume_ a simple wrapper works. In some cases it might, in others maybe not.

[KathleenDollard]

First, we agree that you know best how to run your application and are working on giving you more options.

@TheRealMal You are correct that the .NET Core Runtime was not created with the same process you would use to create an application - because it solves different problems. Do not mistake this for a lack of thought. It is a deeply thought out system, and I think a very good design. Some other comments here reminds me that we largely think this set of details is implementation so do not talk about it much.

Shipped with the runtime is an app host. This and the .NET Core Runtime are platform specific. The app host is small, is named dotnet.exe, and there is one on your machine.

When you type dotnet xyz.dll the host finds the dll and selects the runtime to use executing it based on what it specifies and what is available on the machine. These need to be two separate pieces because it is common for them to come from different runtime versions. This is called a framework dependent application. Since this uses a copy of the runtime that is already on the production machine, it minimizes redundant deployed bits and allows patch uptake the next time you start the app. Your .dll is binary compatible across platform. You just create one and use it everywhere. It is also rather small, but you run in the dotnet process. The runtime must already be on the production machine, or dotnet isn't recognized.

When you create a self-contained application you specify the platform and the app host and the runtime are included in your application. These are quite large because the fixed size of the runtime is included. The author must rebuild and redeploy to uptake patches.

These are the two options available today.

The SDK/CLI is not needed on the production machine. I realize this is a bit confusing because dotnet runs your application and when the SDK is installed runs CLI commands and can run other applications via global tools. Other parts of .NET Core that are only present if the SDK is installed take care of routing to the right code.

I did not understand what this was in relation to:

We need access to instructions that direct the build and publish commands to a specification.

[KathleenDollard]

The fix to create a _dotnet framework executable_ that @peterhuene explained has been moved to the .NET Core 2.2.1xx release. This was because of problems found in testing.

You can see more in the PR to revert.

[ghost]

@KathleenDollard

I know all that. The issue you seem to miss is we aren't making the software for me.

The issue is the knowledge of the people who I make the software for -- _our clients_. People who might never have heard of github, msdn, or .NET, and if they did they couldn't care less. Your process modifies _their_ behavior and expectations with disastrous results.

There are important people out there who have been trained to expect certain responses from files that look a certain way. Even unix "power users" fill volumes of stack exchange questions about how to path and run simple scripts.

You invented "dotnet xyz.dll" without any thought to how people (i.e. non-engineer programmers) would respond to it given what they already know and expect.

[ghost]

I should add that any fix that results in getting less horsepower out of .NET Core during runtime is going to result in more acrimony.

[KathleenDollard]

@TheRealMal

It is not helpful to make unfounded and incorrect accusations about what people were or were not thinking. Being civil is helpful, appropriate and required by our Code of Conduct.

It is helpful to say this is very important to you and your users. Feedback is welcome.

We planned three models. Two were created first, and one of those allows an executable file. It has disadvantages, but you have an option today.

We had hoped the third model would be available in 2.1.4xxx. This model publishes an apphost in your application (allowing you to assign an icon, run in a process name you recognize and start with a direct call or double click), while relying on the the .NET Core Runtime installed on the production machine. This shrinks the deployment (compared to self-contained) and allows patches.

As I just posted here, that has been pushed out to 2.2.1xx.

You have mentioned scripts several time, and I am unclear where you think scripts are or should be involved. It is possible you have a concern that is not relevant to this issue; I'm happy to help straighten that out.

[ghost]

Fine, this is my last comment and then I'm crawling back under my rock.

Did you even consider the power of creating a .epub (e-book file) that produced all of the expected output to the reader, but actually encapsulated a little .NET engine inside doing the work and spitting out the expected output to the reader. If you give the mob the ability to create that kind of bootstrapped adapter some enterprising nerd will make it for you. Cheers.

[NimishDhruv]

I have one question related to self contained deployment.

I have created two console application named "ConsoleApp1" and "ConsoleApp2". Now when I publish the solution using self contain command "dotnet publish -c release -r win7-x64" the relevant files have been generated in their project bin folder along with "ConsoleApp1.exe" and "ConsoleApp2.exe".

My question is that If my project have two executable files then do I need to copy both the publish folder to production?
Or
Is there any other way where all the lib and executable files are copied to single folder from where we can copy that folder to production?

[ylhyh]

I have a project with COM reference, and the project must to be running in x86(32-bit) environment. so I have to use Visual Studio or MSBUILD to build the project. And I have to use:
"C:\Program Files (x86)\dotnet\dotnet.exe" MyWebApi.dll
to start it.

After I created a Publish Profile with RuntimeIdentifier and SelfContained specified, I have found that using Vistual Studio to publish the project will create an exe file named MyWebApi.exe, so I can run the exe file directly to start the web api and it will be ran in x86(32-bit) env. See the .csproj and .pubxm below:

BUT! If I use MSBUILD to publish the project with the PublishProfile specified, it's never to create the .exe file, who can tell me WHY?

MSBuild.exe" /p:DeployOnBuild=true /p:PublishProfile=Release-winx86-SelfContained

HELP !!!

The component versions of my project:
Microsoft.AspNetCore.App (2.1.1)
Microsoft.NETCore.App (2.1.2)
Vistual Stuio 2017 15.7.3

[vijayrkn]

@ylhyh - Can you please run the following command and share the output log?

MSBuild.exe" /p:DeployOnBuild=true /p:PublishProfile=Release-winx86-SelfContained /bl

*Please remove any sensitive information from the log (if present)

[ylhyh]

Thanks @vijayrkn. but /bl is not work

[vijayrkn]

When you pass /bl , it should create a log file in that folder, can you please share that?

[ylhyh]

@vijayrkn , see the binlog file @ https://github.com/ylhyh/TempShare/blob/master/msbuild.binlog?raw=true

[peterhuene]

I'm going to re-open this against 3.0 as we're hoping to unify the build / publish experience (while remaining backwards compatible) and make it much easier to get executables built for .NET Core projects.

For 2.2, we are enabling the application host (i.e. the executable) to be built when publishing a framework dependent (--self-contained=false application with a RID).

[tonecas]

just to bump up this issue. also had the same bad experience with this. not intuitive and very misleading for such a simple issue. spent a couple of hours to understand how this works. there should be a "portable executable" and a "stand-alone/self-contained executable" and the mention to "Exe" be removed.

[Banyc]

Try modifying the value of TargetFramework in file *.csproj into like net48 then you will get an EXE that can be run under .NET Framework 4.8 after executing the command dotnet build.

learn more here https://docs.microsoft.com/en-us/dotnet/standard/frameworks

[bugproof]

@peterhuene I would prefer to have a single exe (not a host + dll) on Windows like in .NET Framework. It looks really weird now.

[peterhuene]

@wrathofodin unfortunately that's not how .NET Core activation currently works. .NET Core is designed to be cross-platform and it needs a platform-native executable that cannot rely on special behavior in the operating system loader to work (like the Windows-only .NET Framework does for its executables).

We currently have no plans to change the design of application activation. .NET Core applications will still build to DLLs and an optional application host may be used to activate the application instead of dotnet exec.

While not the same thing, the 3.0 .NET Core SDK will have support for publishing a "single-file" executable that is essentially a packed version of your application that self-extracts to a temporary location (performed one time) before running.