Lập trình trong môi trường .NET - Visual Studio.NET (Phần 3)

ì 
cửa sổ biến mất, thu mình lại qua phía tay phải hoặc tay trái. 
Xây dựng một dự án 
Building, Compiling và Making 
Trước khi ta đi sâu vào việc xem xét những lựa chọn khác nhau liên quan 
đến việc xây dựng một dự án, thiết tưởng ta nên làm sáng tỏ những từ ngữ 
liên quan đến tiến trình biến mã nguồn của bạn thành một loại đoạn mã khả 
thi. Bạn thường biết đến 3 từ: compiling, building, making. Nguyên nhân của 
những từ ngữ khác nhau là do việc chuyển một mã nguồn thành một mã khả 
thi đòi hỏi không chỉ một bước mà thôi. Trên C++ chẳng hạn mỗi tập tin 
nguồn phải được biên dịch riêng lẽ, cho ra một tập tin đối tượng, mang dáng 
dấp đoạn mã khả thi nhưng mỗi tập tin đối tượng chỉ liên hệ với một tập tin 
nguồn. Muốn cho ra một mã kết sinh các tập tin đối tượng này phải liên kết 
lại một tiến trình mà người ta gọi là linking. Tiến trình phối hợp thường gọi 
là xây dựng (building) đoạn mã theo từ ngữ windows. Tuy nhiên, theo từ 
ngữ C#, thì trình biên dịch phức tạp hơn nhiều có khả năng đọc và xử lý tất 
cả các tập tin nguồn như một khối. Do đó, đối với C# không có giai đoạn 
liên riêng lẽ nên trong phạm trù C# các từ compiling và building coi như 
giống nhau. 
Còn từ making cũng có nghĩa là xây dựng nhưng nó không được dùng trong 
phạm trù C#. Từ này xuất xứ từ những máy tính mainframe, cho biết khi một 
dự án gồm nhiều tập tin nguồn, thì có một tập tin riêng lẽ được viết ra chứa 
những chỉ thị dành cho trình biên dịch biết cách xây dựng một dự án. Tập tin 
riêng rẽ này được gọi là make file, do đó từ này tiếp tục được dùng như là 
chuẩn trên Unix hoặc Linux. Các tập tin make thường không cần đến trên 
Windows, mặc dù bạn có thể viết chúng hoặc yêu cầu Visual Studio.NET 
kết sinh chúng nếu bạn muốn. 
Debug build và Release Build 
Khi bạn gỡ rối chương trình, bạn thường muốn chương trình khả thi có một 
cách ứng xử khác đi khi bạn cho phân phối chương trình. Khi phân phối 
chương trình ngoại trừ việc chương trình phải chạy tốt không có lỗi, nó còn 
phải có kích thước càng nhỏ càng tốt và còn phải chạy thật nhanh. Rất tiết là 
những đòi hỏi trên không hợp với nhu cầu gỡ rối chương trình, với nhiều lý 
do sau đây. 
Tối ưu hoá 
Hiệu năng cao của đoạn mã phần lớn là do việc trình biên dịch đã tối ưu hoá 
đoạn mã. Đây có nghĩa khi biên dịch, trình biên dịch sẽ nhìn vào mã nguồn 
xem có thể nhận diện những đoạn mà nó có thể thay thế bởi một đoạn mã 
khác cho ra kết quả y chang nhưng tối ưu hơn, chạy hiệu quả hơn. 
double InchesToCm(double Ins) 
{ 
 return Ins*2.54; 
} 
// later on in the code 
Y = InchesToCm(X); 
Trình biên dịch có thể thay thế câu lệnh trên bởi: 
Y = X * 2.54; 
Hoặc chẳng hạn trình biên dịch gặp phải đoạn mã như sau: 
{ 
 string Message = "Hi"; 
 Console.WriteLine(Message); 
} 
Thì nó thay thế bởi 
Console.WriteLine("Hi"); 
Như vậy, ta có thể tiết kiệm những nơi nào có những khai báo tham khảo đối 
tượng một cách không cần thiết. 
Các ký hiệu Debugger 
khi bạn gỡ rối chương trình, thường bạn cần xét đến trị của những biến mà 
bạn sẽ khai báo chúng theo tên trên mã nguồn. Khổ nỗi là chương trình khả 
thi EXE lại không chứa tên biến, vì trình biên dịch đã cho thay thế bởi 
những vị chỉ ký ức. .NET đã thay đổi tình trạng trên bằng cách cho trữ vài 
tên trên assembly nhưng chỉ một số nhỏ liên quan đến các lớp và phương 
thức. 
Các chỉ thị gỡ rối extra trên mã nguồn 
Khi bạn đang gỡ rối chương trình, trong đoạn mã của bạn sẽ có phụ thêm 
những dòng lệnh cho phép hiển thi những thông tin cốt tử liên quan đến gỡ 
rối. Lẽ dĩ nhiên là trước khi gữi đi phân phối chương trình của bạn, bạn 
muốn cho gỡ bỏ những dòng lệnh extra này. Bạn có thể làm điều này bằng 
tay nhưng tốt hơn là bạn cho đánh dấu những dòng lệnh này làm thế nào 
trình biên dịch sẽ bỏ qua khi biên dịch sẽ bỏ qua khi biên dịch đoạn mã cần 
được gửi đi. Chúng ta đã biết qua phần tiền chỉ thị (preprocessor directive), 
các chỉ thị này có thể dùng phối hợp với thuộc tính Conditional, xem như là 
điều kiện biên dịch. 
Cuối cùng bạn thấy là trình biên dịch một phiên bản dùng cho ra một sản 
phẩm phần mềm khác so với phiên bản đang được gỡ rối. Visual studio.NET 
thực hiện việc này bằng cách trữ nhiều chi tiết hơn để có thể hỗ trợ hai loại 
xây dựng khác nhau. Những bộ chi tiết khác nhau về thông tin xây dựng 
đựoc gọi là Configuration. Khi bạn tạo một dự án mới, Visual studio.NET sẽ 
tự động tạo cho bạn hai cấu hình được cho mang tên là Debug và Release : 
 Debug configuration: thường sẽ cho biết cho cần tối ưu hóa, thông tin 
