Question

我有一个类似于csproj的项目：

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFrameworks>netstandard2.0;netcoreapp1.1</TargetFrameworks>
  <AssemblyName>ConsoleApp</AssemblyName>
  <PackageId>ConsoleApp</PackageId>
  <Version>1.0.0.1</Version>
  <RootNamespace>ConsoleApp</RootNamespace>
  <RuntimeIdentifiers>win10-x64;android.21;android.21-arm64;osx.10.12;rhel7.4;centos.7-x64;debian.8-x64;ubuntu.16.10-x64;fedora.26-x64;opensuse.42.1-x64</RuntimeIdentifiers>
</PropertyGroup>

<ItemGroup Condition=" '$(_ShortFrameworkIdentifier)' == 'netstandard' ">   
  <PackageReference Include="Microsoft.NETCore.Runtime.CoreCLR" Version="1.1.1" />
  <PackageReference Include="Microsoft.NETCore.DotNetHostPolicy" Version="1.1.0" />
</ItemGroup>

如果我运行dotnet publish -c Release -f netstandard2.0并且没有指定运行时，我会在..\bin\Release\netstandard2.0\publish获得输出，看起来它将是一个自包含的部署，除了主要＆＃34 ;可执行＆＃34;是一个DLL（相反，如果我定义了运行时我得到的exe或没有扩展名的文件）以及一个名为runtimes的文件夹，看起来它有一些运行时特定的库用于不同的OS＆＃39;像unix，osx，rhel，像System.Security.Cryptography.Algorithms等。

这种出版实际上产生了什么？这组文件是否有用？

Answer 1

如果您使用即将推出的netstandard2.0工具，则无法生成可用的部署，因为对于2.0，所有包（NETStandard.Library和Microsoft.NETCore.App）都是扁平的，而不是引用单个组件。

在定位netstandard1.6时，您可以通过这种方式获得“小占用”应用的原因主要是由于Microsoft.NETCore.App构建方式的副作用（针对netstandard版本和各个组件带来的在运行时的实现中。）

发布主入口点的逻辑与从组件解析的组件相关联。对于netcoreapp1。*，重命名dotnet.exe / dotnet可执行文件，对于2.0+，apphost.exe / apphost重命名，dll的名称文件嵌入。

没有运行时定义生成的.NET Core自包含部署是什么？

1 个答案: