Thiết lập thư mục gói nuget chung cho tất cả các giải pháp khi một số dự án được bao gồm trong nhiều giải pháp


137

Tôi đã và đang sử dụng NuGet để lấy các gói từ các nguồn gói bên ngoài và bên trong, rất thuận tiện. Nhưng tôi đã nhận ra rằng các gói theo mặc định được lưu trữ trên mỗi giải pháp, điều này rất bực bội khi một số dự án có tham chiếu NuGet được đưa vào một số giải pháp. Sau đó, các tham chiếu được thay đổi thành thư mục gói giải pháp khác mà thực sự không có sẵn cho nhà phát triển hoặc máy xây dựng khác.

Tôi đã thấy rằng có nhiều cách để chỉ ra một vị trí gói chung (có lẽ ở cấp gốc của dự án, chúng tôi đang sử dụng kiểm soát nguồn TFS) với bản phát hành 2.1 của NuGet, xem ghi chú phát hành . Tôi đang sử dụng NuGet v2.7

Nhưng tôi đã cố gắng thêm các tệp nuget.config mà không thấy bất kỳ ảnh hưởng nào của việc này. Các gói vẫn được lưu trong thư mục giải pháp. Có bất cứ điều gì tôi đã bỏ lỡ? Dường như có các cấu trúc khác nhau của nút xml để thêm vào tệp nuget.config, tùy thuộc vào người trả lời câu hỏi đó: Schwarzie gợi ý về một luồng Stackoverflow khác :

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

Ghi chú phát hành cho NuGet 2.1 (xem liên kết ở trên) gợi ý định dạng này:

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

Tôi không biết cái nào trong số này, hoặc cái nào, hoặc cả hai sẽ hoạt động cuối cùng. Tôi đã thử cả ở cấp độ giải pháp. Tệp nuget.config có thể được đặt ở cấp gốc của dự án TFS không, hay nó phải nằm trong thư mục giải pháp? Dường như NuGet đọc và áp dụng các cài đặt từ các tệp này theo một thứ tự nhất định, tại sao việc thêm chúng ở một số cấp độ lại có ý nghĩa, trong đó tệp nuget.config ở cấp độ giải pháp sẽ ghi đè lên một cấp độ gốc của dự án TFS. Điều này có thể được làm rõ?

Tôi có cần xóa tất cả các gói đã cài đặt trước khi các tham chiếu đó hoạt động không? Tôi rất thích nếu ai đó có thể cung cấp hướng dẫn từng bước để chuyển từ việc sử dụng nuget dành riêng cho giải pháp sang thư mục gói chung nơi các dự án thuộc một số giải pháp có thể tìm thấy các gói nuget cần thiết của họ.


3
Tôi nghi ngờ rằng câu trả lời ngắn cho câu hỏi của bạn (ẩn trong câu trả lời của Vermis bên dưới) là bạn đã bỏ lỡ $phía trước con đường tương đối. Ngoài ra, câu trả lời cho câu hỏi của bạn về các tệp NuGet.Config có ở đây . Đầu tiên, nó tìm trong .nuget, sau đó trong tất cả các thư mục mẹ, sau đó vào tệp 'toàn cầu' trong AppData của bạn: sau đó áp dụng chúng theo thứ tự REVERSE (bất kể điều đó có nghĩa là gì).
Stewol 18/12/13

Điều này có vẻ là khó khăn. Có một công cụ gọi là Paket có thể là giải pháp cho vấn đề này: fsprojects.github.io/Paket
Tuomas Hietanen

Nhận xét muộn. Chỉ muốn thêm rằng Visual Studio cần được khởi động lại nếu bạn chạy nó khi bạn bắt đầu thay đổi này, vì các tệp nuget.config dường như được đọc trong quá trình khởi động VS. Ngoài ra, tôi không có vấn đề gì nếu không có $, chỉ không bắt đầu bằng dấu gạch chéo ngược.
MBWise

