2017-03-18 38 views
4

请参阅下面的编辑部分TLDR。如何在开发人员机器上构建MSVS 2017 .NET Core .exe?

我使用MSVS 2015社区并升级到MSVS 2017.我正在开发.NET Core控制台应用程序。 我在这里只谈论我的本地开发机器,它安装了MSVS并安装了.NET Core运行时和SDK。

在MSVS 2015中,使用了project.json文件,默认情况下生成过程在bin/Debug/netcoreapp1.1中生成了一个DLL文件,可以使用dotnet run命令运行。但是,有一个选项,以使在project.json文件中的小调整:

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

- >

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

并添加runtimes部分,如

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

,如果你做到了这一点,并建立了你的项目,创建了一个EXE文件,你可以直接运行,而不需要使用dotnet run

现在的问题是,是否可以在MSVS 2017中使用csproj XML文件?更具体地说,是否有可能没有沉重的自包含的部署?我确实希望没有完整的SDD发布,因为我在开发过程中仅使用这些可执行文件进行本地测试。一旦项目被发布,我会进行SDD发布,但这在开发过程中非常不方便。

该项目已转换为MSVS 2017,但它只是再次生成DLL文件。所以,我试图创建一个全新的空的Hello世界程序,并尝试从它获取EXE文件。问候世界的csproj文件是这样的:

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

这只能生成一个可以与dotnet run运行DLL文件。这是可能做出改变,以这样的:

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

这是非常接近我想要的东西 - 生成EXE文件。但是,这会创建运行.NET Framework 4.6的EXE文件,而不是.NET Core。所以,它不能解决问题。 我真正想要的是.NET Core可执行文件,而无需执行自包含的部署。可能吗?

编辑:刚发现这确实是可能的,我只是不知道如何在IDE中做到这一点。目前,会发生什么,如果我打Ctrl+Alt+F7在IDE产生相同的结果作为命令

dotnet build --configuration Debug

,我想可以用命令来产生什么

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

因此,我现在真的想为修改默认IDE build命令用--runtime win10-x64参数复制此行为。

回答

7

In。NET Core,如果你想在dotnet build期间产生.exe,你需要提供你想要为其构建的可执行文件的运行时。

在project.json中,您是通过删除type: platform并添加runtimes部分来完成的。

在.csproj中,您可以通过指定名为RuntimeIdentifier的MSBuild属性来执行此操作。在命令行上,当您说dotnet build --runtime win10-x64时,--runtime值传递到MSBuild具有RuntimeIdentifier属性。

一种选择是,你可以纯粹设置你的.csproj的RuntimeIdentifier

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

现在,当你在VS建立,它会产生生成输出文件夹的.exe

或者

我不知道,如果你有兴趣在此或没有,但它听起来像是你只是想办法,而无需调用dotnet run运行应用程序。如果这是真的,则根本不需要设置运行时。默认情况下,你的应用程序被内置到bin\Debug\netcoreapp1.1\AppName.dll。您可以通过说dotnet bin\Debug\netcoreapp1.1\AppName.dll来运行您的应用程序,这基本上是dotnet run所涵盖的内容。

+0

作品! Tx很多。我只想补充一点,应该介意'RuntimeIdentifier'的单数,因为似乎还有一个名为'RuntimeIdentifiers'的分号分隔列表,它明显地做了别的事情。 – Wapac

+0

'RuntimeIdentifiers'是您的项目可以定位的可用运行时的列表。就像'TargetFrameworks'是您的项目可以定位的可用框架列表。不同之处在于,当您构建时,它针对所有目标框架构建,但仅针对“运行时不可知”或“便携式”运行时构建它们。要为特定的运行时构建/发布,必须使用'RuntimeIdentifier' MSBuild属性(或dotnet命令行中的'--runtime')指定一个。 –

相关问题