Các phương pháp hay nhất cho các giải pháp lớn trong Visual Studio (2008) [đã đóng]

Chúng tôi có một giải pháp với hơn 100 dự án, hầu hết trong số đó là C #. Đương nhiên, phải mất một thời gian dài để mở và xây dựng, vì vậy tôi đang tìm kiếm các phương pháp tốt nhất cho những con thú như vậy. Cùng với những câu hỏi mà tôi hy vọng nhận được câu trả lời, là:

• làm thế nào để bạn xử lý tốt nhất các tham chiếu giữa các dự án
  • nên bật hay tắt "copy local"?

• mọi dự án nên xây dựng vào thư mục riêng của nó hay tất cả chúng nên xây dựng vào cùng một thư mục đầu ra (chúng đều là một phần của cùng một ứng dụng)

• Các thư mục của các giải pháp có phải là một cách tốt để sắp xếp mọi thứ không?

Tôi biết rằng chia giải pháp thành nhiều giải pháp nhỏ hơn là một tùy chọn, nhưng điều đó đi kèm với tập hợp các vấn đề đau đầu về cấu trúc lại và xây dựng của riêng nó, vì vậy có lẽ chúng ta có thể lưu nó cho một chủ đề riêng :-)

Bạn có thể quan tâm đến hai bài báo MSBuild này mà tôi đã viết.

MSBuild: Các phương pháp hay nhất để tạo công trình đáng tin cậy, Phần 1

MSBuild: Các phương pháp hay nhất để tạo công trình đáng tin cậy, Phần 2

Cụ thể trong Phần 2 có phần Xây dựng cây nguồn lớn mà bạn có thể muốn xem qua.

Để trả lời ngắn gọn câu hỏi của bạn ở đây:

• CopyLocal? Chắc chắn hãy tắt cái này đi
• Xây dựng một hoặc nhiều thư mục đầu ra? Xây dựng thành một thư mục đầu ra
• Thư mục giải pháp? Đây là một vấn đề của hương vị.

Sayed Ibrahim Hashimi

Cuốn sách của tôi: Bên trong Microsoft Build Engine: Sử dụng MSBuild và Team Foundation Build

+1 để sử dụng tiết kiệm các thư mục giải pháp để giúp sắp xếp nội dung.

+1 để xây dựng dự án vào thư mục riêng của nó. Ban đầu, chúng tôi đã thử một thư mục đầu ra chung và điều này có thể dẫn đến việc tìm kiếm các tài liệu tham khảo lỗi thời rất khó khăn và phức tạp.

FWIW, chúng tôi sử dụng các tham chiếu dự án cho các giải pháp và mặc dù ngày nay nuget có lẽ là lựa chọn tốt hơn, nhưng đã thấy rằng svn: externals hoạt động tốt cho cả bên thứ 3 và (loại khung) trong nhà. Chỉ cần có thói quen sử dụng một số sửa đổi cụ thể thay vì HEAD khi tham chiếu svn: externals (có tội như bị tính phí :)

Dỡ các dự án bạn không sử dụng thường xuyên và mua một ổ SSD. SSD không cải thiện thời gian biên dịch, nhưng Visual Studio trở nên nhanh hơn gấp đôi để mở / đóng / tạo.

Chúng tôi gặp vấn đề tương tự vì chúng tôi có 109 dự án riêng biệt để giải quyết. Để trả lời các câu hỏi ban đầu dựa trên kinh nghiệm của chúng tôi:

1. Làm thế nào để bạn xử lý tốt nhất các tham chiếu giữa các dự án

Chúng tôi sử dụng tùy chọn menu ngữ cảnh 'thêm tài liệu tham khảo'. Nếu 'dự án' được chọn, thì phần phụ thuộc được thêm vào tệp giải pháp toàn cầu, duy nhất của chúng tôi theo mặc định.

2. Nên bật hay tắt "copy local"?

Theo kinh nghiệm của chúng tôi. Việc sao chép thêm chỉ làm tăng thêm thời gian xây dựng.