Câu trả lời:


147

Tôi có một tình huống tương tự với các nguồn gói bên ngoài và bên trong với các dự án được tham chiếu trong nhiều hơn một giải pháp. Tôi vừa mới làm việc với một trong những cơ sở mã của chúng tôi ngày hôm nay và dường như nó đang làm việc với các máy trạm của nhà phát triển và máy chủ xây dựng của chúng tôi. Quá trình dưới đây có kịch bản này trong tâm trí (mặc dù không khó để thích nghi để có thư mục gói chung khác ở đâu).

  • Cơ sở mã hóa
    • Dự án A
    • Dự án B
    • Dự án C
    • Các giải pháp
      • Giải pháp 1
      • Giải pháp 2
      • Giải pháp 3
      • Các gói (đây là gói chung được chia sẻ bởi tất cả các giải pháp)

Câu trả lời được cập nhật kể từ NuGet 3.5.0.1484 với Visual Studio 2015 Update 3

Quá trình này bây giờ dễ dàng hơn một chút so với khi tôi ban đầu giải quyết vấn đề này và nghĩ rằng đã đến lúc cập nhật nó. Nói chung, quá trình là như nhau chỉ với ít bước hơn. Kết quả là một quá trình giải quyết hoặc cung cấp như sau:

  • Mọi thứ cần được cam kết để kiểm soát mã nguồn đều hiển thị và được theo dõi trong giải pháp
  • Cài đặt gói mới hoặc cập nhật gói bằng Trình quản lý gói trong Visual Studio sẽ sử dụng đường dẫn kho lưu trữ chính xác
  • Sau cấu hình ban đầu, không hack các tệp .csproj
  • Không có sửa đổi của máy trạm dành cho nhà phát triển (Mã được xây dựng sẵn sàng khi thanh toán)

Có một số nhược điểm tiềm năng cần lưu ý (Tôi chưa trải nghiệm chúng, YMMV). Xem câu trả lời và ý kiến của Benol bên dưới.

Thêm NuGet.Config

Bạn sẽ muốn tạo tệp NuGet.Config trong thư mục gốc của thư mục \ Solutions \. Đảm bảo đây là tệp được mã hóa UTF-8 mà bạn tạo, nếu bạn không chắc chắn cách thực hiện việc này, hãy sử dụng menu Tệp của Visual Studio-> Mới-> Tệp, sau đó chọn mẫu Tệp XML. Thêm vào NuGet.Config như sau:

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

Đối với cài đặt repositoryPath, bạn có thể chỉ định đường dẫn tuyệt đối hoặc đường dẫn tương đối (được khuyến nghị) bằng cách sử dụng mã thông báo $. Mã thông báo $ dựa trên vị trí của NuGet.Config (Mã thông báo $ thực sự có liên quan đến một cấp dưới đây vị trí của NuGet.Config). Vì vậy, nếu tôi có \ Solutions \ NuGet.Config và tôi muốn \ Solutions \ Gói tôi sẽ cần chỉ định $ \ .. \ Gói làm giá trị.

Tiếp theo, bạn sẽ muốn thêm Thư mục Giải pháp cho giải pháp của mình được gọi là "NuGet" (Nhấp chuột phải vào giải pháp của bạn, Thêm-> Thư mục Giải pháp mới). Thư mục giải pháp là các thư mục ảo chỉ tồn tại trong giải pháp Visual Studio và sẽ không tạo thư mục thực trên ổ đĩa (và bạn có thể tham chiếu các tệp từ bất kỳ đâu). Nhấp chuột phải vào thư mục giải pháp "NuGet" của bạn, sau đó Thêm-> Mục hiện có và chọn \ Solutions \ NuGet.Config.

