Compile a .NET Core application as an EXE file using Visual Studio 2017

user_106397 0
Viewed 36270

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

Why is Visual Studio 2017 is still producing a DLL file?

I'm sure it's a quick setting somewhere that I forgot...

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

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

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <PlatformTarget>AnyCPU</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\Core.EF.SqlServer\Core.EF.SqlServer.csproj" />
  </ItemGroup>

</Project>
visual-studio-2017 .net-core
5 Answers

In Visual Studio 2017:

  1. Right click on your project and select Publish (In Visual Studio 2019, click on menu Build → Publish <projectName>)
  2. Select 'Folder' and create a new profile
  3. In tab 'Publish', click 'Configure...'
  4. Select Deployment Mode: Self-contained, Target Runtime: win-x86 (or win-x64)
  5. Save
  6. Publish

In the folder <Your project>\bin\Debug\netcoreapp2.1\win-x86\ you will see the EXE file:

Publish settings

user_14125920

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 identifier, e.g. win-x64 or whatever platform you wish to build for (see the catalog here).

user_106147910

That's how you do a self-contained publish with command-line in any OS:

dotnet publish C:\src\App\App.csproj -c release -r win-x64 -o output-win-x64

Besides, you might want to get the output decreased from typical ~60 MB for a simple Hello World app to ~30 MB by using ILLink.

Also, you might want to go further and get a single .exe file of a size at around 5 MB and use ILCompiler. See this reply.

user_4406960

The other answers are good, but what I find sometimes convenient is:

  • Not have it self-contained because the target machine is likely to have .NET Core of the correct version installed. This cuts on number of the DLL files I need to ship.
  • Not have to specify dotnet on the command line

For this, a bat file wrapper can be used, similar to these lines:

@ECHO OFF
REM see http://joshua.poehls.me/powershell-batch-file-wrapper/

SET SCRIPTNAME=%~d0%~p0%~n0.dll
SET ARGS=%*

dotnet "%SCRIPTNAME%" %ARGS%
EXIT /B %ERRORLEVEL%

If your application ends up in yourapp.dll, name the bat file yourapp.bat and place it along side the DLL file. 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 developers using the utility will have a pretty standard development machine setup. If this is to be distributed to an external customer who is running who knows what on their boxes, the self-contained option is far superior.

user_2841110
Related