3. Mọi dự án nên xây dựng vào thư mục riêng của nó hay tất cả chúng nên xây dựng vào cùng một thư mục đầu ra (tất cả chúng đều là một phần của cùng một ứng dụng)

Tất cả đầu ra của chúng tôi được đặt trong một thư mục duy nhất được gọi là 'bin'. Ý tưởng là thư mục này giống như khi phần mềm được triển khai. Điều này giúp ngăn chặn các sự cố xảy ra khi thiết lập nhà phát triển khác với thiết lập triển khai.

4. Các thư mục giải pháp có phải là một cách tốt để sắp xếp công cụ không?

Theo kinh nghiệm của chúng tôi thì không. Cấu trúc thư mục của một người là cơn ác mộng của người khác. Các thư mục lồng nhau sâu chỉ làm tăng thời gian tìm kiếm bất cứ thứ gì. Chúng tôi có một cấu trúc hoàn toàn phẳng nhưng đặt tên cho các tệp dự án, tập hợp và không gian tên của chúng tôi giống nhau.

Cách cấu trúc các dự án của chúng tôi dựa trên một tệp giải pháp duy nhất. Việc xây dựng điều này mất nhiều thời gian, ngay cả khi bản thân các dự án không thay đổi. Để trợ giúp việc này, chúng tôi thường tạo một tệp giải pháp 'nhóm làm việc hiện tại' khác. Bất kỳ dự án nào chúng tôi đang thực hiện đều được thêm vào. Thời gian xây dựng được cải thiện đáng kể, mặc dù một vấn đề mà chúng tôi đã thấy là Intellisense không thành công đối với các loại được xác định trong các dự án không có trong bộ hiện tại.

Một phần ví dụ về bố cục giải pháp của chúng tôi:

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]

Chúng tôi làm việc trong một dự án lớn tương tự ở đây. Thư mục giải pháp đã được chứng minh là một cách tốt để tổ chức mọi thứ và chúng tôi có xu hướng chỉ để nguyên set local copy thành true. Mỗi dự án xây dựng thành thư mục riêng của nó và sau đó chúng tôi biết đối với mỗi dự án có thể triển khai trong đó chúng tôi có tập hợp con chính xác của các tệp nhị phân.

Đối với thời gian mở và xây dựng thời gian, điều đó sẽ khó sửa chữa nếu không chia thành các giải pháp nhỏ hơn. Bạn có thể điều tra việc xây dựng song song (google "Bản dựng MS song song" để biết cách thực hiện việc này và tích hợp vào giao diện người dùng) để cải thiện tốc độ tại đây. Ngoài ra, hãy xem thiết kế và xem liệu việc cấu trúc lại một số dự án của bạn để dẫn đến tổng thể ít hơn có thể giúp ích không.

Để giảm bớt nỗi đau về việc xây dựng, bạn có thể sử dụng tùy chọn "Trình quản lý cấu hình ..." cho các bản dựng để bật hoặc tắt việc xây dựng các dự án cụ thể. Bạn có thể có một "Dự án [n] Bản dựng" có thể loại trừ các dự án nhất định và sử dụng nó khi bạn đang nhắm mục tiêu các dự án cụ thể.

Đối với hơn 100 dự án, tôi biết bạn không muốn bị đặt nặng trong câu hỏi này về lợi ích của việc cắt giảm kích thước giải pháp của bạn, nhưng tôi nghĩ bạn không có lựa chọn nào khác khi nói đến việc tăng tốc thời gian tải (và sử dụng bộ nhớ) của devenv.

Những gì tôi thường làm với điều này phụ thuộc một chút vào cách quá trình "gỡ lỗi" thực sự xảy ra. Thông thường, mặc dù tôi KHÔNG đặt bản sao cục bộ thành true. Tôi thiết lập thư mục xây dựng cho mỗi dự án để xuất mọi thứ đến điểm cuối mong muốn.

Do đó, sau mỗi lần xây dựng, tôi có một thư mục phổ biến với tất cả dll và bất kỳ ứng dụng cửa sổ / web nào và tất cả các mục đều ở vị trí thích hợp. Sao chép cục bộ là không cần thiết vì cuối cùng thì dll đã ở đúng nơi.