Lý do chúng tôi đang làm điều này là để nó hiển thị trong giải pháp và sẽ giúp đảm bảo rằng nó được cam kết đúng với kiểm soát mã nguồn của bạn. Bạn có thể muốn thực hiện bước này cho từng giải pháp trong cơ sở mã đang tham gia với các dự án được chia sẻ của bạn.

Bằng cách đặt tệp NuGet.Config trong \ Solutions \ trên bất kỳ tệp .sln nào, chúng tôi đang lợi dụng thực tế là NuGet sẽ điều hướng đệ quy cấu trúc thư mục từ "thư mục làm việc hiện tại" đang tìm kiếm tệp NuGet.Config để sử dụng. "Thư mục làm việc hiện tại" có nghĩa là một vài thứ khác nhau ở đây, một là đường dẫn thực thi của NuGet.exe và thứ hai là vị trí của tệp .sln.

Chuyển qua thư mục gói của bạn

Trước tiên, tôi thực sự khuyên bạn nên xem qua từng thư mục giải pháp của mình và xóa mọi thư mục \ Gói \ tồn tại (trước tiên bạn cần đóng Visual Studio). Điều này giúp dễ dàng hơn để xem NuGet đang đặt thư mục \ Gói \ mới được cấu hình của bạn và đảm bảo rằng mọi liên kết đến thư mục \ Gói \ sẽ bị lỗi và sau đó có thể được sửa.

Mở giải pháp của bạn trong Visual Studio và khởi động Rebuild All. Bỏ qua tất cả các lỗi xây dựng bạn sẽ nhận được, điều này được dự kiến ​​tại thời điểm này. Điều này sẽ khởi động tính năng khôi phục gói NuGet khi bắt đầu quá trình xây dựng. Xác minh rằng thư mục \ Solutions \ Gói \ của bạn đã được tạo ở vị trí bạn muốn. Nếu không, hãy xem lại cấu hình của bạn.

Bây giờ, đối với mỗi dự án trong giải pháp của bạn, bạn sẽ muốn:

  1. Nhấp chuột phải vào dự án và chọn Unload Project
  2. Nhấp chuột phải vào dự án và chọn Chỉnh sửa của bạn-xxx.csproj
  3. Tìm bất kỳ tài liệu tham khảo nào cho \ gói \ và cập nhật chúng lên vị trí mới.
    • Hầu hết trong số này sẽ là tài liệu tham khảo <HintPath>, nhưng không phải tất cả. Ví dụ: WebGreas và Microsoft.Bcl.Build sẽ có các cài đặt đường dẫn riêng biệt cần được cập nhật.
  4. Lưu .csproj và sau đó nhấp chuột phải vào dự án và chọn Tải lại dự án

Khi tất cả các tệp .csproj của bạn đã được cập nhật, hãy khởi động một Rebuild All khác và bạn sẽ không còn lỗi xây dựng nào về các tham chiếu bị thiếu. Tại thời điểm này, bạn đã hoàn tất và bây giờ có cấu hình NuGet để sử dụng thư mục Gói chia sẻ.

Kể từ NuGet 2.7.1 (2.7.40906.75) với VStudio 2012

Trước tiên, điều cần lưu ý là nuget.config không kiểm soát tất cả các cài đặt đường dẫn trong hệ thống gói nuget. Điều này đặc biệt khó hiểu để tìm ra. Cụ thể, vấn đề là msbuild và Visual Studio (gọi msbuild) không sử dụng đường dẫn trong nuget.config mà thay vào đó là ghi đè nó trong tệp nuget.target.

Chuẩn bị môi trường

Đầu tiên, tôi sẽ đi qua thư mục của giải pháp của bạn và xóa tất cả \ gói \ thư mục tồn tại. Điều này sẽ giúp đảm bảo rằng tất cả các gói được cài đặt rõ ràng vào thư mục chính xác và để giúp khám phá mọi tham chiếu đường dẫn xấu trong các giải pháp của bạn. Tiếp theo, tôi sẽ đảm bảo bạn đã cài đặt tiện ích mở rộng Visual Studio mới nhất. Tôi cũng sẽ đảm bảo rằng bạn đã cài đặt nuget.exe mới nhất vào mỗi giải pháp. Mở một dấu nhắc lệnh và đi vào từng thư mục $ (SolutionDir) \ .nuget \ và thực hiện lệnh sau:

