Ссылка a csproj из того же решения, что и xproj

У меня есть решение со следующими проектами:

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

MySolution.Models - это простая библиотека классов, которая содержит общий код, на который ссылается MySolution.Client и MySolution.Service - и я хотел бы ссылаться на него в MySolution.Server.

GUI в VS 2015 RC1 позволяет мне добавить ссылку, щелкнув правой кнопкой мыши ссылку → Добавить ссылку. Затем я вижу все мои проекты в разделе Проекты → Решение.

Я выбираю MySolution.Models и нажимаю Ok, после чего я получаю следующую ошибку в журнале вывода:

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

Кажется, что это должно сработать, поскольку графический интерфейс позволяет мне добавлять ссылку без каких-либо икота.

Ответ 1

Итак, первое, что нужно понять, - проекты DNX не имеют представления о традиционных проектах .net. Они не читают и не анализируют файлы csproj. Это делается для того, чтобы держать их в перекрестной платформе и переходить на совместимость с IDE (csproj - это явно Windows и VS).

Когда вы добавляете ссылку на "наследие" (я использую наследие для обозначения проекта .net 4.x csproj) за кулисами, среда IDE будет запускать dnu wrap, но похоже, что в вашем случае что-то сломалось.

Следующее должно выполняться автоматически.

В корне решения global.json необходимо добавить папку "wrap" проектов.
Папка с корнем с именем "wrap" будет создана, если она не существует.
A/wrap/project.json будет создан/обновлен с помощью пути к сборке (dll).
Добавьте ссылку на сборку и версию на файл project.json проекта ссылки.

Итак, первое, что нужно проверить, это убедиться, что у вас есть папка "обернуть" и обернуть ссылку в свойстве projects решения .json. Если вы этого не сделаете, значит, что-то "сломалось". Попробуйте удалить ссылку на восстановление и добавить ссылку обратно. Проверьте окно вывода сборки для любых ошибок (VS все еще RC, поэтому есть ошибка, которая, вероятно, должна останавливаться, а это не так).

Найдите файл project.json в папке wrap. Он должен выглядеть примерно так:

{
  "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 и, таким образом, когда wrapped имеет ссылку на базовую структуру dnx46, но ваш проект MySolution.Server имеет ссылку на dnx452 (в project.json для MySolution.Server), то он будет терпеть неудачу при разрешении зависимости к MySolution.Models.

Вы, вероятно, могли бы уточнить, что вы указали. Это означает, что он не может разрешить зависимость по одной из следующих причин.

Не удалось найти сборку MySolution.Models(либо исходный код, либо скомпилированную dll) на основе путей, которые он использует (начиная с параметра projects в global.json).
Он нашел сборку MySolution.Models(либо исходный код, либо скомпилирован), но это была недопустимая версия. Проверьте версию в проекте "Модели" и ссылку в "Сервер project.json".
Он нашел сборку MySolution.Models, но не может разрешать зависимости от структуры (т.е. для моделей требуется dnx46, но сервер только нацеливается на dnx452).

По моему опыту третий, если самый распространенный. Для шаблонов DNX в VS 2015 RC целевой целью по умолчанию является 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, но это выходит за рамки того, что вы пытаетесь сделать.