일부 프로젝트가 여러 솔루션에 포함 된 경우 모든 솔루션에 대한 공통 너겟 패키지 폴더 설정

일부 프로젝트가 여러 솔루션에 포함 된 경우 모든 솔루션에 대한 공통 너겟 패키지 폴더 설정

---

외부 및 내부 패키지 소스에서 패키지를 검색하기 위해 NuGet을 사용하여 매우 편리합니다. 그러나 패키지마다 기본적으로 솔루션마다 저장되어 NuGet 참조가있는 일부 프로젝트가 여러 솔루션에 포함되어 있으면 매우 실망 스럽습니다. 그런 다음 다른 개발자 나 빌드 시스템에서 실제로 사용할 수없는 다른 솔루션 패키지 폴더로 참조가 변경됩니다.

NuGet 릴리스 2.1에서 공통 패키지 위치 (아마도 프로젝트 루트 레벨에서 TFS 소스 제어를 사용하고 있음)를 지적하는 방법이 있음을 알았습니다 ( 릴리스 노트 참조) . NuGet v2.7을 사용하고 있습니다.

그러나 나는 이것의 영향을 보지 않고 nuget.config 파일을 추가하려고 시도했습니다. 패키지는 여전히 솔루션 폴더에 저장됩니다. 내가 놓친 것이 있습니까? 누가 그 질문에 대답하는지에 따라 nuget.config 파일에 추가 할 xml 노드의 다른 구조가있는 것 같습니다. Schwarzie는 다른 Stackoverflow 스레드 에 대해 제안 합니다 .

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

NuGet 2.1 릴리스 정보 (위 링크 참조)는 다음 형식을 제안합니다.

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

나는 이것들 중 어느 하나 또는 둘 다가 결국 작동할지 모르겠습니다. 솔루션 수준에서 두 가지를 모두 시도했습니다. nuget.config 파일을 TFS 프로젝트 루트 레벨에 배치 할 수 있습니까, 아니면 솔루션 디렉토리에 있어야합니까? NuGet은 특정 순서로 이러한 파일의 설정을 읽고 적용하는 것으로 보입니다. 솔루션 레벨의 nuget.config 파일이 TFS 프로젝트 루트 레벨의 파일을 대체하는 여러 레벨로 설정하는 것이 합리적입니다. 이것을 명확히 할 수 있습니까?

해당 참조가 작동하려면 설치된 모든 패키지를 제거해야합니까? 누군가 솔루션 특정 너겟 사용법에서 여러 솔루션에 속한 프로젝트가 필요한 너겟 패키지를 찾을 수있는 공통 패키지 폴더로 이동하는 단계별 지침을 제공 할 수 있다면 좋을 것입니다.

---

하나 이상의 솔루션에서 참조 된 프로젝트가있는 외부 및 내부 패키지 소스와 비슷한 상황이 있습니다. 방금 오늘 코드 기반 중 하나를 사용 하여이 작업을 수행했으며 개발자 워크 스테이션 및 빌드 서버와 함께 작동하는 것 같습니다. 아래 프로세스는이 시나리오를 염두에두고 있습니다 (공통 패키지 폴더를 다른 곳에 배치하는 것은 어렵지 않습니다).

• 코드베이스
  • 프로젝트 A
  • 프로젝트 B
  • 프로젝트 C
  • 솔루션
    • 해결책 1
    • 해결책 2
    • 해결책 3
    • 패키지 (모든 솔루션이 공유하는 공통 패키지)

Visual Studio 2015 업데이트 3을 사용하여 NuGet 3.5.0.1484부터 답변 업데이트

이 프로세스는 처음에이 문제를 해결하고 업데이트 할 때라고 생각했을 때보 다 조금 쉬워졌습니다. 일반적으로 프로세스는 적은 단계로 동일합니다. 결과는 다음을 해결하거나 제공하는 프로세스입니다.

• 소스 코드 제어에 커밋해야하는 모든 것이 솔루션에서 표시되고 추적됩니다.
• Visual Studio에서 패키지 관리자를 사용하여 새 패키지를 설치하거나 패키지를 업데이트하면 올바른 저장소 경로가 사용됩니다
• 초기 구성 후 .csproj 파일을 해킹하지 않습니다
• 개발자 워크 스테이션을 수정하지 않음 (체크 아웃시 코드 작성 준비)