gỡ rối extra sẽ hiệu sẽ chỉnh sửa trên đoạn mã khả thi, và trình biên dịch giả 
định là chỉ thị tiền xử lý debug hiện diện trừ khi nó được ghi rõ ra là 
#undefined trong mã nguồn. 
 Release configuration: thường cho trình biên dịch biết là phải tối ưu 
hoá và như vậy sẽ không có những thông tin extra liên quan đến gỡ rối và 
trình biên dịch không được giả định là bất cứ chỉ thị tiền xử lý hiện diện 
trong đoạn mã . 
Chọn cấu hình 
Một câu hỏi được đặt ra là visual studio.NET trữ những chi tiết trên hai cấu 
hình, thế thì cấu hình nào sẽ được chọn khi xây dựng một dự án. Câu trả lời 
là bao giờ cũng có một cấu hình hiện dịch mà Visual studio.NET phải dùng 
đến. Theo mặc nhiên, khi bạn tạo một dự án, cấu hình debug bao giờ cũng là 
cấu hình hiện dịch. Bạn có thể thay đổi cấu hình hiện dịch bằng cách ra lệnh 
Build/Configuration Manager... để hiện lên khung đối thoại Configuration 
Manager, rồi chọn mục Debug hoặc Release trên ô liệt kê Active solution 
Configuration hoặc trên thanh công cụ chính có ô liệt kê cho phép bạn chọn 
debug hoặc Release hoặc Copnfiguration Manager. 
Hiệu đính cấu hình 
Chọn dự án muốn chỉnh sửa trên cửa sổ Solution explorer, rồi ra lệnh project 
/ Properties, hoặc click phải trên dự án để hiện lên trình đơn short cut, rồi 
bạn chọn mục properties. Lúc này khung đối thoại Properties pages hiện 
lên. 
Khung đối thoại này chứa một tree view phía tay trái cho phép bạn lựa chọn 
khá nhiều vùng khác nhau để quan sát hoặc chỉnh sửa. Chúng tôi không thể 
cho thấy tất cả các lĩnh vực nhưng chúng ta sẽ cho thấy vài lĩnh vực quan 
trọng. 
Ở hình trên cho thấy hai mắt nút cấp cao: Common properties và 
Configuration properties. Ta thấy Common properties/General đối với dự 
án Basic ConsoleApp. Bạn có thể chọn tên assembly cần được kết sinh. Mục 
chọn Output type ở đây là: Console application, window application và 
class library. Bạn có thể thay đổi loại assembly nếu bạn muốn nhưng xem ra 
hơi vô lý, vì lúc ban đầu bạn đã chọn rồi trên khung đối thoại New Project. 
Hình bên dưới cho thấy cấu hình xây dựng : 
 Trên đầu khung đối thoại, bạn thấy có một list box " Configuration" cho 