Ghi chú

Các giải pháp trên phù hợp với các giải pháp của tôi, thường là các ứng dụng web và tôi chưa gặp bất kỳ sự cố nào với tài liệu tham khảo, nhưng có thể có!

Chúng tôi có một vấn đề tương tự. Chúng tôi giải quyết nó bằng cách sử dụng các giải pháp nhỏ hơn. Chúng tôi có một giải pháp tổng thể mở ra mọi thứ. Nhưng hoàn hảo. về điều đó là xấu. Vì vậy, chúng tôi phân chia các giải pháp nhỏ hơn theo loại nhà phát triển. Vì vậy, các nhà phát triển DB có một giải pháp tải các dự án mà họ quan tâm, các nhà phát triển dịch vụ và các nhà phát triển giao diện người dùng giống nhau. Thật hiếm khi ai đó phải mở ra toàn bộ giải pháp để hoàn thành những gì họ cần làm hàng ngày. Nó không phải là thuốc chữa bách bệnh - nó có những mặt trái của nó. Xem "mô hình đa giải pháp" trong bài viết này (bỏ qua phần về cách sử dụng VSS :)

Tôi nghĩ rằng với các giải pháp lớn này, cách tốt nhất là nên chia nhỏ chúng. Bạn có thể coi "giải pháp" là nơi tập hợp các dự án cần thiết và có thể là các phần khác để tìm ra giải pháp cho một vấn đề. Bằng cách chia nhỏ hơn 100 dự án thành nhiều giải pháp chuyên để phát triển các giải pháp chỉ cho một phần của vấn đề tổng thể, bạn có thể giải quyết ít hơn tại một thời điểm nhất định ở đó bằng cách tăng tốc độ tương tác của bạn với các dự án cần thiết và đơn giản hóa miền vấn đề.

Mỗi giải pháp sẽ tạo ra đầu ra mà nó chịu trách nhiệm. Đầu ra này phải có thông tin phiên bản có thể được đặt trong một quy trình tự động. Khi đầu ra ổn định, bạn có thể cập nhật các tài liệu tham khảo trong các dự án và giải pháp phụ thuộc với bản phân phối nội bộ mới nhất. Nếu bạn vẫn muốn bước vào mã và truy cập nguồn, bạn thực sự có thể thực hiện việc này với máy chủ ký hiệu Microsoft mà Visual Studio có thể sử dụng để cho phép bạn bước vào các hội đồng tham chiếu và thậm chí tìm nạp mã nguồn.

Việc phát triển đồng thời có thể được thực hiện bằng cách chỉ định trước các giao diện và chế nhạo các tập hợp đang được phát triển trong khi bạn đang chờ các phần phụ thuộc chưa hoàn thành nhưng bạn muốn phát triển ngược lại.

Tôi thấy đây là cách thực hành tốt nhất vì không có giới hạn nào về mức độ phức tạp của nỗ lực tổng thể khi bạn phá vỡ nó về mặt thể chất theo cách này. Đưa tất cả các dự án vào một giải pháp duy nhất cuối cùng sẽ đạt đến giới hạn trên.

Hy vọng thông tin này sẽ giúp.

Chúng tôi có khoảng hơn 60 dự án và chúng tôi không sử dụng tệp giải pháp. Chúng tôi có sự kết hợp của các dự án C # và VB.Net. Hiệu suất luôn là một vấn đề. Chúng tôi không làm việc trên tất cả các dự án cùng một lúc. Mỗi nhà phát triển tạo các tệp giải pháp của riêng họ dựa trên các dự án mà họ đang thực hiện. Các tệp giải pháp không được kiểm tra trong kiểm soát nguồn của chúng tôi.

Tất cả các dự án thư viện Lớp sẽ xây dựng thành một thư mục CommonBin ở thư mục gốc của thư mục nguồn. Dự án Web / Dự án thực thi được xây dựng vào thư mục riêng lẻ của chúng.

