2008-12-26 39 views

Trả lời

31

Tôi nghĩ bạn đang bối rối một chút. Đăng ký một dll chưa bao giờ cần thiết để sử dụng nó.

Sử dụng dll chỉ yêu cầu tải nó (cho một vị trí đã biết hoặc nếu thư viện nằm trong đường dẫn hệ thống) và nhận địa chỉ của hàm bạn muốn sử dụng.

Đăng ký dll được sử dụng khi phân phối các đối tượng COM hoặc ActiveX cần thêm các mục nhất định vào sổ đăng ký cửa sổ. Để sử dụng dịch vụ COM (ví dụ), bạn cần tham chiếu GUID — nghĩa là mã định danh duy nhất — cho phép bạn xử lý tệp dll thực hiện dịch vụ (hoặc cung cấp quyền truy cập vào dịch vụ). Đôi khi bạn có thể tham chiếu đến tên đủ điều kiện và nhận được kết quả tương tự.

Để mọi thứ hoạt động cần phải đăng ký. Quá trình "đăng ký" này chỉ tạo ra một số mục trong sổ đăng ký, nhưng chủ yếu là hai: một liên kết GUID với vị trí của dll (để bạn có thể tham khảo nó thông qua GUID mà không biết vị trí chính xác của nó) và thứ hai liên kết tên đầy đủ với GUID. Nhưng một lần nữa, điều này chỉ dành cho các đối tượng COM hoặc ActiveX.

Khi bạn phát triển một ứng dụng trong .NET, các thư viện được tham chiếu trên dự án của bạn sẽ tự động được tải khi cần thiết mà không cần phải lo lắng về việc định vị hoặc tải chúng. Để làm được điều đó, khung kiểm tra hai vị trí cho các thư viện được tham chiếu.

  • Vị trí đầu tiên là đường dẫn ứng dụng.
  • Vị trí thứ hai là GAC.

GAC (Global Assembly Cache) cho phép bạn đăng ký hiệu quả một dll được sử dụng trên toàn hệ thống và hoạt động như một cơ chế đăng ký cũ.

Vì vậy, về cơ bản bạn chỉ cần đặt dll vào cùng một thư mục của ứng dụng.

+1

Điều này không đúng. Nếu assembly được đặt tên mạnh, nó sẽ kiểm tra GAC ​​trước. Nếu nó không được đặt tên mạnh, thì hệ thống sẽ kiểm tra GAC ​​trước, sau đó làm theo quy trình sau để định vị assembly http://msdn.microsoft.com/en-us/library/15hyw9x3.aspx – Spence

+0

arg, nếu nó không được đặt tên mạnh, hệ thống sẽ KHÔNG kiểm tra GAC, giải thích lỗi đánh máy. – Spence

+0

Điều này có áp dụng cho một cái gì đó như "Office.dll" và "Microsoft.Office.Interop.Outlook.dll" không? Chúng là các đối tượng 'COM', nhưng tôi thấy tôi không cần phải đăng ký chúng, và nó giúp ứng dụng của tôi trên các hệ thống đích (không có chúng, ứng dụng bị treo trên XP (mặc dù không phải Win7)). –

3

Thường đủ để thả dll vào thư mục ứng dụng của bạn trên máy mục tiêu.

Nếu dll phải có sẵn cho các ứng dụng khác thì bạn có thể muốn xem xét GAC.

5

Bạn cần phải "thả" nó vào một thư mục mà ứng dụng cần nó sẽ tìm thấy.

Nếu có nhiều ứng dụng hoặc bạn muốn "thả" tệp ở đâu đó ngoài thư mục ứng dụng, bạn thường cần điều chỉnh biến PATH hoặc đăng ký lắp ráp trong Bộ đệm ẩn toàn cục (GAC).

0

Ứng dụng có thể sử dụng tệp .dll .NET bằng cách đơn giản có nó xuất hiện trong cùng thư mục với ứng dụng.

Tuy nhiên, nếu bạn muốn các ứng dụng của bên thứ ba khác tìm thấy tệp DLL và sử dụng nó, họ cũng sẽ phải đưa nó vào phân phối của họ. Điều này có thể không được mong muốn.

Cách khác là đăng ký DLL trong GAC (Bộ nhớ lắp ráp toàn cục).

3

Nếu bạn muốn access the assembly via com+. Một ví dụ sẽ sử dụng một kiểu được định nghĩa trong một hội đồng .NET từ một ứng dụng không .NET, chẳng hạn như một ứng dụng winforms VB6.

Nếu bạn định truy cập vào assembly từ ứng dụng .NET khác, bạn không phải làm gì cả. Nếu lắp ráp của bạn có một tên mạnh, nó có thể là một ý tưởng tốt để thả nó trong GAC. Nếu không, chỉ cần thả nó vào thư mục của ứng dụng sẽ tham chiếu nó.

3

