好问题。对于您的特定问题,看来您解决的依赖性不匹配。当发生这种情况时,可能是因为您在不兼容的dnx上运行应用程序。我们仍在进行重大更改,因此,如果您发现缺少缺少类型的方法,则有可能您最终运行了betaX
程序包,并且betaY
dnx则相反。
更具体地说,装配中性接口在Beta4中已删除了,但看起来您正在运行的应用程序仍在使用它们。
我们计划这样做,以便程序包可以标记它们需要运行的最小dnx,以使错误消息更加清晰。而且随着时间的流逝,重大变化将消失。
总的来说,我觉得是时候我写了一篇指南,介绍如何在使用dnx时诊断此类问题(因为它与现有的.NET完全不同)。
您放入的依赖性project.json
仅是顶级的。版本也始终是最低版本(就像NuGet包一样)。这意味着当您指定时,Foo 1.0.0-beta4
您实际上是在指定Foo >= 1.0.0-beta4
。这意味着,如果您要求MVC 0.0.1
并且配置的供稿上的最低版本为MVC 3.0.0
,那么您将获得该版本。除非您指定版本,否则我们也绝不会浮动您的版本。如果要求1.0.0并且存在,那么即使存在较新的版本,也将获得1.0.0。指定空版本总是不好的,在以后的版本中将不允许使用。
我们正在为nuget引入一个新功能,称为浮动版本。今天,它仅适用于prerelease标签,但在下一版本中,它将适用于该版本的更多部分。这类似于npm和gem语法,用于在软件包规范文件中指定版本范围。
1.0.0-*
-意味着给我最高前缀匹配的版本(根据语义版本控制规则),或者如果没有与该前缀匹配的版本,请使用正常的行为,让我最低版本> =指定的版本。
在最新版本中运行还原时,它将写出一个名为的文件project.lock.json
。该文件将对中定义的所有目标框架的依赖项进行传递性关闭project.json
。
当类似的操作失败时,您可以执行以下操作:
看看使用 kpm list
。这将向您显示项目引用的已解析软件包的版本以及将其引入哪个依赖项。例如,如果A-> B,它将显示:
一个
-> B
乙
->
实际KPM列表输出:
列出ClassLibrary39的依赖项(C:\ Users \ davifowl \ Documents \ Visual Studio 14 \ Projects \ ClassLibrary39 \ src \ ClassLibrary39 \ project.json)
[Target framework DNX,Version=v4.5.1 (dnx451)]
framework/Microsoft.CSharp 4.0.0.0
-> ClassLibrary39 1.0.0
framework/mscorlib 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System.Core 4.0.0.0
-> ClassLibrary39 1.0.0
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
[Target framework DNXCore,Version=v5.0 (dnxcore50)]
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
System.Runtime 4.0.20-beta-22709
-> ClassLibrary39 1.0.0
*表示直接依赖。
如果您有一个正在运行的Visual Studio(目前已与DNX分离),则可以查看参考节点。它具有以视觉方式表示的相同数据:
让我们看一下依赖失败的样子:
这是project.json
{
"version": "1.0.0-*",
"dependencies": {
"Newtonsoft.Json": "8.0.0"
},
"frameworks" : {
"dnx451" : {
"dependencies": {
}
},
"dnxcore50" : {
"dependencies": {
"System.Runtime": "4.0.20-beta-22709"
}
}
}
}
Newtonsoft.Json 8.0.0
不存在。因此,运行kpm restore将显示以下内容:
当诊断还原何时可能失败时,请查看发出的HTTP请求,它们会告诉您kpm查找了哪些已配置的软件包源。请注意,在上图中,有一个CACHE
请求。这是基于资源类型(nupkg或nuspec)的内置缓存,并且具有可配置的TTL(请参阅参考资料kpm restore --help
)。如果要强制kpm
访问远程NuGet源,请使用--no-cache
标志:
这些错误也会显示在Visual Studio的程序包管理器日志输出窗口中:
边注!
包裹来源
我将描述NuGet.config现在的工作方式(将来可能会改变)。默认情况下,您具有一个NuGet.config,其中默认的NuGet.org源在以下位置进行了全局配置%appdata%\NuGet\NuGet.Config
。您可以在Visual Studio中或使用NuGet命令行工具管理这些全局源。在诊断故障时,应始终查看有效的来源(在kpm输出中列出的来源)。
在此处阅读有关NuGet.config的更多信息
回到现实:
当依赖关系无法解决时,运行该应用程序将为您提供:
> dnx . run
System.InvalidOperationException: Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1':
Newtonsoft.Json 8.0.0
Searched Locations:
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\{name}\project.json
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\test\{name}\project.json
C:\Users\davifowl\.dnx\packages\{name}\{version}\{name}.nuspec
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\{name}.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_64\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll
Try running 'kpm restore'.
at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)
运行时基本上在尝试运行之前尝试验证是否已解决整个依赖关系图。如果它建议运行,kpm restore
那是因为它找不到列出的依赖项。
您可能会收到此错误的另一个原因是,如果您运行的是错误的dnx风格。如果您的应用程序仅指定dnx451,并且您尝试运行CoreCLR dnx,则可能会遇到类似的问题。请密切注意错误消息中的目标框架:
运行:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
当您尝试运行时,应该记住从clr到您的中定义的目标框架的思维导图project.json
。
这也显示在Visual Studio的“引用”节点下:
标记为黄色的节点尚未解析。
这些也会显示在错误列表中:
建造
在构建时也会显示这些错误。从命令行进行构建时,输出非常冗长,并且在诊断问题时非常有用:
> kpm build
Building ClassLibrary39 for DNX,Version=v4.5.1
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Assembly dependency framework/mscorlib 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\mscorlib.dll
Using Assembly dependency framework/System 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.dll
Using Assembly dependency framework/System.Core 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Core.dll
Using Assembly dependency framework/Microsoft.CSharp 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Microsoft.CSharp.dll
Building ClassLibrary39 for DNXCore,Version=v5.0
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Package dependency System.Console 4.0.0-beta-22709
Source: C:\Users\davifowl\.dnx\packages\System.Console\4.0.0-beta-22709
File: lib\contract\System.Console.dll
Using Package dependency System.IO 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.IO\4.0.10-beta-22231
File: lib\contract\System.IO.dll
Using Package dependency System.Runtime 4.0.20-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Runtime\4.0.20-beta-22231
File: lib\contract\System.Runtime.dll
Using Package dependency System.Text.Encoding 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Text.Encoding\4.0.10-beta-22231
File: lib\contract\System.Text.Encoding.dll
Using Package dependency System.Threading.Tasks 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Threading.Tasks\4.0.10-beta-22231
File: lib\contract\System.Threading.Tasks.dll
输出显示了从程序包和项目引用传递到编译器的所有程序集。当您开始遇到构建失败时,查看此处以确保您使用的软件包在该目标平台上确实有效是很有用的。
这是在dnxcore50上不起作用的软件包的示例:
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.Owin.Host.SystemWeb": "3.0.0"
},
"frameworks": {
"dnx451": {
"dependencies": {
}
},
"dnxcore50": {
"dependencies": {
"System.Console": "4.0.0-beta-22709"
}
}
}
}
Microsoft.Owin.Host.SystemWeb版本3.0.0没有在dnxcore50上运行的任何程序集(请查看解压缩后的程序包的lib文件夹)。当我们运行时kpm build
:
注意它说“使用包Microsoft.Owin.Host.SystemWeb”,但没有“文件:”。这可能是构建失败的原因。
到此为止我的脑力激荡