asp.net-core - 从与 xproj 相同的解决方案中引用 csproj

Question

我有以下项目的解决方案:

MySolution.sln
    - MySolution.Client.csproj
    - MySolution.Service.csproj
    - MySolution.Models.csproj
    - MySolution.Server.xproj

MySolution.Models 是一个简单的类库，其中包含由 MySolution.Client 和 MySolution.Service 引用的共享代码 - 我想在 MySolution.Server 中引用它。

VS 2015 RC1 中的 GUI 允许我通过右键单击“引用”->“添加引用”来添加引用。然后我在“项目”->“解决方案”下看到我的所有项目。

我选择 MySolution.Models 并单击 Ok，之后我在输出日志中收到以下错误:

Errors in ...PathToSolution\MySolution.Server\project.json
    Unable to locate MySolution.Models >= 1.0.0-*

感觉这应该可行，因为 GUI 允许我添加引用而不会出现任何问题。

Answer 1

所以首先要了解的是，DNX 项目对传统的.net 项目没有任何了解。他们不读取或解析 csproj 文件。这样做是为了让它们跨平台和跨 IDE 兼容(csproj 是一个明显的 Windows 和 VS 特定的东西)。

当您在幕后添加对“遗留”的引用(我使用遗留表示基于 .net 4.x csproj 的项目)时，IDE 将运行 dnu wrap，但在您的情况下看起来好像出了点问题。

以下应自动完成。

在解决方案根 global.json 中，应将文件夹“wrap”添加到
项目属性(property)。

如果不存在，将创建一个名为“wrap”的根目录下的文件夹。

将使用程序集 (dll) 的路径创建/更新/wrap/project.json。

向引用项目的 project.json 文件添加对程序集和版本的引用。

所以首先要检查的是确保你有一个“wrap”文件夹，并在 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 程序集(源代码或编译的)，但它是一个无效的版本。检查模型项目中的版本与服务器 project.json 中的引用。

它找到了一个 MySolution.Models 程序集，但它无法解析框架依赖项(即模型需要 dnx46 但服务器仅针对 dnx452)。

根据我的经验，第三种是最常见的。对于 VS 2015 RC 中的 DNX 模板，目标的默认完整框架是 dnx452(或者是 dnx451？)。默认情况下，新的 csproj 项目将是 4.6 (dnx46)，现有项目几乎可以是任何东西。

另一种解决方案:
我发现以下替代方法可以更轻松地进行依赖项管理。如果 MySolution.Models 仅用于 DNX 项目，则只需将其转换为 DNX 项目即可将其移动到源文件夹中并直接引用它。它将成为源编译的一部分，您将获得动态编译的好处。

如果 MySolution.Models 将被 DNX 和遗留 (csproj) 项目引用，那么您可以为模型创建并排的 xproj 和 project.json 文件。它们将被遗留项目忽略。本质上，您拥有使用相同源文件的旧项目和 DNX 项目。然后你可以像上面一样直接引用它。如果模型文件夹不在/src 下(如果这是现有项目，则可能不是)，请记住文件夹结构，然后您需要移动它或在 global.json 中添加对文件夹的引用。这听起来更令人困惑，它确实如此。请记住，对于 DNX 项目， global.json 定义了 DNX 可以找到源代码的位置的相对路径。 DNX 还可以通过 nuget 或搜索 GAC 来解决依赖关系，但这超出了您的尝试范围。