2009-11-09 32 views
8

Chúng tôi có dự án .NET bao gồm nhiều tiểu dự án (khoảng 20). Có một số giải pháp, mỗi giải pháp chỉ chứa các tiểu dự án có liên quan đến giải pháp cụ thể.Quản lý phụ thuộc lắp ráp .NET theo tham chiếu dll thay vì tham chiếu dự án trong VS

Để cho phép các giải pháp tùy ý, các tiểu dự án của chúng tôi không bao giờ tham khảo lẫn nhau bằng các tham chiếu dự án, mà là do tham chiếu dll trực tiếp. Có rất ít tinh chỉnh của tệp csproj, để làm cho HintPath bao gồm $ (Cấu hình), do đó, Debug xây dựng các tham chiếu Debug dlls và Release builds reference dlls Release.

Tất cả các công trình lớn, nhưng có hai vấn đề lớn - một là gây phiền nhiễu và khác là thực sự cấp tính:

  1. VS không nhận ra tài liệu tham khảo dll cho mục đích của việc tính toán phụ thuộc. Chúng ta phải chỉ định thủ công các phụ thuộc bằng cách sử dụng hộp thoại "Phụ thuộc dự án" mỗi lần một dự án hoặc tham chiếu mới được thêm vào. Điều này thật khó chịu.
  2. Chúng tôi không sử dụng Resharper hoặc Visual Assist (các công cụ tuyệt vời, nhưng chúng tôi không sử dụng chúng, nó là một nhất định). Chúng tôi thích sử dụng lệnh "Duyệt qua Định nghĩa" chuẩn (có sẵn từ menu ngữ cảnh trên mã nguồn). Vấn đề cấp tính là nó chỉ thực hiện dự án chéo nếu một dự án tham chiếu đến tham chiếu dự án và nó không hoạt động khi tham chiếu là tham chiếu dll trực tiếp, ngay cả khi dự án được tham chiếu được bao gồm trong giải pháp! Đó là một bummer thực sự, bởi vì thay vì điều hướng đến nguồn nó điều hướng đến siêu dữ liệu.

Tôi đang tìm kiếm lời khuyên của những người ở đó, những người sử dụng các tham chiếu dll như chúng tôi và bằng cách nào đó đã khắc phục được hai vấn đề này. Cảm ơn.

EDIT:

Lưu ý, rằng bên cạnh những vấn đề "Duyệt đến Definition", có tài liệu tham khảo DLL thay vì tài liệu tham khảo dự án phát sinh chỉ có một chi phí thời gian trên người quản lý dự án - đó là để cập nhật các phụ thuộc dự án của mỗi giải pháp bị ảnh hưởng khi một dự án mới được thêm vào hoặc một sự phụ thuộc mới phải được giới thiệu. Các phụ thuộc của dự án này được lưu giữ trong tệp .sln và không yêu cầu bất kỳ sự bảo trì nào cho đến khi một dự án mới đến hoặc một sự phụ thuộc mới được tạo ra, điều này xảy ra không quá thường xuyên.

Chúng tôi đang sử dụng msbuild để xây dựng các dự án của chúng tôi trên máy chủ CI, sử dụng cùng một tệp .sln như VS. Có một tệp .sln chính, bao gồm tất cả các tiểu dự án.

Tôi muốn nhấn mạnh vấn đề cấp tính hơn - không có khả năng duyệt đến defintion trong dự án khác, mặc dù cả hai dự án đều nằm trong cùng một giải pháp chỉ vì tham chiếu là tham chiếu dll. Điều này là gây phiền nhiễu và nó là một mối phiền toái, không có lý do tại sao VS khẳng định về tài liệu tham khảo dự án để kích hoạt tính năng này. Các công cụ khác, như Resharper hoặc Visual Assist không có giới hạn này. Than ôi, chúng tôi không có những công cụ này và không có trong tương lai có thể quan sát được.

+0

Để đảm bảo tôi hiểu, bạn có giải pháp có một hoặc nhiều dự án trong đó. Một số dự án này tham khảo đầu ra dll của các dự án khác trong giải pháp, mặc dù dự án được tham chiếu nằm trong giải pháp? –

+0

Thật vậy. Nhưng cũng có những giải pháp khác, không bao gồm một số dự án được tham chiếu. Để có sự linh hoạt này với các giải pháp soạn thảo như một vui lòng chúng tôi chỉ tham khảo dlls. Nhưng sau đó chúng tôi rời khỏi dự án chéo "Duyệt để điều hướng" khả năng ngay cả khi các dự án liên quan đều được tìm thấy trong giải pháp. – mark

+0

Vâng, tôi cũng ghét điều đó. Một giải pháp sẽ thực sự tuyệt vời. –

Trả lời

2

Có lý do nào khiến bạn muốn cho phép các giải pháp tùy ý không? Có vẻ như sẽ dễ dàng hơn để tạo ra một giải pháp đơn lẻ và đặt tất cả các dự án vào giải pháp đó. Tôi cố gắng tránh nhiều giải pháp bất cứ khi nào có thể.

+0

