NuGet và nhiều giải pháp

Question

Chúng tôi có hai giải pháp: foo.sln và bar.sln

Tôi có một thư viện chung được cả foo và bar sử dụng. Common.csproj được sử dụng bởi cả hai.

Nếu tôi mở foo và cập nhật tài liệu tham khảo nuget, tất cả các tham chiếu trong Common.csproj trỏ tới foo/packages /. Nếu sau này tôi mở thanh và cập nhật các tham chiếu nuget, tất cả các tham chiếu sẽ được đặt thành các thanh trong/gói /. Đương nhiên, điều này khiến nhóm foo nổi giận vì nó có thể gây ra sự không tương thích giữa Common.csproj và các công cụ đặc biệt Foo như Foo.Data.csproj, vẫn trỏ đến foo/packages.

Phải có một số giải pháp rõ ràng khác hơn là: "tạo một giải pháp lớn chứa tất cả các dự án của bạn và nếu bạn cần chạm vào nuget, chỉ thực hiện từ giải pháp đó".

Dường như có một số issue on codeplex, (vấn đề bỏ phiếu hàng đầu, tình cờ), nhưng rõ ràng tôi quá dày để hiểu cách giải quyết vấn đề này. Ai đó có thể giải thích làm thế nào để sửa lỗi này?

Answer 1

Tại sao không có common.csproj như một hội đồng riêng biệt mà bạn tham khảo và có sự phụ thuộc của riêng mình chứ không phải là những giải pháp trong của nó.

Bằng cách đó bạn bảo vệ thông thường từ một trong hai foo hoặc thanh cập nhật gói tham chiếu và phá vỡ nó.

Answer 2

Sự cố này đề cập trước NuGet. Nếu bạn có một dự án được tham chiếu trong hai giải pháp và thay đổi tham chiếu assembly trong dự án khi nó được mở trong một giải pháp, tất nhiên nó sẽ thay đổi đường dẫn tham chiếu cho dự án đó khi nó được mở trong giải pháp khác. Điều này luôn luôn xảy ra, bất kể tham chiếu đã được thay đổi như thế nào (với NuGet hoặc cách khác).

Nhưng vấn đề thực sự là khi bạn cập nhật, các gói cập nhật không xuất hiện trong thư mục foo/packages phải không?

Giải pháp đơn giản là di chuyển Common.csproj thành giải pháp của riêng nó, với các tham chiếu, thư mục gói, quá trình xây dựng và phát hành của riêng nó. Sau đó tạo một gói NuGet của riêng bạn với bất kỳ phụ thuộc có liên quan nào được tích hợp vào nó. Sau đó, bạn có thể cài đặt gói Chung của mình vào cả Foo và Bar và sau đó nhóm Foo được tự do cập nhật lên phiên bản mới nhất của Common as và khi họ đã sẵn sàng.

Lý lẽ chính mà tôi đã nghe nói chống lại này là bạn có thể muốn bước qua các mã thông thường trong khi gỡ lỗi, nhưng điều này không còn là một vấn đề với Visual Studio 2010.

Câu hỏi cơ bản mà bạn cần phải hỏi là ai sở hữu Common.csproj? Có phải đội Foo hay đội Bar không?

Answer 3

Trong trường hợp của chúng tôi, nhiều nhà phát triển và giải pháp với tfs và nhiều phiên bản của nó trong các ngành khác nhau ... và mỗi nhà phát triển hiểu biết nguồn gốc của họ phải nằm ở đâu.

Đường dẫn tương đối trong trường hợp này không hoạt động, đường dẫn tuyệt đối trong trường hợp đĩa trùng hợp ngẫu nhiên được thay thế bằng tương đối và cũng không hoạt động.

Giải pháp của chúng tôi bao gồm việc loại bỏ đường dẫn tương đối. Bạn có thể làm điều đó nếu bạn đặt NuGetPackages trên một đĩa riêng biệt. như vậy:

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

Bất kỳ tên thư mục bạn wont
Sau đó, bạn có thể xác định con đường thực sự tuyệt đối trong NuGet.Config

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

Sau khi tất cả xóa file Suo

ps: Sẽ có một chút rắc rối với sự thay đổi của các giải pháp hiện có, nếu chúng sống trong sourcecontrol cách dễ nhất là sửa đường dẫn đến p: \ NuGetPackages trong mỗi .csproj Nếu không, cần phải cài đặt lại tất cả các gói và tự hoàn tác tất cả các gói.config được đánh dấu là đã xóa trong mã kiểm tra

Answer 4

Tôi khắc phục sự cố bằng cách thay đổi đường dẫn gợi ý trong tệp dự án để chứa biến $ (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>