Hệ thống quản lý phụ thuộc .NET


8

Tôi có một số dự án .NET đang bắt đầu đủ lớn để tham gia vào các giải pháp Quản lý phụ thuộc, vì vậy chúng tôi không phải sao chép nhị phân từ dự án này sang dự án khác. Đây là những gì tôi đã tìm thấy cho đến nay:

  • NPanday dựa trên một cảng của Maven. Tôi không thể biết gần đây nó đã hoạt động như thế nào, nhưng bản phát hành cuối cùng là vào tháng 5 năm 2011.
  • NuGet dường như đang được phát triển tích cực và dường như có sự hỗ trợ trực tiếp từ Microsoft. Một số người phàn nàn rằng nó "chỉ giải quyết vấn đề phụ thuộc", nhưng tôi không biết nó nên giải quyết vấn đề gì khác, hoặc liệu nó có thêm nhiều tính năng kể từ thời điểm đó hay không. Dường như gần đây đã thêm khả năng nhập nhị phân như một phần của quy trình xây dựng, vì vậy chúng tôi không phải cam kết chúng vào kho lưu trữ của chúng tôi.
  • Refix dường như vẫn ở bản Beta, sau khi không nhận được sự chú ý nào kể từ tháng 9 năm 2011.

Ai đó có kinh nghiệm gần đây sử dụng bất kỳ công cụ quản lý phụ thuộc nào (hoặc bất kỳ công cụ nào hoạt động tốt) sẽ chia sẻ kinh nghiệm của bạn? NuGet đã đủ trưởng thành để sử dụng nó cho quản lý phụ thuộc chưa? Nếu không, nó thiếu gì?


1
Bạn đã bỏ lỡ openwrap .
Oded

Tôi đang phát triển một bản, nó vẫn ở dạng alpha nhưng được sử dụng thành công trong công ty của chúng tôi (hơn 50 nhà phát triển). Không có tài liệu nào, nhưng nó là nguồn mở. NuGet đã không làm việc cho, cũng như Assix và NPanday (một bổ trợ Maven xấu xí).
Ivan G.

@aloneguid: Bạn có thể chia sẻ lý do mà NuGet không làm việc cho bạn không?
StriplingWar Warrior

NuGet? Nó trông có vẻ bẩn, đôi khi chạy các tập lệnh PS từ các gói, có sự phụ thuộc PS hoàn toàn (bạn có thể tranh luận, nhưng nó có). Quá nặng trong một VS. Không (hoặc không) phát hiện xung đột phiên bản.
Ivan G.

@aloneguid: Giả sử rằng tôi không biết gì về chủ đề này. Bạn có ý nghĩa gì bởi PS / VS?
StriplingWar Warrior

Câu trả lời:


5

NuGet có thể sẽ là câu trả lời của tôi. Sau khi làm việc với tiền thân (Nu) chỉ ngồi trên RubyGems, tôi có thể nói rằng có tài nguyên đối với một cái gì đó giúp ích. Bây giờ, một khi công việc tôi đã kết thúc với một phiên bản vá của tệp thực thi vì chúng tôi có một kho lưu trữ cục bộ bên cạnh các kho lưu trữ từ xa. Tôi không chắc liệu họ đã khắc phục vấn đề đó hay chưa, nhưng vì họ đang chấp nhận các bản vá, nên rất dễ sửa. Trên tất cả các dự án nguồn mở trong lĩnh vực .NET, tôi làm việc bây giờ chúng tôi thực hiện tất cả thông qua NuGet. Nó dễ dàng hơn nhiều, mặc dù việc xuất bản chuỗi sẽ mất nhiều thời gian hơn.

OpenWrap là một tùy chọn, nhưng mọi thứ cần được xây dựng. Đó là một nỗi đau ở mông. Nếu bạn không thể xây dựng dự án đúng thì phải mất một thời gian để giải quyết. Openwrap đã cố gắng giải quyết điều này trong một thời gian dài và nó vẫn thực sự khó xử. Phân phối chỉ nhị phân dễ dàng hơn nhiều (đôi khi) ...

Hai cái còn lại tôi không quen. Vì vậy, tôi không thể nhận xét về họ một tấn.


NuGet giống như sự chuyển đổi của người mới bắt đầu sang quản lý gói. Nó có thể chỉ giúp tải xuống các gói dễ dàng hơn, nhưng tôi không chắc nó làm được nhiều hơn thế. So sánh nó với Maven để hiểu hệ thống quản lý phụ thuộc nên làm gì.
Ivan G.

