我在csproj文件中有以下代码：
<TargetFramework>netcoreapp1.0</TargetFramework>
在NuGet包管理器中，它说我有 Microsoft.NETCore.App版本1.0.5
现在假设我在同一个csproj文件中有以下代码：
<TargetFramework>netcoreapp1.0</TargetFramework>
<RuntimeFrameworkVersion>1.1.4</RuntimeFrameworkVersion>
NuGet包管理器现在会说我有 Microsoft.NETCore.App版本1.1.4
我基本上尝试在.NETCore 2.0之前使用最新的框架（转换时有一些EF问题），这将是.NETCore 1.1.4但csproj中的多个Framework属性让我不确定要使用哪个标签。我无法找到任何明显区分两者之间差异的资源。
答案 0 :(得分：36)
NuGet使用TargetFramework来解析依赖关系并确定用于编译和构建应用程序的资产。 （在幕后，还有一些属性如TargetFrameworkMoniker和TargetFrameworkVersion发挥作用，但SDK将其抽象为更简单的TargetFramework，用于它所知道的框架。
RuntimeFrameworkVersion特定于.NET Core / netcoreapp。对于Microsoft.NETCore.App设置的版本，SDK将为RuntimeFrameworkVersion注入依赖关系，或者使用它知道的.NET Core的最新版本＆lt; 2.0。然后将已解析的版本写入.NET Core主机框架解析程序的runtimeconfig.json文件，以解析要加载的共享框架的版本（例如，＆gt; .NET Core 1.1.4运行时）。
您能够1.1.*使用netcoreapp1.0的原因是因为NuGet包实际上包含构建.NET Core 1.0。*应用程序所需的资产。然而，工具不知道这一点，所以你将得到一个.NET Core 1.0应用程序，但它将由1.1框架加载，因为这是最终在runtimeconfig.json文件中。
重要的区别是：
Microsoft.NETCore.App版本的自包含可执行文件有用。
dotnet publish -r win7-x64）1.0.3构建的应用程序但安装了1.0.5运行时时，将自动使用1.0.5运行时。RuntimeFrameworkVersion并且发布了一个新版本的SDK，它知道.NET Core的较新补丁版本，它将自动使用最新版本。如果您明确设置了版本，则可能不会在不编辑项目文件的情况下更新。RuntimeFrameworkVersion也是应用程序将加载的最小运行时间 - 如果将其设置为1.0.4并尝试在仅安装了1.0.3的计算机上运行，则应用程序将除非您编辑runtimeconfig.json文件，否则无法启动。RuntimeFrameworkVersion可以设置为浮动版本，这在定位预览版本或每日构建时非常有用，例如2.1.0-preview1-*将解析为配置的NuGet供稿中可用的最新preview1版本。除此之外，使用更高版本的Microsoft.NETCore.App进行构建的原因只有几个，例如DiaSymReader组件的构建错误修正。
在.NET Core 2.0中，RuntimeFrameworkVersion的版本对于“可移植应用程序”（非自包含）始终为2.0.0，因为框架的实现不再由依赖关系提供Microsoft.NETCore.App和此NuGet包仅用于提供编译的参考程序集。
答案 1 :(得分：2)
从文档中，您应该只使用runtimeframeworkversion
如果在定位.NET Core时需要特定版本的运行时，则应使用项目中的属性（例如，1.0.4），而不是引用元数据包。