如何在Universal Windows Platform应用程序中更新一个特定的dotnet程序集?

时间:2015-11-22 13:32:47

标签: .net nuget windows-10 uwp .net-core

我读到dotnet是OpenSource,通过nuget而不是monolith安装程序通过粒度包分发。

我创建了一个简单的UWP应用程序,我在project.json中看到的是

{
  "dependencies": {
    "Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0"
  },
  "frameworks": {
    "uap10.0": {}
  },
  "runtimes": {
    "win10-arm": {},
    "win10-arm-aot": {},
    "win10-x86": {},
    "win10-x86-aot": {},
    "win10-x64": {},
    "win10-x64-aot": {}
  }
}

当我尝试通过nuget安装预发布System.Collections时,我得到以下

Version conflict detected for System.Private.Uri. 
 SM.W10 (≥ 1.0.0) -> System.Collections (≥ 4.0.11-beta-23516) -> System.Runtime (≥ 4.0.21-beta-23516) -> System.Private.Uri (≥ 4.0.1-beta-23516) 
 SM.W10 (≥ 1.0.0) -> Microsoft.NETCore.UniversalWindowsPlatform (≥ 5.0.0) -> Microsoft.NETCore.Runtime (≥ 1.0.0) -> Microsoft.NETCore.Runtime.CoreCLR-arm (≥ 1.0.0) -> System.Private.Uri (= 4.0.0).

我觉得我应该以某种方式展开Microsoft.NETCore.UniversalWindowsPlatform,但它有很多级别的嵌套,只有深层嵌套Microsoft.NETCore.Runtime.CoreCLR-arm具有System.Private.Url的严格版本

有没有办法在没有痛苦的情况下更新System.Collections?

1 个答案:

答案 0 :(得分:5)

首次发布时,由于System.RuntimeSystem.Collections等软件包与.NETNative工具链之间的某些私有依赖关系,UWP应用程序固定了所有核心软件包。因此,为了测试任何最低级别合同的新版本,您还需要更新运行时包。

例如。

"dependencies": {
  "Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0"
  "Microsoft.NETCore.Runtime": "1.0.1-beta-23516",
  "System.Collections" :  "4.0.11-beta-23516"
}

您只会在堆栈最底部的包中遇到此行为,特别是

System.Collections,
System.Diagnostics.Contracts,
System.Diagnostics.Debug,
System.Diagnostics.StackTrace,
System.Diagnostics.Tools,
System.Diagnostics.Tracing,
System.Globalization,
System.Globalization.Calendars,
System.IO,
System.ObjectModel,
System.Reflection,
System.Reflection.Extensions,
System.Reflection.Primitives,
System.Resources.ResourceManager,
System.Runtime,
System.Runtime.Extensions,
System.Runtime.Handles,
System.Runtime.InteropServices,
System.Text.Encoding,
System.Text.Encoding.Extensions,
System.Threading,
System.Threading.Tasks,
System.Threading.Timer

UWP的未来版本不会出现同样的问题。我们发现使用NuGet尝试强制执行私有依赖项是脆弱的,并产生令人困惑的错误。