nuget update -self

Đặt đường dẫn thư mục gói chung cho NuGet

Mở mỗi $ (SolutionDir) \ .nuget \ NuGet.Config và thêm phần sau vào phần <configure>:

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

Lưu ý: Bạn có thể sử dụng một đường dẫn tuyệt đối hoặc một đường dẫn tương đối. Hãy ghi nhớ, nếu bạn đang sử dụng một đường dẫn tương đối với $ mà nó có liên quan đến một cấp dưới vị trí của NuGet.Config (tin rằng đây là một lỗi).

Đặt đường dẫn thư mục gói chung cho MSBuild và Visual Studio

Mở mỗi $ (SolutionDir) \ .nuget \ NuGet.target và sửa đổi phần sau (lưu ý rằng đối với người không dùng Windows, có một phần khác bên dưới nó):

<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>

Cập nhật các góiDir để được

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

Lưu ý: GetFullPath sẽ giải quyết đường dẫn tương đối của chúng ta thành một đường dẫn tuyệt đối.

Khôi phục tất cả các gói nuget vào thư mục chung

Mở một dấu nhắc lệnh và goto mỗi $ (SolutionDir) \ .nuget và thực hiện lệnh sau:

nuget restore ..\YourSolution.sln

Tại thời điểm này, bạn nên có một thư mục \ gói \ ở vị trí chung và không có trong bất kỳ thư mục giải pháp nào. Nếu không, sau đó xác minh đường dẫn của bạn.

Sửa chữa tài liệu tham khảo dự án

Mở mọi tệp .csproj trong trình soạn thảo văn bản và tìm bất kỳ tham chiếu nào đến \ gói và cập nhật chúng theo đúng đường dẫn. Hầu hết trong số này sẽ là tài liệu tham khảo <HintPath>, nhưng không phải tất cả. Ví dụ: WebGreas và Microsoft.Bcl.Build sẽ có các cài đặt đường dẫn riêng biệt cần được cập nhật.

Xây dựng giải pháp của bạn

Mở giải pháp của bạn trong Visual Studio và khởi động một bản dựng. Nếu nó phàn nàn về các gói bị thiếu cần được khôi phục, đừng cho rằng gói bị thiếu và cần được khôi phục (lỗi có thể gây hiểu nhầm). Nó có thể là một đường dẫn xấu trong một trong các tệp .csproj của bạn. Kiểm tra trước khi khôi phục gói.

Có một lỗi xây dựng về các gói bị thiếu?

Nếu bạn đã xác minh rằng các đường dẫn trong tệp .csproj của bạn là chính xác, thì bạn có hai tùy chọn để thử. Nếu đây là kết quả của việc cập nhật mã của bạn từ kiểm soát mã nguồn thì bạn có thể thử kiểm tra một bản sao sạch và sau đó xây dựng nó. Điều này đã làm việc cho một trong những nhà phát triển của chúng tôi và tôi nghĩ rằng có một tạo tác trong tệp .suo hoặc một cái gì đó tương tự. Tùy chọn khác là buộc thủ công khôi phục gói bằng cách sử dụng dòng lệnh trong thư mục .nuget của giải pháp được đề cập:

nuget restore ..\YourSolution.sln

Cảm ơn câu trả lời dài cho vấn đề dài dòng của tôi. Tôi sẽ thử giải pháp này và lấy lại cho bạn.
Thảm Isaksson

Nó có hoạt động để có cả .sln trong cùng một thư mục không? họ sẽ kết thúc việc chia sẻ cùng một thư mục gói?
tofutim

