Xem lại Cài đặt GAC

Question

Vòng tròn này tròn và tròn tôi biết nhưng tôi dường như không thể tìm thấy câu trả lời thỏa đáng.

Hội đồng có nên tham gia GAC ​​không? Những câu hỏi sau: when-and-when-not-to-install-into-the-gac và What are the advantages and disadvantages of using the GAC, giải quyết chính xác điều đó nhưng câu trả lời là rất nhiều "bạn nên ..." hoặc "bạn chỉ nên ...". Tại sao???

Rất nhiều blog của GAC ​​naysaying dường như có từ ngày 5/6 năm trước khi ngôi sao của .Net bắt đầu tăng lên. Chúng ta có còn ở đó không? Chắc chắn DLL-Hell là một điều của quá khứ với các bên hỗ trợ GAC bên cài đặt các phiên bản khác nhau của "cùng" lắp ráp?

Hãy để tôi nêu ra những lo ngại của mình. Chúng tôi có một bộ ứng dụng web ngày càng tăng (5 cho đến nay). Đây là những phần mở rộng của ứng dụng bên thứ ba thông qua các cuộc gọi API và phần mở rộng cơ sở dữ liệu. Rõ ràng, do đó, tất cả các ứng dụng này chia sẻ nhiều mã chung và chúng tôi đang phát triển một bộ thư viện chia sẻ cốt lõi mới để cải thiện chất lượng, bảo trì, v.v.

Chắc chắn tôi muốn chức năng chia sẻ này được cài đặt một lần và chia sẻ. Tất cả các lập luận về việc mở một cơn ác mộng bảo trì dường như dựa trên một số thế giới của kỷ luật nghèo. Nếu bạn phá vỡ ABI sau đó chạm vào AssemblyVersion là đủ để giữ cho các ứng dụng hiện tại của bạn hoạt động.

GAC thực sự là một cái bẫy mật ong cho sự không ngờ? Tôi có ngây thơ không? Tôi có phải là không cần thiết khắc nghiệt khi tôi bác bỏ các lý do trích dẫn sự mất mát của 'XCopy' cài đặt như là whinges lười biếng? Hoặc là nó nhận được một chút "Tôn giáo" và tôi chỉ nên đi với những gì có vẻ đúng?

Cảm ơn bạn đã giúp tôi nhìn thấy ánh sáng.

Dan

Answer 1

Cá nhân tôi chưa bao giờ cài đặt bất kỳ hội đồng nào trực tiếp trong GAC (ngoại trừ một bài tập thuần túy về học thuật). Tôi đã nghe những lý lẽ trước khi về việc sử dụng một hội đồng từ một vị trí tập trung được truy cập từ một số ứng dụng, và trong khi đó có vẻ hơi hấp dẫn, cá nhân, nó không có giá trị thời gian của tôi. Máy tính đi kèm với 320GB không gian đĩa cứng những ngày này ... lắp ráp measly 160K của tôi sẽ không làm cho một vết lõm trong đó, ngay cả khi nó được sao chép 5 lần. (Tất nhiên, một số người có thể tranh luận "vấn đề của commons" ... bạn biết: "nếu mọi nhà phát triển nghĩ như vậy ....", nhưng tôi digress). Lý do chính tôi chọn không làm điều này là bởi vì một ứng dụng cụ thể có thể dựa vào lắp ráp theo một cách, trong khi một ứng dụng khác có thể dựa vào nó theo một cách khác. Trong khi trong một thế giới lý tưởng, cập nhật cho hội đồng này không bao giờ nên ảnh hưởng đến các ứng dụng dựa vào nó, trong thực tế, nó thường làm. Nếu tôi đang sửa chữa một vấn đề với một assembly bởi vì một ứng dụng cụ thể có vấn đề với nó, tôi vô tình ảnh hưởng đến các ứng dụng khác dựa vào assembly cụ thể đó. Mặt khác, một số người có thể lập luận rằng tình huống này làm cho chúng ta lập trình tốt hơn và làm cho hội đồng GAC-Shared của chúng ta chống đạn hơn. Điều đó thật tuyệt, nhưng công việc của tôi là một lập trình viên không phải là chủ yếu để làm cho mình trở thành một lập trình viên giỏi hơn, nhưng để viết các chương trình hoạt động, và làm như vậy, tôi sẽ trở thành một lập trình viên tốt hơn.

Vì vậy, phiếu bầu của tôi là gì? Tránh xa GAC. Hãy để mỗi ứng dụng dựa vào phiên bản của assembly mà chúng được xây dựng để dựa vào.Một lỗi tiếp xúc trong assembly đó bởi một ứng dụng có thể không bao giờ xuất hiện trong các ứng dụng khác, bởi vì chúng đang sử dụng assembly khác nhau, vì vậy hãy để chúng lại và bạn sẽ không phải kiểm tra hồi quy 5 ứng dụng riêng biệt mỗi khi DLL được chia sẻ của bạn bị vá .

Answer 2

Tôi sử dụng theo chiến lược yếu.
Sử dụng GAC - khi các chương trình khác nhau sử dụng phiên bản chia sẻ + phiên bản.
Không sử dụng GAC - luôn luôn.

mọi nhận xét đều được chào đón.