알고 있어야 할 몇 가지 잠재적 단점이 있습니다 (YMMV는 아직 경험하지 못했습니다). 아래에서 Benol의 답변과 의견을 참조하십시오.

NuGet.Config 추가

\ Solutions \ 폴더의 루트에 NuGet.Config 파일을 작성하려고합니다. 이 파일이 작성하는 UTF-8 인코딩 파일인지 확인하십시오.이를 수행하는 방법을 모르면 Visual Studio의 파일-> 새로 만들기-> 파일 메뉴를 사용하여 XML 파일 템플리트를 선택하십시오. NuGet.Config에 다음을 추가하십시오.

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

repositoryPath 설정의 경우 $ 토큰을 사용하여 절대 경로 또는 상대 경로 (권장)를 지정할 수 있습니다. $ 토큰은 NuGet.Config가있는 위치를 기준으로합니다 ($ 토큰은 실제로 NuGet.Config 위치 보다 한 레벨 아래 에 있습니다). 따라서 \ Solutions \ NuGet.Config가 있고 \ Solutions \ Packages를 원하면 $ \ .. \ Packages를 값으로 지정해야합니다.

다음으로 "NuGet"(솔루션을 마우스 오른쪽 단추로 클릭하고 추가-> 새 솔루션 폴더)과 같은 솔루션 폴더에 솔루션 폴더를 추가합니다. 솔루션 폴더는 Visual Studio 솔루션에만 존재하는 가상 폴더이며 드라이브에 실제 폴더를 만들지 않으며 어디서나 파일을 참조 할 수 있습니다. "NuGet"솔루션 폴더를 마우스 오른쪽 단추로 클릭 한 다음 추가-> 기존 항목을 선택하고 \ Solutions \ NuGet.Config를 선택하십시오.

우리가이 작업을 수행하는 이유는 솔루션에서 볼 수 있고 소스 코드 제어에 제대로 적용되는지 확인하는 데 도움이되기 때문입니다. 공유 프로젝트에 참여하는 코드베이스의 각 솔루션에 대해이 단계를 수행 할 수 있습니다.

NuGet.Config 파일을 .sln 파일 위의 \ Solutions \에 배치하면 NuGet이 "현재 작업 디렉토리"에서 폴더 구조를 재귀 적으로 탐색하여 사용할 NuGet.Config 파일을 찾습니다. "현재 작업 디렉토리"는 여기서 몇 가지 다른 것을 의미합니다. 하나는 NuGet.exe의 실행 경로이고 다른 하나는 .sln 파일의 위치입니다.

패키지 폴더 전환

먼저 각 솔루션 폴더를 살펴보고 존재하는 \ Packages \ 폴더를 삭제하는 것이 좋습니다 (먼저 Visual Studio를 닫아야합니다). 이렇게하면 NuGet이 새로 구성된 \ Packages \ 폴더를 어디에 두는지 쉽게 알 수 있으며 잘못된 \ Packages \ 폴더에 대한 링크가 실패한 후 수정할 수 있습니다.

Visual Studio에서 솔루션을 열고 모두 다시 작성을 시작하십시오. 나타날 모든 빌드 오류를 무시하십시오.이 시점에서 예상됩니다. 그러나 빌드 프로세스 시작시 NuGet 패키지 복원 기능이 시작됩니다. \ Solutions \ Packages \ 폴더가 원하는 지점에 생성되었는지 확인하십시오. 그렇지 않은 경우 구성을 검토하십시오.

이제 솔루션의 각 프로젝트에 대해 다음을 수행하려고합니다.

1. 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 프로젝트 언로드를 선택하십시오.
2. 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 Edit your-xxx.csproj를 선택하십시오.
3. \ packages \에 대한 참조를 찾아 새 위치로 업데이트하십시오.
   • 이들 중 대부분은 <HintPath> 참조이지만 전부는 아닙니다. 예를 들어 WebGrease와 Microsoft.Bcl.Build에는 업데이트해야 할 별도의 경로 설정이 있습니다.
4. .csproj를 저장 한 다음 프로젝트를 마우스 오른쪽 단추로 클릭하고 프로젝트 다시로드를 선택하십시오.

