Tài liệu Assembly part 1 doc

Assembly là gì ?

Trước khi nền tảng .NET được giới thiệu, chúng ta đã phải giải quyết với tiền
assembly, DLL thường cung cấp các hàm dùng chung và COM DLLs cung cấp các lớp
COM. Microsoft tự giới thiệu cụm từ "DLL-Hell" để mô tả những vấn đề truyền thống
với DLL, những vấn đề này dường như chúng ta đã biết đó là Thường các chương trình
ứng dụng bị dừng hoặc lỗ
i bởi vì ứng dụng cài đặt gần nhất ghi đè một DLL lên ứng dụng
trước đó, DLL này cũng được sử dụng bởi một ứng dụng khác. Thỉnh thoảng nó xảy ra sự
cài đặt thay thế một DLL mới cho một cái cũ bởi vì sự cài đặt chương trình không kiểm
tra phiên bản một cách chính xác, hoặc phiên bản không thiết lập một cách chính xác.
Bình thường chúng không có vấn đề gì nhưng thực sự chúng có s
ự khác biệt, đúng ra
DLL mới nên được lùi lại tích hợp với DLL cũ nhưng thỉnh thoảng không như vậy, đôi
khi trường hợp này lại sảy ra quá thường xuyên.

DLL Hell

Nền tảng .NET chính là DLL Hell và tất cả vấn đề của nó là assemblies. Assemblies
là bộ cài đặt chính nó, bao gồm một hoặc nhiều files. Một assembly có thể là một đơn
DLL hoặc EXE bao gồm cả metadata, hoặc nó có thể đuợc tạ
o từ nhiều file khác, thí dụ,
các file nguồn, metadata, DLLs, và một EXE. Sự cài đặt của một assembly có thể đơn
giản như là sao chép tất cả các file của chính nó. Một tính năng mạnh của assemblies là
chúng có thể là private hoặc shared. Với COM đây là sự khác biệt không tồn tại, trước
đây gần như tất cả các thành phần COM đều được chia sè. Nếu bạn tìm kiếm thành phần
COM ở trong Registry hoặc sử dụng OleView,bạn ph
ải lục lội trong hàng trăm và hàng

trăm các thành phần. Chỉ một số nhỏ các thành phần đã được định nghĩa để sử dụng từ
một số ứng dụng, nhưng mỗi thành phần phải có một khai báo toàn cục duy nhất (global
unique identifier) (GUID).
Có sự khác biệt lớn giữa private và shared assemblies. Nhiều nhà phát triển sẽ thích hơn
nếu chỉ có private assemblies. Không có quản lý riêng, đăng ký, xác định phiên bản và
vậy nên cần làm việ
c với private assemblies. Chỉ duy nhất ứng dụng chúng có vấn đề về
phiên bản với private assemblies thì chính là ứng dụng của bạn. các thành private mà bạn
sử dụng mà ứng dụng của bạn không được cài đặt cùng thời gian với ứng dụng. Thư mục
ứng dụng cục bộ được sử dụng cho các thành phần của assemblies, cho nên bạn không
nên có bất kỳ vấn đề về phiên bản. Ứng dụng khác chưa ghi đ
è lên private assemblies của
bạn. Tất nhiên nó cũng hay khi khi sử dụng phiên bản private assemblies. Nó có lợi khi
thay đổi code, Nhưng điều này không yêu cầu trong .NET.
Khi sử dụng shared assemblies, Một vài ứng dụng có thể sử dụng assembly này và có sự
lệ thuộc vào chúng. Với shared assemblies, phải thoả mãn một số qui tắc. Một shared
assembly phải có số phiên bản cụ thể, một tên duy nhất và thường nó được cài đặt trong
global assembly cache (GAC).
Các tính năng của Assemblies
Các tính năng của assemblies có thể được tóm tắt như sau:
•
Assemblies là miêu tả bản thân (self-describing). Nó không cần thiết để đăng ký
để nhận thư viện từ nơi khác. Assemblies bao gồm metadata nó miêu tả assembly.
The metadata bao gồm các kiểu sinh ra từ assembly và một manifest; Chúng ta sẽ
tìm hiểu a manifest ở phần sau.
•
Độc lập phiên bản (Version dependencies) được ghi lại bên trong assembly
manifest. Bằng cách chứa phiên bản của nhiều tham khảo assemblies trong
manifest của assembly, Chúng ta có thể biết chính xác số phiên bản cả tham khảo
assembly nó đuợc sử dụng trong suốt quá trình phát triển. Phiên bản của tham

