I created a NetCoreApp (v1.1) in Visual Studio 2017. When I compile it, I get a DLL produced instead of the expected EXE for the built project. I did check the csproj file and confirmed the output type is set to exe, but no dice.

Any ideas why VS2017 is still producing a DLL? I'm sure its a quick setting somewhere that I forgot... its also 1 AM. :)

5 Answers
5

.NET Core applications are supposed to be .dllfiles. OutputType set to Exe in this case means "executable" and does everything necessary to ensure that the output is runnable (entry point from Main() method, .runtimeconfig.json file). The resulting dll file is meant to be run using:

dotnet yourapp.dll

This dll file works across all platforms that are supported by the .net core runtime (windows, linux, macOS). This is called a "portable" or "framework dependant" deployment.

If you want really a .exe file, consider self-contained deployments. This will create an output that contains its own copy of the .net core runtime and an yourapp.exe file - but it also increases the size of the published app and it needs to be updated when new versions of the runtime are released.
Also, the resulting application only works on the operating system published for.

Starting with .NET Core 2.2 you can build Framework-Dependent Executables

Although building a Self Contained Deployment can be a good solution, it has its own drawbacks. (See R.Titov and Martin Ullrichs' answers on SCD-s.)

Fortunately .NET Core 2.2 supports the building of so called Framework-Dependent Executable-s, that are essentially a wrapper binary (.exe on windows) around the standard dll-s.

This way you have all the advantages (and disadvantages) of the standard Framework-Dependent Deployment (again, see Martin's answer), but you have a convenient way to launch it, without having to call it through the dotnet CLI.

You can publish your app as a Framework-Dependent Executable using the following syntax:

dotnet publish -c Release -r <RID> --self-contained false

Where RID is the usual runtime identitfier, e.g. win-x64 or whatever platform you wish to build for (see the catalog here).

If your app ends up in yourapp.dll name the bat file yourapp.bat and place it along side the dll. Now instead of dotnet yourapp.dll params you can call yourapp params

Note that the context of this answer is in-house tooling, so all the devs using the utility will have pretty standard dev machine setup. If this is to be distributed to external customer who running who know what on their boxes, the self-contained option is far superior.