.csproj 파일이 모두 업데이트되면 다른 모두 다시 빌드를 시작하면 누락 된 참조에 대한 빌드 오류가 더 이상 발생하지 않습니다. 이제 작업이 완료되었으며 이제 공유 패키지 폴더를 사용하도록 NuGet을 구성했습니다.

VStudio 2012의 NuGet 2.7.1 (2.7.40906.75) 기준

가장 먼저 명심해야 할 것은 nuget.config가 nuget 패키지 시스템의 모든 경로 설정을 제어하지는 않는다는 것입니다. 이것은 특히 이해하기 혼란 스러웠습니다. 특히 문제는 msbuild 및 Visual Studio (msbuild 호출)가 nuget.config의 경로를 사용하지 않고 nuget.targets 파일에서 경로를 재정의한다는 것입니다.

환경 준비

먼저 솔루션 폴더를 살펴보고 존재하는 모든 \ packages \ 폴더를 제거합니다. 이렇게하면 모든 패키지가 올바른 폴더에 눈에 띄게 설치되고 솔루션 전체에서 잘못된 경로 참조를 발견하는 데 도움이됩니다. 다음으로 최신 Nuget Visual Studio 확장이 설치되어 있는지 확인하십시오. 또한 각 솔루션에 최신 nuget.exe가 설치되어 있는지 확인하십시오. 명령 프롬프트를 열고 각 $ (SolutionDir) \ .nuget \ 폴더로 이동하여 다음 명령을 실행하십시오.

nuget update -self

NuGet에 대한 공통 패키지 폴더 경로 설정

각 $ (SolutionDir) \ .nuget \ NuGet.Config를 열고 <configuration> 섹션 안에 다음을 추가하십시오.

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

Note: You can use an absolute path or a relative path. Keep in mind, if you are using a relative path with $ that it is relative to one level below the location of the NuGet.Config (believe this is a bug).

Setting common package folder path for MSBuild and Visual Studio

Open each $(SolutionDir)\ .nuget\NuGet.targets and modify the following section (note that for non-Windows there is another section below it):

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
    <PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>

Update PackagesDir to be

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

Note: The GetFullPath will resolve our relative path into an absolute path.

Restoring all of the nuget packages into common folder

Open a command prompt and goto each $(SolutionDir)\ .nuget and execute the following command:

nuget restore ..\YourSolution.sln

At this point, you should have a single \packages\ folder in your common location and none within any of your solution folders. If not, then verify your paths.

Fixing project references

Open every .csproj file in a text editor and find any references to \packages and update them to the correct path. Most of these will be <HintPath> references, but not all of them. For example, WebGrease and Microsoft.Bcl.Build will have separate path settings that will need to be updated.

Build your solution

Open your solution in Visual Studio and kick off a build. If it complains about missing packages that need to be restored, don't assume that the package is missing and needs to be restored (error can be misleading). It could be a bad path in one of your .csproj files. Check that first before restoring the package.

Have a build error about missing packages?

If you have already verified that the paths in your .csproj files are correct, then you have two options to try. If this is the result of updating your code from source code control then you can try checking out a clean copy and then building that. This worked for one of our developers and I think there was an artifact in the .suo file or something similar. The other option is to manually force a package restore using the command line in the .nuget folder of the solution in question:

nuget restore ..\YourSolution.sln

---

Instead of setting common package location for all projects, it is also possible to change HintPath in project as follow:

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

In most cases there in shared project will be only few packages, so you can easily change it.

I think it is better solution, when you branching code, when setting common repo, you must change relative path, in this solution you don't need to do this.

---

My experience trying this with the latest version of NuGet (2.7) and VS2012:

• Delete the .nuget folder (on disk and in solution)
• Put a NuGet.Config file in a common parent folder of all solutions
• Delete any existing packages folders
• Go through all csproj files and change HintPaths to point to the new location
• Profit

In my case, I wanted to put all packages in .packages, so my NuGet.Config looked like below.

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

Note that there are a few 'strange' things that can happen, but I think they're bearable:

• If you 'Update' a package from one solution, it will promptly delete the older version from your packages folder (it can't know whether you have another solution which is pointing there). This doesn't bother me greatly, as the other solution will just restore when required.
• If you try to add package from right-click-on-solution, if the package is already present in another solution, it will see that it's there and show you the 'green tick' instead of the 'install' button. I usually install from right-click-on-project, so this doesn't bother me at all.

Disclaimer: I just tried this today, I don't have any long term experience to back it up!

---

I have NuGet version 2.8.50926 with VS 2013. You don't need to use multiple nuget.config files, or use complex directory structures. Just modify the default file located here:

%APPDATA%\Roaming\NuGet\NuGet.Config

Here is the content of my file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

So all packages go to the "C:\Projects\nugetpackages" folder, no matter where the solution is.

In all your solutions, just delete existing "packages" folders. Then build your solution, and NuGet will automatically restore the missing packages in the new, centralized directory you specified.

---

Already there is no need to modify nuget.targets. It has been fixed in nuget 2.8 (http://nuget.codeplex.com/workitem/2921). You only need to set repositorypath.

---

From Visual Studio 2013 Update 4 and Nugget Package Manager version > 2.8.5...

Create nuget.config file in root of repository.

file content:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

This will cause that all packages will go to packages folder on level of your's nuget.config file.

Now you can go for each .sln nuget console with command 'update-package -reinstall'

If you have like multiple repository at the same level and what to share the same package folder across them try use way to go one folder up.

 <add key="repositoryPath" value="..\packages" />

But this way you cause that nuget packages reference csproj is pointing one folder up outside you repositorys path.

---

I've concocted a NuGet package that transparently converts all NuGet references in a project to a $(SolutionDir)-relative format. It does so using build-time XSLT transform, so you don't need to hack your project file by hand. You can update your packages freely, it will break nothing.

https://www.nuget.org/packages/NugetRelativeRefs

Or you if you use Visual Studio 2015 Update 3, you can just migrate your package references to project.json form as described here: https://oren.codes/2016/02/08/project-json-all-the-things

---

Updating my experience with nuget 2.8.3. It was relatively simple. All did was enabled package restore from right clicking solution. Edited NuGet.Config and added these lines :

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

Then rebuilt the solution, it downloaded all packages to my desired folder and updated references automatically. I did the same for all of my other projects, where only incremental packages were downloaded and existing packages were referenced. Hence a common package repository for all projects as been set.

Here is a step by step procedure to enable package restore.

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

---

Just hardlink /packages to the desired shared location. Then your project won't be broken for other users, that do not have a special packages location.

Open a command prompt as admin and use

mklink /prefix link_path Target_file/folder_path

---

For any significant solution, the above answers will fall short. Quite simply, a complex TFS workspace structure with differing relative paths, branching, shared projects etc. make a single central repository impossible.

Using ($SolutionDir) is a step in the right direction, but hand coding the csproj file with ($SolutionDir) would become quite tedious in a code base with hundreds of packages that are updated regularly (everytime update occurs, the HintPath gets overwritten with a new relative path). What happens if you have to run Update-Package -Reinstall.

There is a great solution called NugetReferenceHintPathRewrite. It automates the injection of ($SolutionDir) into the HintPaths just prior to build (without actually changing the csproj file). I imagine it could easily be incorporated into automated build systems

---

A short summary for those on VS 2013 professional with NuGet Version: 2.8.60318.667

This is how you would direct packages to a path relative to the .nuget folder:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

For example, if your solution (.sln file) resides in C:\Projects\MySolution, when you enable NuGet package restore, the .nuget folder is created like so: C:\Projects\MySolution.nuget and the packages will be downloaded to a directory like so: C:\Projects\MySolution\Dependencies

NOTE: For some (unknown) reason, everytime I update the "repositoryPath", I have to close and reopen the solution for the changes to take effect

---

for those using paket as their package manager, there's an auto-symlink option for your dependencies file:

storage: symlink

btw: paket leverages nuget

reference: https://fsprojects.github.io/Paket/dependencies-file.html

If you want to modify as little as possible, you could just clean up subdirectories periodically with a script. ie. Nuget's default behaviour is to copy files from a global location to a local packages folder, so delete these files afterwards.

---

These are the instructions as of NuGet 2.1: http://docs.nuget.org/docs/release-notes/nuget-2.1

No need to edit solution level files.

Works with Visual Studio 2013 and three solutions sharing projects.

Don't forget to update solution level NuGet (each nuget.exe in .nuget folders).

참고URL : https://stackoverflow.com/questions/18376313/setting-up-a-common-nuget-packages-folder-for-all-solutions-when-some-projects-a