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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

Я исправляю проблему, изменяя путь подсказки в файле проекта, чтобы она содержала переменную $ (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>

Answer 3

В нашем случае, многие разработчики и решения с 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. В противном случае необходимо переустановить все ссылки и вручную отменитьвсе package.config помечены как удаленные в sourcecontrol

Answer 4

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

Этим вы защищаете common от обновления foo или bar, на которое ссылаютсяпакет и ломая его.