Khi nào tôi nên triển khai các hội đồng của mình vào GAC?

Question

Tôi muốn biết thực tế loại Assemblies nào tôi nên triển khai trong GAC.

Trường hợp 1: Nếu trong dự án đa giải pháp của tôi sử dụng log4net.dll thì nó có được triển khai trong GAC không?

Trường hợp 2: Nếu tôi có nhiều ứng dụng được triển khai trong một máy sử dụng log4net.dll thì đây có phải là lý do đủ để triển khai log4net.dll vào GAC không?

Answer 1

Câu hỏi: Khi nào tôi nên triển khai các hội đồng của mình vào GAC?

Trả lời: Never

thực tế, trung thực, Real trả lời: Hầu như không bao giờ

Thảo luận

Chỉ thả mọi thứ vào GAC khi nhiều ứng dụng trên máy tính này sẽ sử dụng lắp ráp, và khi lắp ráp là cơ sở (có khả năng được sử dụng bởi nhiều ứng dụng), khi nó được ký kết, và khi bạn mong đợi gần như không bao giờ cập nhật hội đồng đó. Có thể thêm vào đó, khi có nhiều phiên bản độc lập của một DLL được triển khai với mỗi ứng dụng thực sự sẽ có hại.

Ví dụ về sau là: giả sử bạn có 2 ứng dụng độc lập, được phát triển độc lập và triển khai độc lập. Tuy nhiên, có một khả năng mà họ sẽ liên lạc với nhau. Họ sẽ trao đổi ... một cái gì đó ... trên .NET Remoting trên máy địa phương. Nếu bạn có một hội đồng duy nhất trong GAC, các ứng dụng này được đảm bảo rằng liên lạc sẽ chỉ hoạt động. Tuy nhiên, nếu họ có một phiên bản riêng biệt của một hội đồng, họ có thể không có khả năng trao đổi đồ vật. Đây là một sự xuất hiện hiếm hoi mà bạn có thể không cần đến nó. Nếu bạn không chắc chắn, thì bạn không cần nó.

---

Kịch bản GAC cơ sở là Thư viện lớp cơ sở .NET. Các hội đồng này được vận chuyển bởi Microsoft. Chúng có thẩm quyền. Chúng là nền tảng. và đã ký. Họ hiếm khi thay đổi. Tất cả các ứng dụng nên sử dụng cùng một bản sao của các tệp DLL đó. Vì vậy, chúng thuộc về GAC.

Ngược lại, DLL ứng dụng của bạn không phải từ Microsoft, chúng không phải là nền tảng và có thể chưa được ký. Chúng thay đổi thường xuyên hơn và chỉ có một vài ứng dụng (có thể chỉ một ứng dụng!) Sử dụng từng DLL. Không có GAC.

---

Tôi có thể tưởng tượng thiết bị phần cứng, giả sử một máy ảnh kỹ thuật số, cài đặt phiên bản .NET để cho phép lập trình. Đó là một kịch bản mà hội đồng có thể phù hợp tốt với GAC. Nó cho phép các ứng dụng .NET tùy ý truy cập vào máy ảnh kỹ thuật số theo lập trình.

---

Ví dụ về log4net của bạn không, theo ý kiến ​​của tôi, đủ để biện minh cho việc lắp ráp GAC. Hãy tưởng tượng kịch bản mà một trong các ứng dụng nhận được bản cập nhật và là một phần của bản cập nhật nó sử dụng phiên bản mới của log4net. Giờ thì sao? Nên lắp ráp log4net mới vào GAC? Chắc là không.

Toàn bộ ý tưởng chia sẻ các tệp DLL trên các ứng dụng được bắt nguồn từ tiền đề rằng bộ nhớ và dung lượng đĩa bị khan hiếm. Ngày xửa ngày xưa, đó là sự thật. Nó không còn là sự thật nữa. Khi nghi ngờ, không sử dụng GAC.

Answer 2

Những gì bạn mô tả là một tình huống đủ phong nha để đặt một hội đồng trong GAC. Thành thật mà nói, tôi sẽ tránh nó. Với GAC bạn phải lo lắng về việc đặt tên mạnh mẽ và các hội đồng đáng tin cậy và phiên bản lắp ráp cụ thể. Nếu bạn không có lý do rõ ràng để cần chúng. Nó chỉ là dễ dàng để triển khai dll nhiều lần cho mỗi dự án.