Càng nhiều dự án thì thời gian tải càng cao, cộng với nó sẽ kiểm tra tất cả các dự án khi xây dựng và nếu phần lớn không thay đổi thì nó là quá nhiều chi phí. Một nhà phát triển giao diện người dùng có thể không bao giờ chạm vào một nửa dự án, vậy tại sao phải trả chi phí mỗi lần xây dựng, cộng với chi phí một lần để tải giải pháp? – mark

-1

Nghe có vẻ như tôi gặp phải vấn đề bạn đang gặp phải là kết quả trực tiếp của việc sử dụng bộ công cụ không chính xác. Visual Studio không có cách nào khác để tự động tính toán phụ thuộc dự án khi bạn không cho phép nó quản lý chúng.

Có vẻ như bạn có hai lựa chọn.

  1. Sử dụng Visual Studio để quản lý phụ thuộc dự án
  2. Sử dụng khác xây dựng hệ thống (như Nant)

Có vẻ như bạn đã loại trừ khả năng lựa chọn # 1, vì vậy tôi sẽ không giải quyết bất kỳ hơn . Vì vậy, chỉ để lại tùy chọn # 2.

Bạn có thể sử dụng NAnt để tạo các dự án CSproj riêng lẻ và sử dụng tập lệnh xây dựng NAnt để xác định sự phụ thuộc giữa các dự án. Có hai nhược điểm này.

  1. Bạn phải quản lý tất cả mua tay (mà có vẻ như bạn đang chuẩn bị để làm)
  2. Visual Studio sẽ được bình đẳng như bị phá vỡ với bạn như bây giờ.

Trên nhược điểm # 2, Visual Studio sẽ không thể biên dịch giải pháp của bạn nói chung vì logic đó sẽ bị chuyển khỏi VS và thành tập lệnh xây dựng bên ngoài. Điều này có thể dẫn đến sự nhầm lẫn giữa các nhà phát triển và sẽ cản trở quá trình gỡ lỗi. Không nói những điều đó không thể vượt qua được ... chỉ cần nói rằng nó sẽ được thiết lập thêm liên quan đến những bước của quá trình phát triển.

+0

Tôi không hiểu những gì Nant mang lại cho tôi trái ngược với msbuild. Các dự án của chúng tôi được xây dựng với msbuild tại máy chủ CI và nó hoạt động rất tốt. Vấn đề duy nhất, đó là các tệp .sln (được sử dụng bởi msbuild cũng như VS) phải bao gồm các phụ thuộc dự án một cách rõ ràng, bởi vì chúng tôi tham chiếu các Dll hơn là các dự án. Đó là tất cả. Tôi không hiểu tại sao tôi nên chuyển sang NAnt. – mark

+0

Cảm ơn câu trả lời.Tôi đã chỉnh sửa câu hỏi của mình. – mark

7

Sự cố với cấu hình xây dựng của bạn như sau: giả sử bạn có 3 dự án và 2 giải pháp.

Solution1 
- Project1 
- Project2 
Solution2 
- Project1 
- Project3 

Đột nhiên, xây dựng Solution2 xây dựng phần của mã cho Solution1, để lại nó trong trạng thái không hợp lệ (những chương trình mới nhất là một trong hai không tương thích hay không cần phải được xây dựng).

Mọi dự án nên được đưa vào một giải pháp duy nhất. Các giải pháp khác có thể dựa vào, nhưng không nên chủ động thay đổi mã của các dự án đó. Bằng cách này, họ có thể tham khảo một DLL được xây dựng bởi vì không có lý do để xây dựng lại các phụ thuộc bên ngoài.

Để tóm tắt, bạn nên dành chút thời gian và cơ cấu lại các giải pháp để đáp ứng các điều kiện sau:

  • Mỗi dự án được bao gồm trong đúng một giải pháp.
  • Nếu dự án phụ thuộc vào dự án khác trong cùng một giải pháp, hãy biến nó thành tham chiếu dự án.
  • Nếu dự án phụ thuộc vào dự án khác trong một giải pháp khác nhau, hãy biến nó trở thành tham chiếu DLL.

Ngoài những điều trên, tôi khuyên bạn nên tạo thư mục "Externals" để đặt bản dựng trong khi chúng được tham chiếu bởi các giải pháp khác. Giả sử bạn tái cơ cấu như sau:

Solution1 
- Project1 
- Project2 -> reference project Project1 
Solution2 
- Project3 -> reference Project1.dll 

Trong trường hợp này, bạn nên đặt các bản sao của Project1.dll và Project1.pdb trong Externals\Project1\DebugExternals\Project1\Release, và tham khảo External\Project1\$(Configuration)\Project1.dll trong Project3. Chỉ cập nhật các bản dựng trong thư mục Externals khi bạn đã sẵn sàng để đẩy bản dựng vào tất cả các giải pháp khác của mình.

+0

Cảm ơn bạn đã trả lời. Tôi đã chỉnh sửa câu hỏi của mình. – mark

+0

Ok, hãy tư vấn. Thêm vào trên: Làm thế nào để quản lý kiểm soát phiên bản cho Project.dll đã xuất bản? Tôi hy vọng Project3 chọn Project1.dll từ điều khiển phiên bản. –

Các vấn đề liên quan