所以首先要了解的是DNX项目对传统的.net项目没有了解。他们不读取或解析 csproj 文件。这样做是为了让它们跨平台和跨 IDE 兼容（csproj 是一个明显的 windows 和 VS 特定的东西）。
当您在幕后添加对“旧版”的引用（我使用旧版表示基于 .net 4.x csproj 的项目）时，IDE 将运行 dnu wrap，但在您的情况下看起来有些问题。
以下应该自动完成。
- 在解决方案根 global.json 中，应将文件夹“wrap”添加到
项目属性。
- 如果不存在名为“wrap”的根目录下的文件夹，则会创建它。
- 将使用程序集 (dll) 的路径创建/更新 /wrap/project.json。
- 将程序集和版本的引用添加到引用项目的 project.json 文件中。
所以首先要检查的是确保您在 solution.json 的项目属性中有一个“包装”文件夹并包装引用。如果你不这样做，那么可能有一些东西“坏了”。尝试删除参考重建并重新添加参考。检查构建输出窗口是否有任何错误（VS 仍然是 RC，所以有些错误可能应该停止但不是）。
在 wrap 文件夹中查找 project.json。它应该看起来像这样：
{
"version": "1.0.0-*",
"frameworks": {
"net452": {
"wrappedProject": "../../LegacyClassLibrary/LegacyClassLibrary.csproj",
"bin": {
"assembly": "../../LegacyClassLibrary/obj/{configuration}/LegacyClassLibrary.dll",
"pdb": "../../LegacyClassLibrary/obj/{configuration}/LegacyClassLibrary.pdb"
}
}
}
}
注意框架版本。如果存在不匹配，那么它将无法解决依赖关系。例如，如果您的 MySolution.Models 以 .Net 4.6 为目标，因此在包装时具有 dnx46 框架引用，但您的 MySolution.Server 项目具有对 dnx452 的引用（在 mySolution.Server 的 project.json 中），则在解析依赖项时它将失败到 MySolution.Models。
您引用的内容可能会有所改进。这意味着由于以下原因之一，它无法解决依赖关系
- 根据它使用的路径（从 global.json 中的项目参数开始）找不到 MySolution.Models 程序集（源代码或编译的 dll）。
- 它找到了一个 MySolution.Models 程序集（源代码或已编译），但它是无效版本。检查 Models 项目中的版本与 Server project.json 中的参考。
- 它找到了一个 MySolution.Models 程序集，但它无法解析框架依赖项（即模型需要 dnx46，但服务器只针对 dnx452）。
根据我的经验，第三个是最常见的。对于 VS 2015 RC 中的 DNX 模板，默认的完整框架是 dnx452（或者是 dnx451？）。新的 csproj 项目默认为 4.6 (dnx46)，现有项目几乎可以是任何东西。
另一种解决方案：
我发现以下替代方法可以更轻松地进行依赖管理。如果 MySolution.Models 仅由 DNX 项目使用，则只需将其转换为 DNX 项目，将其移动到源文件夹并直接引用它。它将成为源代码编译的一部分，您将获得动态编译的好处。
如果 DNX 和旧 (csproj) 项目都引用 MySolution.Models，那么您可以为模型创建并行的 xproj 和 project.json 文件。遗留项目将忽略它们。本质上，您拥有使用相同源文件的旧项目和 DNX 项目。然后，您可以像上面一样直接引用它。如果模型文件夹不在 /src 下（如果这是一个现有项目，则可能不是），请记住文件夹结构，那么您将需要移动它或在 global.json 中添加对文件夹的引用。这听起来更令人困惑，实际上是这样。请记住，对于 DNX 项目，global.json 定义了 DNX 可以找到源代码的相对路径。 DNX 还可以通过 nuget 或搜索 GAC 来解决依赖关系，但这超出了您的尝试范围。