7
Tôi nghĩ rằng câu trả lời này cho thấy nuget cứng nhắc như thế nào. Phải tạo ra một cấu trúc phức tạp, cứng nhắc để cho phép một khái niệm đơn giản như vậy: - "chia sẻ cùng một tổ hợp giữa các giải pháp" là dấu hiệu cho thấy thiết kế kém của toàn bộ.
Mick

1
Điều gì cũng hoạt động để sửa HintPaths - sau khi bạn cập nhật NuGet.config theo ý thích của mình, trong bảng điều khiển Gói-Trình quản lý chạy "Cập nhật-Gói -reinstall". Điều này sẽ cài đặt lại tất cả các gói, sửa lỗi gợi ý của họ quá. Sau này - bạn có thể còn lại một số di tích (tôi đã có trong một số dự án bạc - việc nhập khẩu mục tiêu / công trình "cũ" vẫn còn đó)
johannes.colmsee

1
@Vermis Nếu tôi thiết lập thư mục gói nuget chung cho tất cả các giải pháp của mình. điều gì sẽ tác động đến điều đó đối với bản dựng Azure Devops của tôi?
Pankaj Devrani

39

Thay vì đặt vị trí gói chung cho tất cả các dự án, cũng có thể thay đổi HintPath trong dự án như sau:

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

Trong hầu hết các trường hợp, trong dự án chia sẻ sẽ chỉ có một vài gói, vì vậy bạn có thể dễ dàng thay đổi nó.

Tôi nghĩ rằng đó là giải pháp tốt hơn, khi bạn phân nhánh mã, khi đặt repo chung, bạn phải thay đổi đường dẫn tương đối, trong giải pháp này bạn không cần phải làm điều này.


2
Adam là chính xác. Đây là giải pháp đơn giản nhất cho một vấn đề ngu ngốc đáng kinh ngạc.
lapsus

1
Đó là giải pháp tuyệt vời. đơn giản và rõ ràng không yêu cầu xây dựng lại cấu trúc mã.
RredCat

2
AFAIK $ (SolutionDir) chỉ được đặt khi quá trình xây dựng được thực hiện thông qua VS. Vì vậy, không có tòa nhà trực tiếp thông qua msbuild.exe, trừ khi bạn đang thiết lập / p: SolutionDir = path
Lars Nielsen

điều này có thể được đặt tự động tại đây% APPDATA% \ Roaming \ NuGet \ NuGet.Config
Korayem

15
Điều này hoạt động rất tốt cho đến khi bạn cập nhật gói và ghi đè HintPath bằng một đường dẫn tương đối mới. Trở nên khá tẻ nhạt trong một giải pháp lớn với rất nhiều gói. Chúa cấm bạn phải chạy Gói cập nhật -Reinstall ...
gravidThoughts 8/8/2016

22

Trải nghiệm của tôi khi thử điều này với phiên bản mới nhất của NuGet (2.7) và VS2012:

  • Xóa thư mục .nuget (trên đĩa và trong giải pháp)
  • Đặt tệp NuGet.Config vào thư mục gốc chung của tất cả các giải pháp
  • Xóa mọi thư mục gói hiện có
  • Đi qua tất cả các tệp csproj và thay đổi HintPath để trỏ đến vị trí mới
  • Lợi nhuận

Trong trường hợp của tôi, tôi muốn đặt tất cả các gói vào .packages, vì vậy NuGet.Config của tôi trông như dưới đây.

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