phép bạn khai báo cấu hình nào bạn muốn quan sát. Trong trường hợp cấu 
hình Debug, ta có thể thấy là những chỉ thị tiền xử lý DEBUG và TRACE 
được giả định là có, việc tối ưu hoá không được thực hiện và những thông 
tin gỡ rối sẽ được kết sinh. 
Nhìn chung, sở dĩ chúng tôi đi vào chi tiết liên quan đến cấu hình, nhưng 
phần lớn trưòng hợp ít khi bạn phải điều chỉnh chúng. Tuy nhiên bạn phải 
hiểu để chọn đúng cấu hình tuỳ theo việc bạn xây dựng thế nào dự án của 
bạn và cũng là điều bổ ích khi biết tác dụng của những cấu hình khác nhau. 
Gỡ rối chương trình 
Trên C#, cũng như trên các ngôn ngữ đi trước .NET, kỹ thuật chính trong 
việc gỡ rối chuơng trình là đơn giản đặt những chốt dừng, rồi sử dụng chúng 
để xem xét việc gì xảy ra trong đoạn mã của bạn tại một điểm nào đó trong 
khi thi hành chương trình. 
Các chốt ngừng: 
Bạn có thể đặt các chốt ngừng từ Visual studio.NET lên bất cứ dòng nào trên 
đoạn mã hiện đang được thi hành. Cách đơn giản nhất là click lên dòng lệnh 
trên code editor, trên biên trái màu xám. Dòng lệnh đổi màu với một chấm 
tròn ở biên trái. Lúc này một chốt ngừng được đặt để trên hàng này, làm cho 
việc thi hành sẽ tạm ngừng khi Debugger đạt đến hàng này và chuyển quyền 
điều khiển cho debuger. Nếu bạn click trên chấm tròn của dòng lệnh này thì 
xem như chốt ngừng bị gỡ bỏ, dòng lệnh trở lại màu bình thường của văn 
bản. 
Các cửa sổ quan sát 
Khi một chốt ngừng đã đạt đến, thường thì bạn muốn khảo sát. Lúc này một 
ô hình chữ nhật màu vàng hiện lên cho biết trị của biến. Tuy nhiên, có thể 
bạn lại muốn sử dụng của sổ Watch window để xem nội dung của các biến 
cửa sổ dạng thẻ. Cuối màn hình code editor là một loạt thẻ các cửa sổ Local, 
Auto, Watch, Call stack, Breakpoint, Command, Output ... Các cửa sổ này 
chỉ hiện lên khi chương trình đang chạy dưới sự điều khiển của Debugger. 
Có 3 loại cửa sổ kiểu tab dùng điều khiển những biến khác nhau: 
Autos: cho biết tình trạng của một vài biến được truy xuất khi chương trình 
đang thi hành. 
Locals: Cho biết tình trạng của biến được truy xuất trong phương thức đang 
thực thi 
Watch : cho biết tình trạng của bất cứ biến nào mà bạn đã khai báo rõ ra 
bằng cách gõ vào tên biến trong cửa sổ Watch. 
Biệt lệ 
Biệt lệ cho phép bạn thụ lý cách thích ứng những điều kiện sai lầm xảy ra 
trong ứng dụng mà bạn muốn phân phối. Nếu được sử dụng đúng đắn, biệt lệ 
bảo đảm ứng dụng của bạn kiểm soát tốt hoạt động và người sử dụng không 
phải phiền lòng khi nhận những khung đối thoại mang tính quá kỹ thuật. Tuy 
nhiên, điều phiền toái là khi gỡ rối, biệt lệ gây không ít khó khăn cho bạn. 
Có hai vấn đề: 
Nếu biệt lệ xảy ra, thì liền sau đó khi bạn đang gỡ rối thường thì bạn không 
muốn biệt lệ được tự động thụ lý bởi chương trình của bạn. Thay vào đó, 
bạn muốn Debugger nhập cuộc để xem ra vì sao biệt lệ xảy ra, để có thể gỡ 
bỏ lý do sai lầm trước khi phân phối sản phẩm. 
Nếu một biệt lệ xảy ra mà bạn chưa hề viết một hàm thụ lý biệt lệ này, thì 
.NET runtime sẽ đi tìm tiếp một hàm thụ lý biệt lệ. Tuy nhiên, đến khi .NET 
Runtime nhận ra là không có hàm nào, nó sẽ cho chấm dứt chương trình. Và 
lúc này, cửa sổ Call Stack cũng sẽ biến mất không còn gì để bạn có thể xem 
xét trị của các biến, vì chúng đã ra ngoài phạm vi.