在 global.json 中，父级相对目录的预期行为是什么？

Question

（现在作为DNX问题3206提出...）

DNX环境：1.0.0-rc1，Windows 10 x64。

假设我有三个解决方案：

• Application1
• Application2
• Common

每个解决方案都有多个项目，将所有项目放在一个解决方案中是没有意义的，尽管这可能会简化这个特定的问题。

Application1和Application2中的各个项目依赖于Common中的一个项目。它们的project.json文件以正常方式指示了该依赖项。虽然最终我想发布来自Common的工件到NuGet服务器（内部或外部），但暂时从源代码构建所有内容是有意义的。

我可以通过编辑（例如）Application1内的global.json来执行此操作：

{
  "projects": [ "src", "test", "../Common/src" ], 
  "sdk": { "version": "1.0.0-rc1-final"  }
}

有了这个设置，我可以从Application1目录执行dnu restore，但不能从根目录执行（报错信息是“Unable to locate Dependency 'Common' >= 0.0.0-*"）。我可以在根目录中运行dnu restore Application1，但不能仅通过dnu restore命令。

我尝试了很多方式来引用Common src目录（包括"./Common/src"、"Common/src"、"../repo-name/Common/src"），但都没有成功。在每种情况下，都会得到上面显示的错误消息。我尝试使用dnu -v restore命令，但似乎没有额外的信息显示哪些目录正在探测基于源码的软件包。

那么，在global.json文件中，应该如何解析"../Common/src"路径？这是一个合理的开发方案吗？如果是，那么只需要向DNX提交一个bug报告即可解决问题吗？

- Jon Skeet

---

我还在学习中，但是你应该只有一个global.json文件，并且它应该在根目录下，不是吗？ - Khalid Abuhakmeh

@KhalidAbuhakmeh：每个解决方案一个。这是多个解决方案的情况，每个解决方案都有多个项目。我会澄清问题。 - Jon Skeet

没有在global.json（或dnx）中的经验；但总的来说，我尽量避免使用相对引用，比如“../folder”，因为在不同的上下文中会出现问题。你是否尝试将Common/src内容存储在给定应用程序的文件夹内，并在不使用“../”部分的情况下引用它？只是为了测试一下，看看这是否是问题所在。 - varocarbas

@varocarbas：我相信那样做也没问题，但对于文件组织来说并没有什么帮助。我只希望文件系统中的布局与存储库中的布局相匹配 - 这里并没有跨存储库的期望。 - Jon Skeet

这只是为了测试目的提出的建议（消除潜在的错误源；并不是说文件不能在任何地方定位，只是可能你用来引用路径的方式不被支持）。例如，PHP的require/include就不允许这种格式。无论如何...我相信你对所有这些都比我更了解。只是想帮忙。 - varocarbas

Answer 1

当你开始执行dnu restore时，它并不像你期望的那样工作，它会尝试在当前或父目录中查找global.json，并从中读取项目路径。所以在你的例子中，它没有读取到任何内容，因为global.json在子目录中。

解决这个问题的一种方法是将global.json添加到根文件夹中，并使用以下内容：

{
   "projects": [ "Application/src", "Common/src" ]
}

我会就这种情况进行询问，如果使用 dotnet cli 时可能发生变化。

- Pavel Krymets

---

所以它只在搜索子目录时查找project.json？这解释了其行为，但似乎是一个奇怪的设计选择。不过我会进行实验的 - 谢谢！ - Jon Skeet

没错，经过进一步尝试，我认为这正是问题所在。我会适当修改该问题 :) - Jon Skeet