Lưu ý rằng có một vài điều 'lạ' có thể xảy ra, nhưng tôi nghĩ chúng có thể chịu được:

  • Nếu bạn 'Cập nhật' một gói từ một giải pháp, nó sẽ nhanh chóng xóa phiên bản cũ hơn khỏi thư mục gói của bạn (nó không thể biết liệu bạn có giải pháp nào khác đang chỉ vào đó không). Điều này không làm phiền tôi nhiều, vì giải pháp khác sẽ chỉ khôi phục khi được yêu cầu.
  • Nếu bạn cố gắng thêm gói từ giải pháp nhấp chuột phải, nếu gói đó đã có trong một giải pháp khác, nó sẽ thấy rằng nó ở đó và hiển thị cho bạn 'dấu tick xanh' thay vì nút 'cài đặt'. Tôi thường cài đặt từ nhấp chuột phải vào dự án, vì vậy điều này hoàn toàn không làm phiền tôi.

Tuyên bố miễn trừ trách nhiệm : Tôi mới thử điều này hôm nay, tôi không có kinh nghiệm lâu dài để sao lưu!


4
Đây là những cách đề nghị để làm điều đó. Cách tích hợp msbuild cũ để thực hiện khôi phục nuget trong câu trả lời được chấp nhận là pita và tôi có thể xác nhận đặt NuGet.config cùng với công việc sln cho chúng tôi với Khôi phục gói tự động. Đặt nó trong một thư mục cha mẹ phổ biến tôi không thể xác nhận.
9swampy

1
Làm cách nào để đặt NuGet.Config vào thư mục gốc chung cho tất cả các giải pháp (trong TFS) để chúng có thể tham khảo? Cách duy nhất tôi biết là thư mục .nuget trong mọi giải pháp có tệp nuget.config; và nếu "repositorypath value = .packages" thì nó sẽ tạo một thư mục con bên dưới .nuget như: C: \ TFS \ Comp \ Ent \ SolABC \ .nuget \ .packages - điều này không giải quyết các dự án / giải pháp lồng nhau một cách sạch sẽ cũng nên hoạt động trên bản dựng TFS tự động. Câu trả lời được chấp nhận yêu cầu một số công việc được mã hóa bằng tay, cộng với "giá trị kho lưu trữ = $ \ .. \ .. \ .. \ Gói này không hoạt động nếu có các dự án lồng nhau có đường dẫn tương đối khác nhau.
hB0

2
Hoạt động với Visual Studio 2015 và Nuget 3.4.3
Hüseyin Yağlı 17/05/2016

Nó không chỉ xóa ngay gói cũ hơn, nó sẽ ghi đè và phá vỡ HintPath mà bạn đã mã hóa thành tệp csproj. @ hB0 là chính xác. Điều này chỉ hoạt động cho các giải pháp tương đối đơn giản. Một khi bạn nhận được vào một cấu trúc không gian làm việc TFS phức tạp với các nhánh, các dự án được chia sẻ, v.v. nó không thể mở rộng hiệu quả.
gravidThoughts

20

Tôi có phiên bản NuGet 2.8.50926 với VS 2013. Bạn không cần sử dụng nhiều tệp nuget.config hoặc sử dụng các cấu trúc thư mục phức tạp. Chỉ cần sửa đổi tập tin mặc định ở đây:

%APPDATA%\Roaming\NuGet\NuGet.Config

Đây là nội dung của tập tin của tôi:

<?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>

Vì vậy, tất cả các gói đều chuyển đến thư mục "C: \ Project \ nugetpackages", bất kể giải pháp ở đâu.

Trong tất cả các giải pháp của bạn, chỉ cần xóa các thư mục "gói" hiện có. Sau đó, xây dựng giải pháp của bạn và NuGet sẽ tự động khôi phục các gói bị thiếu trong thư mục mới, tập trung mà bạn đã chỉ định.


Đây là giải pháp dễ nhất cho tất cả và nó xứng đáng được yêu thương nhiều hơn!
Korayem

2
hôm nay đây là giải pháp đơn giản nhất nhưng thực sự thiếu một điều trong câu trả lời của bạn. bạn vẫn cần phải xử lý HintPath trong các tệp csproj của từng dự án. Họ sẽ không tự động nhắm mục tiêu đến con đường mới. tôi có đúng không
batmaci