chiếu assembly nó được dùng để cấu hình bởi các nhà phát trỉên và nhà quản trị
hệ thống (system administrator).Phần sau của chương này chúng ta sẽ biết chúng
làm việc như thế nào.
•
Assemblies có thể được nạp side-by-side. Sử dụng Windows 2000 chúng ta có
từng bước một các tính năng và ở đâu là sự khác biệt các phiên bản của cùng DLL
được sử dụng trong hệ thống .NET mở rộng các tính năng cho Windows 2000, cho
phép các phiên bản khác nhau của cùng assembly để sử dụng bên trong một tiến
trình đơn giản, Vậy lợi ích ở đâu ? Nếu assembly A tham khảo version 1 của
shared assembly được chia sẽ, và assembly B sử dụng version 2 của shared
assembly được chia sẽ,
và bạn đang sử dụng cả hai assembly A and B, đoán xem
versions của shared assembly Chia sẽ nào được dùng trong ứng dụng của bạn -
bạn cần cả hai, và với .NET cả hai versions được nạp và sử dụng.
•
Ứng dụng độc lập được đảm bảo sử dụng (vùng sở hữu ứng dụng) application
domains. Với application domains một số các ứng dụng có thể chạy một cách độc
lập trong một đơn tiến trình. Khuyết điểm trong một ứng dụng không thể trực tiếp
ảnh hưởng các ứng dụng khác bên trong cùng tiến trình. Sự cài đặt dễ dàng như
sao chép file nó phụ thuộc vào assembly. Xcopy có thể sao chép đẩy
đủ. Tính
năng này có tên là zero-impact installation.
Tại sao Microsoft Windows Installer (MSI) vẫn còn quan trọng.
Tôi thường hỏi tại sao Microsoft Windows Installer vẫn cần thiết trong khi xcopy đã đủ
để cài đặt các ứng dụng .NET. Câu trả lời đơn giản đó là chúng ta thường muốn sao chép
nhiều file hơn một file khi cài đặt các ứng dụng Windows.
Thường chúng ta truy xuất ứng dụng từ Start menu, cài đặt thư mục con của Program
Files, Chúng ta làm vài thay đổi , hiển thị bản quyền, vân vân . . The Windows Installer
hỗ trợ
rất nhiều tính năng thêm vào khi không thể giải quyết với assemblies. Các ứng

dụng sử dụng với chính Registry settings, group policies để dễ dàng hơn trong quản lý
nơi người sử dụng truy xuất các tính năng riêng biệt, advertisement để cài đặt các ứng
dụng sau này, Khi yêu cầu bởi user, và sữa chữa các file bị sai lạc.
Application Domains
Application domain ("địa bàn hoạt động" của ứng dụng, giống như namespace là
"địa bàn hoạt động" của các tên) là một cải tiến quan trọng mà .NET đem lại trước việ
c
tiêu hao ký ức (gọi là overheah) khá nhiều để bảo đảm các ứng dụng phải được cách ly
(isolation) hoàn toàn với nhau, nhưng vẫn có thể liên lạc với nhau. Bạn cứ hình dung hai
sân quần vợt nằm kế cận, và cả hai đều có người chơi. Vấn đề là quả bóng của bên này có
thể nhảy qua bên kia, phá rối cuộc chơi. Phải làm thế nào để cách ly hai sân chơi.
Mãi tới giờ, biện pháp duy nhất để cách ly đoạn mã là thông qua tiế
n trình process. Khi
bạn khởi động một ứng dụng, thì ứng dụng này chạy trong phạm vi một process
Appliction Domain được thiết kế như là một cách để cách ly các cấu kiện với nhau,
nhưng không giảm thiểu hiệu năng hoạt động do việc trao đổi dữ liệu giữa các process. Ý
niệm nằm đằng sau là chia bất cứ process nào thành một số "địa bàn hoạt động của ứng
dụng (appliction domain). Mỗi appliction domain tương ứ
ng đối với một ứng dụng đơn
lẻ, và mỗi mạch trình (thread) thi hành sẽ được chạy trong một application domain đặc
biệt nào đó.

Nếu những đoạn mã khả thi khác nhau đều chạy trong cùng không gian ký ức của
process, rõ ràng là chúng có thể chia sẻ sử dụng dữ liệu vì theo lý thuyết chúng có thể
thấy được dữ liệu của nhau. Mặc dù có khả năng như thế, nhưng .NET runtime bảo đảm
là sẽ
không xảy ra, trong thực tế thông qua việc kiểm tra đoạn mã của mỗi ứng dụng đang
chạy bảo đảm đoạn mã không thể chạy ngoài vùng dữ liệu được cấp phát riêng cho mình.
Nhờ việc kiểm tra chặt chẽ về kiểu dữ liệu của IL, nên các điều kể trên có thể thực hiện
được. Trong đa số trường hợp, kiểu dữ liệu được sữ d

ụng sẽ bảo đảm là ký ức sẽ không
được truy xuất một cách bất hợp lệ. Thí dụ, kiểu dữ liệu kiểu bản dãy (array) của .NET
bảo đảm kiểm tra giới hạn thấp và cao (lower & upper bound) không cho phép bản dãy
hoạt động quá giới hạn.
Ví dụ: DomainTest có trong mã nguồn bạn có thể download để tham khảo .Trong ví dụ
này kết quả sẽ trả về vùng
domain đang hoạt động.
using System;
namespace Wrox.ProCSharp.Assemblies.AppDomains
{
class Class1
{
public Class1(int val1, int val2)
{
Console.WriteLine("Constructor with the values {0}, {1}" +
" in domain {2} called", val1, val2,
AppDomain.CurrentDomain.FriendlyName);
}
static void Main(string[] args)
{
Console.WriteLine("Main in domain {0} called",
AppDomain.CurrentDomain.FriendlyName);
Console.ReadLine();
}
}
}
download source