Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How can I build a Visual Studio 2017 .NET Core .exe file on a developer machine?

Please see Solution section below for the TLDR.

I used the Visual Studio 2015 Community edition and upgraded to Visual Studio 2017. I am developing a .NET Core console application. I am talking here only about my local development machine, which has Visual Studio installed and it has .NET Core runtimes and SDKs installed.

In Visual Studio 2015, project.json files were used, and by default the build process produced a DLL file in the bin/Debug/netcoreapp1.1, that one could run using the dotnet run command. But there was an option to make a minor tweak in the project.json file:

...
"Microsoft.NETCore.App": {
  "version": "1.0.1",
  "type": "platform"
},
...

->

...
"Microsoft.NETCore.App": {
  "version": "1.0.1"
},
...

And adding a runtimes section, such as

"runtimes": {
  "win10-x64": {}
}

And if you did this and built your project, an EXE file was created that you could run directly, without using dotnet run.

Now the question is, is the same possible in Visual Studio 2017 using .csproj XML files? And more specifically, is it possible without the heavy self-contained deployments? I do want it without the full SDD publish because I use these executables for just local testing during the development. Once the project is to be released, I do the SDD publish, but that is very inconvenient during the development process.

The project was converted to Visual Studio 2017, but it only generates DLL files again. So, I tried to create a completely new and empty Hello, World! program and try to get EXE file from it. The Hello, World! csproj file looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>
</Project>

This only generates a DLL file that you can run with dotnet run. It is possible to make a change to this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp1.1;net46</TargetFrameworks>
  </PropertyGroup>
</Project>

which is very close to what I want - generating an EXE file. However, this creates EXE file that runs .NET Framework 4.6, not .NET Core. So, it does not solve the problem. What I really want is .NET Core executable without having to do self-contained deployment. Is it possible?

Solution

I just found out that this is indeed possible. I just don't know how to do it in the IDE. What currently happens if I hit Ctrl + Alt + F7 in the IDE produces the same result as the command:

dotnet build --configuration Debug

And what I want can be produced by command:

dotnet build --configuration Debug --runtime win10-x64

So what I really want now is modify the default IDE build command to replicate this behavior with --runtime win10-x64 parameter.

like image 823
Wapac Avatar asked Dec 23 '22 19:12

Wapac


1 Answers

In .NET Core, if you want an .exe produced during dotnet build, you need to supply the runtime that you want the executable built for.

In project.json, you did it as you describe above by removing type: platform and adding a runtimes section.

In .csproj, you do it by specifying the MSBuild property named RuntimeIdentifier. On the command-line, when you say dotnet build --runtime win10-x64, the --runtime value gets passed into MSBuild has the RuntimeIdentifier property.

One option is you can purely set the RuntimeIdentifier in your .csproj:

<PropertyGroup>
  <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
</PropertyGroup>

Now when you build in Visual Studio, it will produce an .exe in the build output folder.

Alternatively

I'm not sure if you are interested in this or not, but it sounds like you just want a way to run your application without calling dotnet run. If this is true, you don't need to set a runtime at all. By default your application gets built into bin\Debug\netcoreapp1.1\AppName.dll. You can run your application by saying dotnet bin\Debug\netcoreapp1.1\AppName.dll, which is basically what dotnet run does under the covers.

like image 88
Eric Erhardt Avatar answered Dec 28 '22 09:12

Eric Erhardt