好问题。针对你的具体问题，看起来你的依赖关系存在不匹配的情况。当出现这种情况时，很可能是因为你在不兼容的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 中引入一个名为“floating versions”的新功能。今天它仅适用于预发布标记，但在下一个版本中，它将适用于版本的更多部分。这类似于 npm 和 gem 语法，在软件包规范文件中指定版本范围。
1.0.0-* - 表示给我与前缀匹配的最高版本（根据语义化版本规则），或者如果没有与该前缀匹配的版本，则使用正常行为并获取>=指定版本的最低版本。
当您在最新版本中运行恢复时，它将编写一个名为project.lock.json的文件。此文件将具有在project.json中定义的所有目标框架的依赖项的传递闭包。
当类似于这样的内容失败时，您可以执行以下操作：
使用kpm list查看已解决的依赖项。这将显示您的项目引用的软件包的已解析版本以及引入它的依赖关系。例如，如果A->B，则会显示：
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不兼容），您可以查看引用节点。它以相同的方式呈现数据：
让我们看一下依赖项失败的情况：
这是项目的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 目前的工作方式（这在将来可能会改变）。默认情况下，你在 %appdata%\NuGet\NuGet.Config 中全局配置了一个默认的 NuGet.org 源。你可以使用 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}
当你尝试运行时，应该记住在
project.json中定义的从clr到目标框架的心理映射。
这也显示在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”，但没有“文件：”。这可能是构建失败的原因。
这就是我的头脑倾泻的全部内容。