Tôi biết điều này đi ngược lại việc lưu trữ nhiều bản sao của cùng một đoạn mã, v.v., nhưng tôi luôn thấy dễ dàng hơn chỉ để tránh sử dụng GAC. Khi tôi đã sử dụng nó, GAC luôn luôn là phiền hà, bởi vì bạn phải lo lắng nếu GAC có tất cả các assembly chính xác cho dự án (vì assembly có thể tham chiếu đến các assembly khác). Khi bạn không sử dụng GAC, nó dễ dàng hơn nhiều để đi, "Có phải các hội chúng ở đó không?" "Đúng, họ đang ở trong thư mục ứng dụng."

Thời gian duy nhất tôi từng thấy hữu ích là khi tôi phải xây dựng một dịch vụ SharePoint WSS 2.0. Tôi chạy vào một thời điểm khi cập nhật phần cấu hình để cho phép sự tin tưởng là cồng kềnh (vì chính sách của công ty) và đặt nó vào GAC để cho phép nó được tin cậy hoàn toàn thì không. Đây là một trường hợp rất hiếm.

Answer 3

Loại lắp ráp duy nhất bạn nên xem xét đưa vào GAC là một hội đồng trưởng thành và ổn định. Trong trường hợp của log4net, nếu bạn hài lòng với phiên bản bạn đã ổn định, trưởng thành và bạn không có khả năng thay đổi phiên bản đó bất kỳ lúc nào, hãy đặt nó vào GAC.

Đừng cố gắng đặt các thư viện trong GAC có khả năng thay đổi, đặc biệt nếu bạn đang phát triển chúng trong nhà và vẫn còn phạm vi để cải thiện hơn nữa. Triển khai chúng như là hội đồng tư nhân thay thế.

Tôi đã thấy mọi người truyền giáo kỳ quan về mã được chia sẻ. Họ nói những thứ như "ah, chúng tôi sẽ cải thiện 20 ứng dụng cùng lúc với thay đổi mã này". Vấn đề là, bạn cũng có thể phá hủy 20 ứng dụng cùng một lúc nếu bạn làm sai. Tôi đã thấy mọi người nói "Tôi vừa mới ra mắt trang X. Bạn có thể kiểm tra các trang A-W để đảm bảo chúng vẫn hoạt động được không?".

Hội đồng tư nhân có thể là một nỗi đau, nhưng các vấn đề mà bạn có thể gặp phải sẽ bị hạn chế đối với ứng dụng cụ thể mà chúng được triển khai. Nếu bạn không chắc chắn 100% rằng một assembly không ổn định và trưởng thành, đừng đặt nó vào GAC.

Hãy tin tôi đi, bạn sẽ ngủ ngon hơn.

Answer 4

log4net.dll có kích thước 95KB. ngay cả khi bạn triển khai nó 100 lần nó sẽ không thực sự quan trọng với harddisks todays. tôi cố gắng tránh GAC ở bất cứ nơi nào có thể vì một số lý do:

• làm cho việc triển khai khó hơn, bạn phải nói trình cài đặt những gì cần đưa vào GAC. tôi thích khả năng tạo các thiết lập xcopy đơn giản (sao chép một thư mục để cài đặt, xóa nó để gỡ cài đặt). bởi vì điều đó đơn giản - nhưng nó không hoạt động tốt như vậy ngay sau khi bạn phải đưa mọi thứ vào GAC.
• bạn phải ký tên vào hội đồng của mình. chỉ để đưa họ vào GAC ....
• ngay sau khi nhà phát triển tham chiếu điều gì đó từ GAC trong dự án studio trực quan của mình, tham chiếu sẽ bị mất khi nhà phát triển khác mở giải pháp trên máy tính của anh ấy. trước tiên anh ta sẽ phải lấy các assembly cần thiết vào GAC trước khi anh ta có thể mở và biên dịch thành công giải pháp. đó là một PITA thực sự. tôi muốn có thể thanh toán, biên dịch và chạy mà không có lỗi.