Visual Studio не может обрабатывать вложенный подмодуль, как ожидалось - PullRequest
Новая
       23

Visual Studio не может обрабатывать вложенный подмодуль, как ожидалось

1 голос
/ 12 апреля 2019

У меня есть 3 решения, которые

* Решения 1004 *

Раствор А

  • Project A1 - это проект расширения для классов System.Data.SqlClient (.NET Standard 2.0)

Раствор B

  • Project B1 - это библиотека, используемая для управления некоторыми экземплярами (.NET Standard 1.0)
  • Project B2 - это библиотека, используемая для управления экземплярами с расширенным System.Data.SqlClient до Project A1 (.NET Standard 2.0)

Раствор С

  • Project C1 библиотека зависит от A1 и B1 (.NET Standard 2.0)
  • Project C2 - это тест NUnit, зависит от всех проектов выше (.NET Core 2.2)

Файловая структура

Решения / Проекты импортируются через подмодули Git, структура которых представлена ​​ниже: 

- \
--- \Solution C
------ \Project C1
------ \submodules
--------- \Solution A
------------ Project A1
--------- \Solution B
------------ \Project B1
------------ \Project B2
------------ \submodules
--------------- \Solution A
------------------ \Project A1

Выпуск

Хотя я использую Visual Studio для открытия Solution C и компиляции проектов внутри, результаты различны: ( note : я не включил \Solution C\submodules\Solution B\submodules\Solution A\Project A1 в решение, поскольку VS не позволяет 2 проекта с тем же именем)

  • Проект А1: хорошо
  • Проект B1: хорошо
  • Проект B2: не в порядке
  • Проект C1: хорошо
  • Проект C2: не в порядке

VS всегда говорил, что Project B2 не может найти Project A1 (путь \Solution C\submodules\Solution B\submodules\Solution A\Project A1), если я не нажму правой кнопкой мыши на Project A1 и не выберу «clean», а затем перестрою Project B2 («clean is must»), ниже приведено сообщение:

Error NU1105 Unable to find project information for '\Solution C\submodules\Solution B\submodules\Solution A\Project A.csproj'. Inside Visual Studio, this may be because the project is unloaded or not part of current solution. Otherwise the project file may be invalid or missing targets required for restore.

Однако я попытался клонировать только Solution B на новую позицию (с подмодулями Solution A), и его можно скомпилировать и запустить как положено.

Угадывает

  • Как предполагает @jessehouwing, это может быть не проблема Git, а Visual Studio, я думаю, это из-за того, что VS компилирует проекты с 2-й версией Project A1, в то время как я уже потратил часы, чтобы обеспечить Solution B и Solution C загружено Solution A из той же ветки и версии.

Обновление

Guids

  • Project A из Solution A: FD9834ED-3C94-4445-AE15-DFF0F5C42656
  • Project A из Solution A с папкой подмодулей Solution B: FD9834ED-3C94-4445-AE15-DFF0F5C42656
  • Project A из Solution A: E0FEC3C6-42AB-47D9-912A-40B3C5D2BA66
  • Project A из Solution C: 2A7E2981-87F6-40A5-86F4-D523EC1F68DB

Любая помощь будет оценена

1 Ответ

2 голосов
/ 12 апреля 2019

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

Как и предполагал jessehouwing (спасибо за вашу помощь, jessehouwing !!), мы могли бы объединить все проекты (подмодули) в одно гигантское решение для разработки (я думаю, этот подход идеально соответствует названию решение )

Однако то, что мы пытаемся сделать, имеет следующую архитектуру:

  • Cores.Library
  • ACompany.Cores.Library
  • ACompany.Cores.Web
  • BCompany.Cores.Library1
  • BCompany.Cores.Library2
  • BCompany.Cores.Console
  • BCompany.Cores.Web

Итак, в конце концов я решил использовать внутреннюю ленту NuGet, в то время как VS2017 уже может автоматически генерировать файл nupkg при сборке, которая была протестирована и работает отлично, как и ожидалось.

@ jessehouwing, вы можете ответить на вопрос, и я бы поставил ваш ответ, еще раз спасибо!

...