NuGet и несколько решений

У нас есть два решения: foo.sln и bar.sln

У меня есть общая библиотека, которая используется как foo, так и bar. Common.csproj используется обоими.

Если я открываю ссылки foo и update nuget, все ссылки в Common.csproj указывают на foo/packages/. Если позже я открою бар и обновит ссылки на nuget, все ссылки будут установлены в теги в bar/packages/. Естественно, это отрывается от команды foo, так как это может вызвать несовместимость между Common.csproj и Foo-специфическими файлами, такими как Foo.Data.csproj, который все еще указывает на foo/packages.

Должно быть какое-то очевидное решение, кроме: "создать огромное решение, содержащее все ваши проекты, и если вам нужно коснуться nuget, сделайте это только из этого решения".

Кажется, что проблема на codeplex (кстати, проголосовали за верхнюю часть), но, видимо, я слишком толстый, чтобы понять, как эта проблема решена. Может кто-нибудь объяснить, как это исправить?

Ответ 1

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

Но реальная проблема заключается в том, что при обновлении обновленные пакеты не отображаются в каталоге foo/packages?

Простым решением является перемещение Common.csproj в собственное решение с его собственными ссылками, пакетами пакетов, сборкой и выпуском. Затем создайте собственный пакет NuGet с любыми зависимыми зависимостями, встроенными в него. Затем вы можете установить свой общий пакет как в Foo, так и в Bar, а затем команда Foo может обновить до последней версии Common, когда и когда они будут готовы.

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

Основной вопрос, который вам нужно задать, - кто владеет Common.csproj? Это команда Foo или команда Bar?

Ответ 2

Я исправляю проблему, изменяя путь подсказки в файле fil, чтобы содержать переменную $(SolutionDir):

Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <HintPath>$(SolutionDir)packages\EntityFramework.6.1.3\lib\net40\EntityFramework.dll</HintPath>

Ответ 3

Почему бы не иметь common.csproj как отдельную сборку, с которой вы ссылаетесь, и имеет свои собственные зависимости, а не те, которые находятся в ее решении.

Поступая таким образом, вы защищаете общее от foo или bar, обновляя указанный пакет и разбивая его.

Ответ 4

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

Относительный путь в этом случае не работает, абсолютные пути в случае диска совпадения заменяются относительными, а также не работают.

Наше решение состоит в том, чтобы избавиться от относительного пути. Вы можете сделать это, если поместите NuGetPackages на отдельный диск. так:

net use /persistent:yes p: \\localhost\C$\NuGetPackagesDiskFolder

Любое имя папки, в которой вы не найдете После этого вы можете указать реальный абсолютный путь в NuGet.Config

<config>
<add key="repositorypath" value="p:\NuGetPackages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>

После удаления файлов suo

ps: Будет ли небольшая проблема с изменением существующих решений, если они живут в sourcecontrol Самый простой способ - исправить путь к p:\NuGetPackages в каждом .csproj В противном случае необходимо переустановить все ссылки и вручную отменить все packages.config, помеченные как удаленные в sourcecontrol