Chúng tôi không sử dụng tham chiếu dự án, thay vào đó là tham chiếu dựa trên tệp từ thư mục CommonBin. Tôi đã viết một Nhiệm vụ MSBuild tùy chỉnh sẽ kiểm tra các dự án và xác định thứ tự xây dựng.

Chúng tôi đã sử dụng điều này trong vài năm nay và không có khiếu nại.

Tất cả đều liên quan đến định nghĩa và cách nhìn của bạn về giải pháp và dự án là gì. Trong tâm trí tôi, một giải pháp chỉ là vậy, một nhóm hợp lý các dự án giải quyết một yêu cầu rất cụ thể. Chúng tôi phát triển một ứng dụng Intranet lớn. Mỗi ứng dụng trong Intranet đó có giải pháp riêng, cũng có thể chứa các dự án cho các dịch vụ exes hoặc windows. Và sau đó, chúng tôi có một khuôn khổ tập trung với những thứ như lớp cơ sở và trình trợ giúp và httphandlers / httpmodules. Khung cơ sở khá lớn và được sử dụng bởi tất cả các ứng dụng. Bằng cách chia nhỏ nhiều giải pháp theo cách này, bạn giảm số lượng các dự án yêu cầu của một giải pháp, vì hầu hết chúng không liên quan gì đến nhau.

Có nhiều dự án trong một giải pháp chỉ là thiết kế tồi. Không có lý do gì để có nhiều dự án theo một giải pháp. Một vấn đề khác mà tôi thấy là với các tham chiếu dự án, chúng thực sự có thể khiến bạn khó chịu, đặc biệt nếu bạn muốn chia giải pháp của mình thành những giải pháp nhỏ hơn.

Lời khuyên của tôi là hãy làm điều này và phát triển một khuôn khổ tập trung (việc triển khai Thư viện Doanh nghiệp của riêng bạn nếu bạn muốn). Bạn có thể GAC nó để chia sẻ hoặc bạn có thể tham khảo trực tiếp vị trí tệp để bạn có một cửa hàng trung tâm. Bạn cũng có thể sử dụng chiến thuật tương tự cho các đối tượng kinh doanh tập trung.

Nếu bạn muốn tham chiếu trực tiếp đến DLL, bạn sẽ muốn tham chiếu nó trong dự án của mình với copy local false (ở đâu đó như c: \ mycompany \ bin \ mycompany.dll). Thời gian chạy, bạn sẽ cần thêm một số cài đặt vào app.config hoặc web.config của mình để làm cho nó tham chiếu đến một tệp không có trong GAC hoặc thùng thời gian chạy. Trên thực tế, không có vấn đề gì nếu nó được sao chép cục bộ hay không, hoặc nếu dll kết thúc trong thùng hoặc thậm chí là trong GAC, vì cấu hình sẽ ghi đè cả hai. Tôi nghĩ rằng việc sao chép cục bộ và có một hệ thống lộn xộn là một việc làm không tốt. Mặc dù vậy, rất có thể bạn sẽ phải sao chép cục bộ tạm thời nếu bạn cần gỡ lỗi vào một trong những tổ hợp đó.

Bạn có thể đọc bài viết của tôi về cách sử dụng DLL trên toàn cầu mà không cần GAC. Tôi thực sự không thích GAC chủ yếu vì nó ngăn cản việc triển khai xcopy và không kích hoạt tự động khởi động lại trên các ứng dụng.

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

Đặt CopyLocal = false sẽ giảm thời gian xây dựng, nhưng có thể gây ra các vấn đề khác nhau trong thời gian triển khai.

Có nhiều trường hợp, khi bạn cần phải để Copy Local 'thành True, ví dụ: Các dự án cấp cao nhất, phụ thuộc cấp hai, các tệp DLL được gọi bằng phản chiếu.

Trải nghiệm của tôi với việc đặt CopyLocal = false không thành công. Xem tóm tắt về ưu và nhược điểm trong bài đăng trên blog của tôi "KHÔNG thay đổi các tham chiếu dự án" Sao chép cục bộ "thành sai, trừ khi hiểu các chuỗi con."