Thật vậy, trong một số dự án cũ của tôi đôi khi có các tham chiếu đến thư mục gói "cũ". Tuy nhiên, đối với tôi mọi thứ đều hoạt động chính xác, vì vậy tôi đoán rằng thiết lập toàn cầu được ưu tiên.
Matthieu

đối với OSX, xem docs.microsoft.com/en-us/nuget/consume-packages/ mẹo . Tôi cũng thích ý tưởng mklink dưới đây.
sgtz


3

Từ Visual Studio 2013 Update 4 và phiên bản Trình quản lý gói Nugget> 2.8.5 ...

Tạo tập tin nuget.config trong thư mục gốc của kho lưu trữ.

nội dung tập tin:

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

Điều này sẽ khiến tất cả các gói sẽ chuyển đến thư mục gói theo cấp độ tệp nuget.config của bạn.

Bây giờ bạn có thể sử dụng cho mỗi bảng điều khiển nuget .sln với lệnh 'update-pack -reinstall'

Nếu bạn muốn có nhiều kho lưu trữ ở cùng cấp độ và những gì để chia sẻ cùng một thư mục gói trên chúng, hãy thử sử dụng cách để đi lên một thư mục.

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

Nhưng theo cách này, bạn gây ra rằng các gói nuget tham chiếu csproj đang trỏ một thư mục lên bên ngoài đường dẫn kho lưu trữ của bạn.


3

Tôi đã tạo ra một gói NuGet chuyển đổi rõ ràng tất cả các tham chiếu NuGet trong một dự án sang định dạng liên quan đến $ (SolutionDir). Nó sử dụng biến đổi XSLT thời gian xây dựng, do đó bạn không cần phải hack tệp dự án của mình bằng tay. Bạn có thể cập nhật các gói của bạn một cách tự do, nó sẽ không phá vỡ gì.

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

Hoặc nếu bạn sử dụng Visual Studio 2015 Update 3, bạn chỉ có thể di chuyển các tham chiếu gói của mình sang project.jsonmẫu như được mô tả ở đây: https://oren.codes/2016/02/08/project-json-all-the-things


Thật không may, có vẻ như Microsoft đang rời khỏi project.json . Ngoài ra, tôi thích gói nuget của bạn. Cách đây một thời gian, tôi đã sử dụng NuGetReferenceHintPathRewrite , thứ này hoạt động khá giống nhau nhưng theo cách khác
Andrey Borisko

2

Cập nhật trải nghiệm của tôi với nuget 2.8.3. Nó tương đối đơn giản. Tất cả đã được kích hoạt khôi phục gói từ giải pháp nhấp chuột phải. Đã chỉnh sửa NuGet.Config và thêm các dòng sau:

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

Sau đó, xây dựng lại giải pháp, nó tải tất cả các gói vào thư mục mong muốn của tôi và tự động cập nhật các tài liệu tham khảo. Tôi đã làm tương tự cho tất cả các dự án khác của tôi, trong đó chỉ các gói gia tăng được tải xuống và các gói hiện có được tham chiếu. Do đó một kho lưu trữ gói chung cho tất cả các dự án đã được đặt.

Dưới đây là quy trình từng bước để cho phép khôi phục gói.

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


2

Chỉ cần hardlink / gói đến vị trí chia sẻ mong muốn. Sau đó, dự án của bạn sẽ không bị phá vỡ đối với những người dùng khác, không có vị trí gói đặc biệt.

Mở một dấu nhắc lệnh với tư cách quản trị viên và sử dụng

mklink /prefix link_path Target_file/folder_path

2

Đối với bất kỳ giải pháp quan trọng, các câu trả lời trên sẽ giảm. Rất đơn giản, một cấu trúc không gian làm việc TFS phức tạp với các đường dẫn tương đối khác nhau, phân nhánh, các dự án được chia sẻ, vv làm cho một kho lưu trữ trung tâm duy nhất không thể.

