从xproj引用与csproj相同的解决方案

Inr*_*ego 12 visual-studio-2015 asp.net-core

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

MySolution.sln
    - MySolution.Client.csproj
    - MySolution.Service.csproj
    - MySolution.Models.csproj
    - MySolution.Server.xproj
Run Code Online (Sandbox Code Playgroud)

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

VS 2015 RC1中的GUI允许我通过右键单击引用 - >添加引用来添加引用.然后我在Projects - > Solution下看到我的所有项目.

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

Errors in ...PathToSolution\MySolution.Server\project.json
    Unable to locate MySolution.Models >= 1.0.0-*
Run Code Online (Sandbox Code Playgroud)

它真的感觉这应该工作,因为GUI允许我添加引用没有任何打嗝.

Ger*_*vis 14

因此首先要了解的是DNX项目对传统的.net项目一无所知.它们不读取或解析csproj文件.这样做是为了保持它们跨平台和跨IDE兼容(csproj明显是Windows和VS特定的东西).

当您在幕后添加对"遗留"的引用(我使用遗留来表示基于.net 4.x csproj的项目)时,IDE将运行dnu wrap,但在您的情况下看起来像是有问题.

以下内容应自动完成.

  1. 在解决方案根global.json中,应将一个文件夹"wrap"添加到projects属性中.
  2. 如果不存在,将创建名为"wrap"的根目录下的文件夹.
  3. 将使用程序集(dll)的路径创建/更新/wrap/project.json.
  4. 将程序集和版本的引用添加到引用项目的project.json文件中.

因此,首先要检查的是确保在solution.json的projects属性中有一个"wrap"文件夹和wrap引用.如果你不这样做,那么可能会"破坏".尝试删除引用重建并添加引用.检查构建输出窗口是否有任何错误(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"
      }
    }
  }
}
Run Code Online (Sandbox Code Playgroud)

请注意框架版本.如果存在不匹配,则无法解析依赖关系.例如,如果您的MySolution.Models以.Net 4.6为目标,因此当包装有dnx46框架引用但您的MySolution.Server项目引用了dnx452(在Project.json中为MySolution.Server)时,它将在解析依赖时失败到MySolution.Models.

你引用的内容可能会得到改善.这意味着由于以下原因之一,它无法解决依赖关系

  • 它无法根据它使用的路径找到MySolution.Models程序集(源代码或编译的dll)(从global.json中的projects参数开始).
  • 它找到了一个MySolution.Models程序集(源代码或编译),但它是一个无效的版本.检查Models项目中的版本与Server project.json中的引用.
  • 它找到了一个MySolution.Models程序集但它无法解析框架依赖关系(即模型需要dnx46但服务器只针对dnx452).

根据我的经验,第三个如果最常见的话.对于VS 2015 RC中的DNX模板,目标的默认完整框架是dnx452(或者是dnx451?).默认情况下,新的csproj项目将为4.6(dnx46),现有项目几乎可以是任何项目.

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

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

  • 惊人的答案.我们正在研究如何在将来启用csproj - > xproj.我们还需要更多地完善包装体验并支持更多dnx4x版本. (2认同)