使用Visual Studio 2017将.NET Core应用程序编译为EXE文件


72

我在Visual Studio 2017中创建了一个.NET Core应用程序(v1.1)。对其进行编译时,我生成了一个DLL文件,而不是所生成项目的预期EXE文件。我确实检查了csproj文件,并确认输出类型设置为exe,但没有骰子。

为什么Visual Studio 2017仍在生成DLL文件?

我确定这是我忘了的快速设置...

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

Answers:


104

更新2019:

现在,.NET Core 3.0+项目将默认包含针对您所构建平台的可执行文件。这只是一个填充程序可执行文件,您的主要逻辑仍然在.dll文件内。

但是.NET Core 3.0还引入了单文件部署,因此使用

dotnet publish -r win-x64 -p:PublishSingleFile=True --self-contained false

将创建一个包含所有依赖项的.exe文件。您也可以更改--self-containedtrue也包含.NET Core运行时,因此.NET Core不需要在目标计算机上全局安装。

原版的

.NET Core应用程序应该是.dll文件。在这种情况下,OutputType设置为Exe表示“可执行”,它会做所有必要的工作以确保输出可运行(Main()方法,.runtimeconfig.json文件的入口)。生成的DLL文件应使用以下命令运行:

dotnet yourapp.dll

该DLL文件可在.NET Core运行时支持的所有平台(Windows,Linux和macOS)上运行。这称为“便携式”或“框架相关”部署。

如果您确实想要一个.exe文件,请考虑独立的部署。这将创建一个包含其自己的.NET Core运行时副本和一个yourapp.exe文件的输出-但它还会增加已发布应用程序的大小,并且在发布新版本的运行时时需要对其进行更新。

同样,生成的应用程序仅可在为其发布的操作系统上运行。

有关部署选项及其设置方法的更多详细信息,请参考.NET Core应用程序部署


7
感谢您提供有关不同部署策略的信息。这有助于我对.net-core的更多了解。
ajawad987

@Martin,我一直在dotnetcore(1个月:)中寻找“ -p:PublishSingleFile = True”标志。值得庆幸的是,我从3.0开始我的dotnetcore生活,并且在OSX Mojave,Linux(CentOS 7.6)和Windows 10上都可以正常工作。–
TMT

63

在Visual Studio 2017中:

  1. 右键单击您的项目并选择发布(在Visual Studio 2019中,单击菜单生成发布<projectName>
  2. 选择“文件夹”并创建一个新的配置文件
  3. 在“发布”标签中,点击“配置...”
  4. 选择部署模式:自包含,目标运行时:win-x86(或win-x64)
  5. 保存
  6. 发布

在文件夹<您的项目> \ bin \ Debug \ netcoreapp2.1 \ win-x86 \中,您将看到EXE文件:

发布设定


2
谢谢!很高兴知道在Visual Studio中有一种方法可以做到这一点。
ajawad987 '18

7

从.NET Core 2.2开始,您可以构建框架相关的可执行文件


尽管构建一个独立的部署可能是一个好的解决方案,但它也有其自身的缺点。(请参阅R.Titov和Martin Ullrichs关于SCD-s的回答。)

幸运的是,.NET Core 2.2支持所谓的依赖于框架的可执行文件-s的构建,该文件本质上是标准dll-s的包装二进制文件(在Windows上是.exe

这样,您就具有了依赖于标准框架的标准部署的所有优点(和缺点)(再次参见Martin的回答),但是您有一种方便的启动方式,而不必通过dotnet CLI调用它。

您可以使用以下语法将应用程序发布为依赖框架的可执行文件

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

RID是通常的运行时标识符,例如,win-x64或您希望构建的任何平台(请参见此处的目录)。


1

这就是您在任何OS中使用命令行进行自包含发布的方式:

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

此外,您可能希望使用ILLink将输出从一个简单的Hello World应用程序的典型〜60 MB减少到〜30 MB 。

另外,您可能想走得更远,获得一个大小约为5 MB的.exe文件,并使用ILCompiler请参阅此回复


值得一提的是,ILCompiler是一个像CoreRT这样的AOT编译器平台,它有其自身的局限性(没有Reflection.Emit等)。
马塞勒·托斯

0

其他答案也不错,但我发现有时很方便的是:

  • 由于目标计算机可能已安装了正确版本的.NET Core,因此它不是自包含的。这减少了我需要运送的DLL文件的数量。
  • 不必dotnet在命令行上指定

为此,可以使用bat文件包装器,类似于以下行:

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

如果您的应用程序以结尾yourapp.dll,请命名bat文件yourapp.bat并将其放置在DLL文件旁边。现在,dotnet yourapp.dll params您可以致电而不是yourapp params

请注意,此答案的上下文是内部工具,因此所有使用该实用程序的开发人员都将拥有相当标准的开发机器设置。如果要将其分发给正在运行的外部客户,他们知道自己的盒子上有什么东西,那么自包含的选项将非常优越。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.