Sử dụng ($ SolutionDir) là một bước đi đúng hướng, nhưng việc mã hóa tệp csproj bằng ($ SolutionDir) sẽ trở nên khá tẻ nhạt trong một cơ sở mã với hàng trăm gói được cập nhật thường xuyên (mỗi lần cập nhật xảy ra, HintPath bị ghi đè một con đường tương đối mới). Điều gì xảy ra nếu bạn phải chạy Cập nhật-Gói -Reinstall.

Có một giải pháp tuyệt vời gọi là NugetReferenceHintPathRewrite . Nó tự động hóa việc tiêm ($ SolutionDir) vào HintPath ngay trước khi xây dựng (mà không thực sự thay đổi tệp csproj). Tôi tưởng tượng nó có thể dễ dàng được tích hợp vào các hệ thống xây dựng tự động


1

Một bản tóm tắt ngắn cho những người trên VS 2013 chuyên nghiệp với Phiên bản NuGet : 2.8.60318.667

Đây là cách bạn sẽ hướng các gói đến một đường dẫn liên quan đến thư mục .nuget:

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

Ví dụ: nếu giải pháp của bạn (tệp .sln) nằm trong C: \ Project \ MySolution, khi bạn bật khôi phục gói NuGet, thư mục .nuget sẽ được tạo như vậy: C: \ Project \ MySolution.nuget và các gói sẽ được tải xuống vào một thư mục như vậy: C: \ Project \ MySolution \ Dependencies

LƯU Ý: Vì một số lý do (không xác định), mỗi khi tôi cập nhật "repositoryPath", tôi phải đóng và mở lại giải pháp để các thay đổi có hiệu lực


Lưu ý rằng có một dấu gạch chéo bị thiếu trên thẻ cấu hình đóng.
Moo


0

đối với những người sử dụng paket làm trình quản lý gói của họ, có tùy chọn tự động liên kết đối với tệp phụ thuộc của bạn:

storage: symlink

btw: đòn bẩy paket nuget

tham khảo: https://fsprojects.github.io/Paket/dependencies-file.html

Nếu bạn muốn sửa đổi ít nhất có thể, bạn có thể dọn sạch các thư mục con theo định kỳ bằng một tập lệnh. I E. Hành vi mặc định của Nuget là sao chép các tệp từ một vị trí toàn cầu vào thư mục gói cục bộ, do đó hãy xóa các tệp này sau đó.


0

Tôi chỉ sử dụng các mối nối NTFS để làm cho tất cả các thư mục gói trực tiếp đến một thư mục duy nhất phía trên các kho lưu trữ gốc. Công trình tuyệt vời. Không có vấn đề với khôi phục gói song song trên nhiều giải pháp. Một lợi thế cho điều này là bạn không phải cấu hình lại bất cứ thứ gì trong mã nguồn của mình, chẳng hạn như hàng trăm đường dẫn gợi ý tương đối trong các tệp .csproj của bạn. Nó 'chỉ hoạt động' bằng cách cho phép hệ thống tệp xử lý chuyển hướng và mô phỏng của một thư mục gói duy nhất.

Chỉ cần coi chừng các vấn đề 'git'. Mặc dù 'trạng thái git' thông qua dòng lệnh cho thấy không có thay đổi chưa được thực hiện, tôi nhận thấy rằng GitKraken thấy đường nối 'gói' là một tệp không được xử lý . Nó thậm chí còn hiển thị các lỗi như 'tập tin là một thư mục' khi bạn nhấp vào nó. GitKraken cũng sẽ cố gắng bỏ 'tập tin' này nếu bạn khởi động lại, phá hủy đường nối và khôi phục nó dưới dạng một tệp thực sự có chứa văn bản với đường dẫn tệp gốc. Hành vi rất lạ. Có thể có thể làm việc xung quanh nó bằng cách đảm bảo tệp gói được thêm vào .gitignore của bạn.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.