48
dự án của chúng tôi trong TFS được tổ chức như thế này:NuGet và TFS thực hành tốt nhất
$\DefaultCollection\ProjectName\Source <-- source code goes here
$\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here
Bây giờ NuGet là trên sân khấu, là có bất kỳ lý do gì để thay đổi cách tiếp cận của chúng tôi và sử dụng thư mục gói NuGet cho dlls đến từ Dự án NuGet nhận thức? Tôi đang tựa người này vì
1) nó tạo ra hai nơi người ta phải tìm kiếm phụ thuộc 2) nó lại cho chúng ta mở cửa cho một nhà phát triển cập nhật một gói và phá vỡ một số phụ thuộc
Điều đó nói rằng, nếu có ai có thể báo cáo một lý do chính đáng để bắt đầu sử dụng NuGet trong môi trường TFS, tôi sẽ vui vẻ trình bày ý tưởng của bạn cho nhóm của tôi như thể họ là của riêng tôi (đùa).
Bạn không cần phải lưu trữ các gói từ NuGet trong điều khiển phiên bản, thay vì sử dụng 'NuGet.exe' để cư một bản sao cục bộ từ' file packages.config' của dự án: http: // blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html – Richard
Tính năng này hoạt động như thế nào cho các giải pháp có nhiều dự án? Phần chính của chúng tôi có hai ứng dụng web, hai ứng dụng giao diện điều khiển và một dịch vụ. Ưu điểm của cách tiếp cận dll store là tất cả chúng đều hoạt động hoặc thất bại cùng nhau. –
Xem liên kết: chạy 'nuget-exe' cho mỗi' packages.config' với cùng một thư mục kho lưu trữ, chỉ các gói bị thiếu sẽ được tải xuống (đây cũng có thể là bước dựng sẵn của mỗi dự án). – Richard