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