Một trong những điểm bán hàng tuyệt vời của .NET cho nền tảng Windows khi xuất hiện trên màn hình là theo mặc định, DLL hội tụ .NET không cần phải được đăng ký và có thể được sử dụng riêng bởi ứng dụng bằng cách đơn thuần đặt chúng trong cùng thư mục với tệp EXE. Đó là một bước tiến lớn bởi vì nó cho phép các nhà phát triển tránh sự cạnh tranh của DLL/COM hell.

Mô-đun DLL/COM được chia sẻ đã chứng tỏ là một trong những lỗi thiết kế lớn nhất của Windows vì nó dẫn đến sự bất ổn của các ứng dụng mà người dùng đã cài đặt. Cài đặt một ứng dụng mới cũng có thể làm hỏng một ứng dụng đã hoạt động tốt - vì ứng dụng mới đã giới thiệu các phiên bản mới hơn của các mô-đun DLL/COM được chia sẻ. (Nó được chứng minh trong thực tế là quá nhiều gánh nặng cho các nhà phát triển để quản lý đúng các phụ thuộc phiên bản chi tiết.)

Đó là một điều để quản lý các phiên bản mô-đun với hệ thống kho lưu trữ như Maven. Maven hoạt động rất tốt với những gì nó làm.

Tuy nhiên, đó là một vấn đề hoàn toàn khác, để giải quyết vấn đề đó trong môi trường thời gian chạy của người dùng cuối trải rộng trên dân số hàng triệu người dùng.

.NET GAC không phải là giải pháp thích hợp cho vấn đề Windows cũ kỹ này.

Hội đồng DLL được tiêu thụ riêng sẽ tiếp tục vô cùng thích hợp hơn. Đó là một cách không có trí tuệ để đi như diskspace là cực kỳ rẻ những ngày này (~ $ 100 có thể bởi một terabyte ổ đĩa tại Fry của những ngày này). Không có gì để đạt được với các hội đồng chia sẻ với các sản phẩm khác - và danh tiếng của công ty bị mất đi khi mọi thứ đi về phía nam cho người dùng kém.

+0

Vâng, tôi đã làm việc tại Microsoft trong nửa thập kỷ, nơi tôi xử lý các vấn đề địa ngục DLL/COM/DCOM trên mọi dự án tôi đã tham gia. Và sau đó tôi làm việc trên dự án .NET khi nó được phát triển lần đầu tiên - nơi chữa trị vấn đề địa ngục DLL/COM thông qua các hội đồng tư nhân là một kết quả rõ ràng mong muốn – RogerV

2

Thực ra KHÔNG cần đăng ký dll bằng .NET trên máy mục tiêu.

Nếu bạn tham khảo một .dll trong ứng dụng của mình, hãy nhấp vào .dll được tham chiếu trong tài liệu tham khảo trong dự án của bạn, xem các thuộc tính và đặt Được đặt thành TRUE.

Điều này sẽ tự động bao gồm tệp .dll này trong dự án của bạn và ứng dụng của bạn sẽ sử dụng bản sao của .dll có trong dự án của bạn mà không cần đăng ký nó trên hệ thống đích.

Để xem một ví dụ làm việc này xem ở đây:

http://code.msdn.microsoft.com/SEHE

Các .dll trong câu hỏi sẽ cần phải được đăng ký trên hệ thống mà bạn xây dựng ứng dụng của bạn để làm việc này đúng cách. Tuy nhiên một khi bạn xây dựng dự án của bạn, sẽ không có bất kỳ cần phải đăng ký dll trong câu hỏi trên bất kỳ hệ thống bạn triển khai ứng dụng hoặc chương trình của bạn.

Lợi ích bổ sung của việc sử dụng phương pháp này, ngay cả khi trong tương lai, một .dll khác được đăng ký với cùng tên trên hệ thống đích được đề cập, dự án của bạn sẽ tiếp tục sử dụng .dll bạn đã triển khai. Điều này rất tiện dụng trong đó a.dll có nhiều phiên bản và bạn muốn duy trì một số tính ổn định, như sử dụng một trong những bạn đã thử nghiệm, nhưng tất cả các ứng dụng khác sẽ sử dụng .dll đã đăng ký trừ khi họ sử dụng phương thức isolated = true.

Ví dụ trên là một trong những trường hợp đó, có rất nhiều phiên bản của Skype4COM là một API Skype .dll và có thể thay đổi thường xuyên.

Phương pháp này cho phép ví dụ trên sử dụng API .dll mà dự án đã được thử nghiệm, mỗi khi người dùng cài đặt phiên bản Skype mới, có thể phiên bản sửa đổi của .dll này đã được cài đặt.

Ngoài ra, có một số ứng dụng khách Skype không cài đặt .dll này, phiên bản doanh nghiệp của ứng dụng khách Skype chẳng hạn, nhỏ hơn và không bao gồm .dll này, vì vậy trong trường hợp này, dự án không thành công trên đó .dll mất tích và không được đăng ký vì nó được bao gồm trong dự án như bị cô lập = true.

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