1
@aloneguid: Vì tôi là người mới bắt đầu quản lý gói, NuGet có phải là bước đầu tiên hợp lý để tôi thực hiện cho đến khi tôi xác định rằng tôi có nhu cầu bổ sung không được đáp ứng?
StriplingWar Warrior

@aloneguid Vui lòng kiểm tra tính năng Khôi phục gói NuGet đã được giới thiệu trong NuGet 2.7. Có vẻ như nó có thể mang NuGet đến gần hơn một chút với khả năng quản lý phụ thuộc của Maven.
Martin Klinke

2

Tôi vừa tải xuống một phiên bản mới nhất của NuGet để xem những gì đã thay đổi kể từ lần trước. Vui lòng sửa lại cho tôi nếu tôi sai (Tôi thực sự đang cân nhắc việc chuyển công cụ của mình sang nuget):

Các gói NuGet vẫn không chỉ định "nền tảng" là phụ thuộc gói. Tôi vừa cài đặt "Ninject" và nó đã tham chiếu phiên bản .NET 4.0 trong "gói" thư mục con. Tôi cho rằng đó là một dự đoán tốt nhất vì dự án của tôi là trong 4.0, nhưng điều đó khá nguy hiểm để giả sử. Tôi cũng không hiểu nền tảng nào sẽ được lựa chọn bởi sự phụ thuộc của các gói.

Tính năng "Khôi phục gói" biến đổi giải pháp của tôi thêm bước xây dựng trước tùy chỉnh. Tôi không thích cái gì đó sửa đổi các tập tin giải pháp của mình, nhưng đó không phải là vấn đề. Tôi không hiểu tần suất kiểm tra các phiên bản mới (tôi muốn đặt tần suất cho các kho riêng tư khá thường xuyên).

Tôi có thể hoàn toàn sai ở đây, tuy nhiên có vẻ như nuget không tự động nâng cấp sự phụ thuộc của dự án khi một phiên bản gói được nâng cấp. Gói khôi phục sẽ tạo một thư mục con mới cho phiên bản gói mới, tuy nhiên tôi phải chọn thủ công thư mục đó từ Visual Studio xóa tham chiếu trước.

Một số gói (như jQuery) sẽ chạy tập lệnh PowerShell được nhúng khi khởi động. Tôi thực sự không thích bất kỳ sự thực thi tùy chỉnh và phụ thuộc PS nào không phải lúc nào cũng có trên các cửa sổ và hoàn toàn bị thiếu trong các bản dựng Mono non-windows. Nhân tiện, như tôi đã đề cập MSBuild trước đây, thậm chí sự phụ thuộc này có thể không thực tế để đáp ứng cho một số bản dựng C ++ (nếu không tôi sẽ bỏ lỡ tính năng Gói khôi phục?).

Cái cuối cùng có thể không quan trọng lắm, tuy nhiên phải mất một khoảng thời gian hợp lý để Khôi phục Phụ thuộc khi tôi có khá nhiều trong số chúng.


0

NuGet vẫn là lựa chọn tốt nhất tại thời điểm này.

Vấn đề chính với NuGet với tư cách là người quản lý phụ thuộc là nó được hình dung là người quản lý phụ thuộc "thời gian phát triển", chứ không phải là người quản lý phụ thuộc "thời gian xây dựng".

Một nhà phát triển sẽ khôi phục gói NuGet thông qua Visual Studio ... và điều này có thể chạy tập lệnh PowerShell trong quá trình khôi phục sửa đổi các tệp trong dự án.

Điều này không giống như các hệ thống quản lý phụ thuộc khác mà tôi đã thấy, vì việc thêm một phụ thuộc và giải quyết nó có thể thay đổi hệ thống tham chiếu đến sự phụ thuộc.

Không có cơ chế tích hợp để đảm bảo hoặc kiểm tra tính không ổn định trong tập lệnh PowerShell, do đó, việc chạy nó nhiều lần trên cùng một tập tin có thể không xác định được.

Có vẻ như nhiều người sử dụng NuGet để kéo các gói thông qua Visual Studio trong thời gian phát triển, nhưng tôi không biết về một khuyến nghị chắc chắn về cách thức hoạt động trên máy chủ xây dựng.

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.