Giáo trình lập trình C# doc

Giáo trình Lập trình với C# Chương 1 - Kiến trúc của C# và .NET Chương 2 - Căn bản C# Chương 3 - Hướng đối tượng trong C# Chương 4 - Những chủ đề tiến bộ trong C# Chương 5 - C# và các lớp cơ sở Chương 6 - Lập trình trong môi trường .NET Chương 7 - Windows Applications Chương 8 - Assemblies Chương 9 - Truy cập cơ sở dữ liệu với .NET Chương 10 - Viewing .NET Data Chương 11 - Thao tác XML Chương 12 - File and Registry Operations Chương 13 - Làm việc với Active Directory Biên dịch từ cuốn Professional C#, 2nd Edition, Xuất bản bởi Wrox Press Ltd . Chương 1: C# và kiến trúc .NET Tổng quan: Tôi muốn nhấn mạnh rằng đừng bao giờ xem xét ngôn ngữ C# một cách tách biệt, nó luôn đồng hành với "Bộ khung .NET". C# là một trình biên dịch hướng .NET, nghĩa là tất cả các mã của C# luôn luôn chạy trên trên môi trường .NET Framework. Điều đó dẫn đến 2 hệ quả sau: • Cấu trúc và các lập luận C# được phản ánh các phương pháp luận của .NET ngầm bên dưới. • Trong nhiều trường hợp, các đặc trưng của C# thậm chí được quyết định dựa vào các đặc trưng của .NET, hoặc thư viện lớp cơ sở của .NET. Chính bởi tầm quan trọng của .NET, nên các bạn cần phải biết sơ qua về .NET trước khi đi vào ngôn ngữ C#. Đây cũng chính là mục đích của chương này. Chúng ta sẽ tìm hiểu xem chuyện gì sẽ xảy ra khi mã của các ngôn ngữ hướng .NET (bao gồm C#) được biên dịch và thực thi. Đây là một lĩnh vực rộng, chúng ta sẽ tìm hiểu kĩ hơn về Microsoft Intermediate Language (MS-IL), ngôn ngữ trung gian trong .NET mã của các ngôn ngữ khác đều phải được biên dịch về ngôn ngữ này trước khi thực thi. Cụ thể chúng ta sẽ tìm hiểu xem cách thức mà MS-IL với phần dùng chung Common Type System (CTS) và Common Language Specification (CLS) có thể cung cấp cho chúng ta sự tương hoạt giữa các ngôn ngữ hướng .NET. Chúng ta cũng sẽ trình bày các ngôn ngữ biết .NET khác bao gồm VB và C++. Sau đó chúng ta sẽ xem xét các đặc trưng khác của .NET, bao gồm các assembly, các namespace, và thư viện lớp cơ bản của .NET. Chúng ta sẽ kết thúc chương này bằng việc liệt kê vắn tắt về các loại ứng dụng mà chúng ta có thể tạo ra trong C#. Mối quan hệ giữa C# và .NET C# là một ngôn ngữ lập trình mới, và được biết đến với hai lời chào: • Nó được thiết kế riêng để dùng cho Microsoft's .NET Framework (Một nền khá mạnh cho sự phát triển, triển khai, hiện thực và phân phối các ứng dụng) • Nó là một ngôn ngữ hoàn toàn hướng đối tượng được thiết kế dựa trên kinh nghiệm của các ngôn ngữ hướng đối tượng khác. Một điều quan trọng cần nhớ C# là một ngôn ngữ độc lập. Nó được thiết kế để có thể sinh ra mã đích trong môi trường .NET, nó không phải là một phần của .NET bởi vậy có một vài đặc trưng được hỗ trợ bởi .NET nhưng C# không hỗ trợ và bạn cũng đừng ngạc nhiên khi có những đặc trưng C# hỗ trợ mà .NET không hỗ trợ (chẳng hạn như quá tải toán tử) Để tạo được những ứng dụng mang tính hiệu quả cao, chúng ta sẽ xem qua về hoạt động của .NET Common Language Runtime Trung tâm của .NET framework là môi trường thời gian chạy, gọi là Common Language Runtime (CLR) hoặc .NET runtime. Mã của các điều khiển trong CLR thường là mã có quản. Tuy nhiêu, trước khi được thực thi bởi CLR, mã được phát triển trong C# (hoặc các ngôn ngữ khác) cần phải được biên dịch.Quá trình biên dịch trong .NET xảy ra theo hai bước: 1. Dịch mã nguồn thành Microsoft Intermediate Language (MS-IL) 2. Dịch IL thành mã nền cụ thể bởi CLR Mới nhìn có vẻ hơi dài dòng. Nhưng thật sự, một tiến trình dịch hai mức là rất cần thiết, bởi vì trạng thái của Microsoft Intermediate Language (mã có quản) là chìa khóa cung cấp nhiều lợi ích trong .NET. Các lợi ích của mã có quản Microsoft Intermediate Language (thường được viết tắt là"Intermediate Language", hay "IL") tương tự như ý tưởng về mã Java byte, nó là một ngôn ngữ cấp thấp với những cú pháp đơn giản (dựa trên cơ sở mã số hơn là text), chính điều này sẽ làm cho quá trình dịch sang mã máy nhanh hơn. Hiểu kĩ các cú pháp này sẽ mang lại những lợi ích đáng kể. Độc lập nền Trước tiên, nó có nghĩa là các file chứa mã lệnh có thể chạy trên bất kì nền nào, vào thời gian chạy trình biên dịch cuối sẽ hoạt động và mã có thể chạy trên một nền cụ thể. Nói cách khác việc dịch mã nguồn sang Intermediate Language cho phép độc lập nền trong .NET, nó giống như cách dịch mã nguồn sang Java byte code cung cấp sự độc lập nền trong Java. Bạn cũng nên biết rằng sự độc lập nền của .NET chỉ là trên lí thuyết bởi vì tại thời điểm này, .NET chỉ có sẵn trong Windows. Tuy nhiên việc chuyển .NET sang những nền khác đang được khảo sát tỉ mỉ (xem ví dụ Mono project, một sự cố gắng tạo một thực thi mã nguồn mở trong .NET, tại địa chỉ http://www.go-mono.com/). Sự cải tiến trong thực thi Mặc dù chúng ta đã so sánh với Jave, IL thật sự có một chút khả quan hơn Java. IL luôn là trình biên dịch Just-In-Time, ngược lại Java byte code thì thường là thông dịch. Một trong những bất lợi của Java là vào lúc thực thi quá trình dịch từ java byte code sang mã máy tốn nhiều tài nguyên. Thay vì phải dịch toàn bộ ứng dụng một lần, trình biên dịch JIT sẽ biên dịch từng phần mã khi nó được gọi. Khi mã được dịch rồi, mã kết quả sẽ được giữ lại cho tới khi thoát khỏi ứng dụng, chính vì thế nó không phải biên dịch lại trong lần chạy kế tiếp. Microsoft quả quyết rằng cách xử lí này có hiệu lực cao hơn là dịch toàn bộ ứng dụng, bởi vì có trường hợp một khối lượng lớn mã của ứng dụng không bao giờ được sử dụng trong thời gian chạy. Khi sử dụng trình biên dịch JIT , các đoạn mã này sẽ không bao giờ được dịch. Chính vì thế chúng ta hi vọng rằng mã IL sẽ thực thi nhanh như là mã máy. Microsof cam kết chúng ta sẽ có một thay đổi lớn trong thực thi. Lời lí giải là, là lần dịch cuối cùng trong thời gian chạy, trình biên dịch JIT sẽ biết chính xác loại vi xử lí mà chương trình sẽ chạy. Có nghĩa là nó có thể tối ưu mã thi hành cuối cùng bằng cách tham chiếu đến các đặc trưng của từng các bộ lệnh ứng với các loại vi xử lí đó. Các trình biên dịch truyền thống đều có tối ưu mã, nhưng chúng chỉ có thể tối ưu độc lập không quan tâm đến loại vi xử lý mà chương trình sẽ chạy. Bởi vì trình biên dịch truyền thống biên dịch toàn bộ ứng dụng sang mã máy trước khi thực thi. Có nghĩa là trình biên dịch không hề biết loại vi xử lí mà chương trình sẽ được chạy, chẳng hạn nó có thể là một vi xử lí tương thích x86 hoặc một vi xử lí Alpha. Visual Studio 6, tối ưu cho cho một máy tương thích Pentium, bởi vậy mã mà nó sinh ra không đem lại lợi ích gì đối với các đặc trưng phần cứng của vi xử lí Pentium III. Trong khi đó, trình biên dịch JIT có thể thực hiện tối ưu giống như Visual Studio 6, ngoài ra nó còn có thể tối ưu cho các loại vi xử lí cụ thể mà mã chương trình sẽ chạy. Tương hoạt giữa các ngôn ngữ Chúng ta đã biết cách thức IL cho phép độc lập nền, trình biên dịch JIT có thể cải thiện quá trình thực thi. Tuy nhiên, IL cũng làm cho tương hoạt giữa các ngôn ngữ trở nên dễ dàng hơn. Bạn có thể biên dịch IL từ một ngôn, và mã này sau đó có thể tương hoạt với IL được biên dịch bởi một ngôn ngữ khác. Bây giờ chắc bạn đang tự hỏi rằng những ngôn ngữ nào có thể tương tác với C# trong .NET, hãy xem qua các ngôn ngữ biết .NET phổ biến sau. VB.NET Visual Basic đã được tân trang lại để có thể tương thích với công nghệ .NET. Từ việc phát triển Visual Basic trong những năm gần đây cho thấy rằng trong các phiên bản trước, Visual Basic 6, nó không tương thích với lập trình .NET. Ví dụ, nó đặt nặng vấn đề tích hợp COM, và nó chỉ đưa ra các sự kiện để phát triển, hầu hết mã nền không có sẵn trong mã nguồn. Không những thế, nó không thực sự hỗ trợ tính thừa kế và các kiểu dữ liệu chuẩn của Visual Basic không tương thích với .NET. Visual Basic đang được hoàn thiện trong Visual Basic .NET, cũng đừng ngạc nhiên khi sự thay đổi này xảy ra trên một diện rộng. Về phương diện thực hành bạn có thể xem VB.NET như là một ngôn ngữ mới. Mã VB 6 không không thể được biên dịch trong như mã VB.NET. Sự chuyển đổi từ lập trình VB 6 sang VB.NET yêu cầu một sự thay đổi lớn về mã. Tuy nhiên hầu hết các sự thay đổi này có thể được thực hiện một cách tự động bởi Visual Studio .NET (sự cải tiến của VS cho việc sử dụng .NET). Nếu bạn cố gắng đọc một đề án VB 6 trong Visual Studio .NET, nó sẽ cải tiến đề án của bạn, có nghĩa là nó sẽ viết lại mã nguồn VB 6 thành mã nguồn VB.NET. Điều đó có nghĩa là việc này sẽ gặp rắc rối khi bạn cắt ngang, bạn sẽ phải kiểm tra lại mã VB.NET mới để chắc rằng đề án của bạn vẫn chạy đúng. Một hiệu ứng phụ là không còn khả năng biên dịch .NET sang mã thực thi. VB.NET chỉ biên dịch sang IL, giống như C#. Nếu như bạn muốn tiếp tục mã hóa trong VB 6, bạn có thể làm như vậy, nhưng khi mã thực thi quá dài nó sẽ lờ đi .NET Framework, và bạn cần phải giữ lại Visual Studio 6 đã cài đồng thời phải hoàn toàn tin vào môi trường phát triển trong Visual Studio. Managed C++ Vào lúc đó trong Visual C++ 6, C++ đã có một khối lượng lớn các mở rộng của Microsoft trong Windows. Với Visual C++ .NET, các mở rộng này được tăng thêm cho việc hỗ trợ .NET framework. Có nghĩa là mã nguồn C++ sẽ vẫn tiếp tục được dịch sang mã máy không có gì khác biệt. Cũng có nghĩa là nó sẽ chạy độc lập trong môi trường .NET. Nếu bạn không muốn mã C++ của bạn chạy trong môi trường .NET Framework, bạn có thể đơn giãn đặt dòng lệnh sau vào đầu mã nguồn của bạn: #using <mscorlib.dll> Bạn cũng có thể bỏ qua cờ /clr trong trình biên dịch, cờ này cho biết rằng bạn muốn biên dịch sang mã có quản, và nó sẽ phát ra IL thay vì mã máy. Có một điều thú vị trong C++ khi bạn biên dịch sang mã có quản, trình biên dịch có thể phát ra các IL có nhúng các mã máy. Điều này có nghĩa là bạn có thể pha trộn kiểu có quản và kiểu không quản trong mã C++. Bằng cách mã C+ +: class MyClass { Định nghĩa cho một lớp trong C++ , trong khi đó mã: __gc class MyClass { sẽ cho bạn một lớp có quản, giống như việc bạn viết một lớp trong C# hay VB.NET. Thật vậy, một thuận lợi của managed C++ so với C# là bạn có thể gọi các lớp không quản C++ từ mã có quản C++ bỏ qua tương thích COM. Trình biên dịch sẽ phát ra một lỗi nếu bạn cố gắng dùng những đặc trưng mà mã có quản của .NET không hỗ trợ trong (ví dụ, khuôn mẫu hay đa thừa kế). Bạn cũng sẽ nhận ra rằng bạn sẽ phải dùng các đặc trưng không thuần C++ (chẳng hạn từ khoá __gc trong ví dụ trên) khi sử dụng các lớp có quản. Bởi vì trong VC++ cho phép giải phóng bộ nhớ thủ công dưới dạng một con trỏ, trình biên dịch C++ không thể phát ra mã cho kiểu bộ nhớ an toàn CLR. Nếu ứng dụng của bạn thật sự cần phải nhận dạng kiểu bộ nhớ an toàn CLR, bạn cần phải viết mã nguồn trong các ngôn ngữ khác (như C# hay VB.NET). J++ and J# J++ vẫn được hỗ trợ cho chỉ vì mục đích tương thích trước đây. Microsoft không còn phát triển bất kì nền tảng nào hỗ trợ việc biện dịch sang máy Java ảo. Thay vì đó, Microsoft phát triển hai công nghệ tách biệt Java/J++ phát triển bên dưới ngọn cờ JUMP (Java User Migration Path) và "JUMP trong .NET". Công nghệ đầu tiên là Visual J#. Về bản chất nó được thêm vào Visual Studio.NET để cho phép bạn viết và biên dịch mã J++. Sự khác biệt đó là thay vì biên dịch sang một Java Virtual Machine, J# sẽ biên dịch sang IL, vì vậy nó sẽ hoạt động như là một ngôn ngữ của .NET. Ngừơi dùng J# sẽ có thể được hưởng các thuận lợi của các đặc tính của VS.NET. Microsoft tin răng người dùng J++ sẽ nhanh chóng nhận ra điều đó nếu họ thích làm việc trong với .NET. Sự lựa chọn thứ hai là công cụ tự động hỗ trợ việc chuyển mã J++ sang mã C#. Sự giống nhau giữa J++ và C# làm cho việc chuyển đổi này trở nên dễ dàng hơn. Không giống như J# cũng không như các công cụ chuyển đổi ngôn ngữ có sẵn như là một phần của .NET hay trong Visual Studio. NET, thay vì thế nó được cung cấp riêng. Để biết thêm thông tin liên hệ http://msdn.microsoft.com/visualj/. Scripting languages Scripting languages đâu đó vẫn còn tồn tại, dù rằng về mặt tổng quát, tầm quan trọng của chúng đã giảm sút cùng với sự ra đời của .NET. JScript, được cải tiến lên JScript.NET. ASP.NET (một cải tiến từ ASP dành cho .NET, giải thích sau) các trang có thể được viết bằng JScript.NET, và bây giờ nó có thể chạy trên JScript.NET như là một ngôn ngữ biên dịch hơn là một ngôn ngữ thông dịch và nó có thể tạo ra các mã kiểu mã JScript.NET mạnh hơn. Với ASP.NET không có lí do gì để dùng scripting languages trên cac trang web server-side. VBA vẫn được sử dụng như là một ngôn ngữ cho Microsoft Office và Visual Studio macros. COM and COM+ COM và COM+ không là công nghệ chính của .NET, bởi vì các thành phần cơ bản của chúng không thể dịch sang IL (mặc dù vẫn có thể làm điều đó khi tổ chức thành phần COM bằng mã C++). Tuy nhiên COM+ vẫn còn là một công cụ quan trọng, từ khi đặc tính của nó được nhân lên trong .NET. Ngoài ra, thành phần COM vẫn còn làm việc và .NET kết hợp chặc chẽ các đặc trưng tương hoạt COM để mã có quản có thể gọi đến COM và ngược lại (sẽ được bàn thêm ở chương 17). Assemblies Một assembly là một đơn vị luận lí chứa mã đã được biên dịch sang .NET. Chúng ta sẽ bàn kĩ về các assemblie trong chương 8, ở đây chúng ta sẽ nói sơ về nó. Một assembly là một tự mô tả đầy đủ, và nó giống một đơn vị luận lí hơn là một đơn vị vật lí, điều đó có nghĩa là nó có thể chứa trong nhiều file (thật vậy các assemblie động được lưu trong bộ nhớ không phải trong file). Nếu một assembly được lưu trong nhiều file, thì sẽ có một file chính chứa các con trỏ và các mô tả về các file khác của assembly. Chú ý rằng, câu trúc assembly được dùng chung cho cả mã thi hành và mã thư viện. Sự khác biệt duy nhất là assembly thi hành chứa lối vào chương trình chính trong khi assembly thư viện thì không có. Một điểm quan trọng trong các assembly là chúng chứa metadata dùng để mô tả các kiểu và phương thức được định nghĩa trong mã tương ứng. Một assembly, tất nhiên cũng chứ assembly metadata dùng để mô tả chính assembly đó. Assembly metadata này, chứa một vùng đựơc hiểu như là manifest, cho phép kiểm tra phiên bản và tình trạng của assembly. ildasm, một tiện ích có sẵn của Windows, có thể dùng để nghiên cứu nội dung của một assembly, bao gồm manifest metadata. Chúng ta sẽ lấy vi dụ về ildasm trong chương 8. Thật vậy một assembly chứa metadata của chương trình nghĩa là các ứng dụng hoặc các assembly khác có thể gọi mã trong môt assembly mà không cần tham chiếu đến Registry, hoặc một dữ liệu nguồn khác,. Một điểm quan trọng trong cách làm của COM cũ, các GUID của các thành phần và giao diện interfaces không thể đạt được từ Registry. Việc dàn trải dự liệu thành 3 định vị khác nhau đồng nghĩa với việc tạo ra mối nguy hiểm trong đồng bộ hoá, nó ngăn không cho các thành phần khác sử dụng. Với assemblies, sẽ không còn những mối nguy hiểm như vậy, bởi vì tất các các metadata được lưu trong bộ lệnh thi hành của chương trình. Chú ý rằng dù cho các assemblie được lưu thành một vài file, chúng vẫn không gây vấn đề gì về đồng bộ hoá dữ liệu. Đó là vì nhờ vào file assembly chính, file này chứa đường dẫn, các thông tin chi tiết, mã băm, và nội dung của các file khác, điều đó có nghĩa là nếu một file bị thay thế, hay bị phá hoại, nó sẽ được tìm ra và sẽ không cho load. Assemblies bao gồm 2 loại: các shared và private assembly. Private Assemblies Private assemblies là kiểu đơn giản nhất. Nó chứa phần mềm và chỉ được dùng cho phần mềm đó. Với phần mô tả này bạn có thể chứa đựng các private assemblie hòng cung cấp cho một ứng dụng kiểu thực thi và một số thư viện, các thư viện này chứa mã sẽ được thi hành bởi ứng dụng đó. Hệ thống đảm bảo rằng private assemblies sẽ không được dùng bởi phần mềm khác, bởi vì một ứng dụng chỉ có thể load private assemblies trong cùng folder với chương trình chính hoặc là trong một thư mục con của nó. Chúng ta không thể tin cậy rằng tất cả các phần mềm luôn được cài đặt trong thư mục của nó, nghĩa là sẽ không bao giờ có chuyện một gói phần mềm ghi đè, sửa chữa hoặc vô tình load một private assemblies dành riền cho một gói khác. Vậy làm sao để các Private assemblie chỉ được dùng bởi gói phần mềm mà nó mô tả? Cần có một cơ chế bảo vệ, sao cho khi một sản phẩm thương mại khác cài đè lên một phiên bản assembly mới (chưa kể đến các chương trình đựơc thiết kế để phá hoại), thì sẽ không có chuyện tranh chấp tên. Nếu có sự trùng tên trong các assembly, đều đó không quan trọng và các ứng dụng chỉ có thể nhìn thấy một bộ các assembly. Bởi vì một private assembly là một tự định nghĩa trọn vẹn, tiến trình xử lí cực kì đơn giản. Bạn đơn giản thay thế các file thích hợp vào thư mục thíhc hợp trong file hệ thống (Không cần phải đăng kí trong registry). Tiến trình này được gọi là zero impact (xcopy) installation. Shared Assemblies Shared assemblies được dành cho cácc thư viện công cộng có thể dùng cho bất kì ứng dụng nào. Bởi vì bất kì ứng dụng nào cũng có thể truy xuất một shared assembly, cần phải có các cơ chế để bảo vệ các rủi ro sau: • Tranh chấp tên, khi một công ty tạo ra các shared assembly trùng tên với các shared assembly sẵn có của bạn. Về mặt lí thuyết mã của bạn có thể truy xuất vào cả hai assembly này song đây có thể là một vấn đề phức tạp. • Lỗi của một assembly có thể bị ghi đè bởi một phiên bản khác của cùng same assembly - một phiên bản mới không tương thích với những gì sẵn có. Giải pháp cho những vấn đề trên là đặt các shared assembly trong một cây thư mục đặt biệt của hệ thống, có thể xem như là assembly cache toàn cục. Không giống như các private assembly, nó không đơn giản là copy assembly sang một thư mục thích hợp - nó cần được cài đặt rõ ràng vào cache. Tiến trình này có thể được thực thi bởi một số tiện ích của .NET, bao gồm luôn quá trình kiểm tra trên assembly, tương tự như cài đặt một thư mục trong assembly cache để đảm bảo tính toàn vẹn của assembly. Để tránh tranh chấp tên, shared assemblies đưa ra một được quản lí dựa trên một khóa mật mã chính. Tên này được gọi là strong name, được bảo đảm về tính độc nhất, và phải được trích dẫn bởi ứng dụng muốn tham chiếu đến một shared assembly. Vấn đề về tương thích với lỗi do ghi đè một assembly được đánh địa chỉ theo thông tín phiên bản trong assembly manifest, và cho phép cài đặt song song. Reflection Từ khi các assembly được lưu dưới dạng metadata, bao gồm chi tiết về tất cả các kiểu và thành viên của những kiểu này, thì nó có thể được truy xuất được các metadata programmatically. Để biết chi tiết hơn, xin hãy xem reflection - mã quả có thể xem xét các mã quản khác, hoặc xem xét chính nó, để nhận ra các thông tin về mã. Bạn có thể dùng các attribute, để có thể sử dụng phương thức trong lúc chạy điều này tốt hơn là trong lúc biên dịch. Tìm hiểu về Intermediate Language Như chúng ta đã biết, Intermediate Language hoạt động như là bản chất của .NET Framework. Là lập trình viên C#, chúng ta nên biết rằng mã C# sẽ luôn được dịch sang Intermediate Language trước khi nó được thực thi (thật vậy, trình biên dịch C# chỉ dịch sang mã có quản). Chúng ta hãy cùng khám phá các tính năng chính của IL, bất kì ngôn ngữ nào hướng .NET cũng sẽ hỗ trợ các đặc tính chính của IL. Sau đây là những đặc tính chính của Intermediate Language: • Hướng đối tượng và dùng interfaces • Sự tách biệt giữa kiểu giá trị và kiểu tham chiếu • Định kiểu mạnh • Quản lỗi thông qua các ngoại lệ • Sự dụng các thuộc tính Bây giờ chúng ta sẽ cùng khám phá các đặc tính trên. Hỗ trợ hướng đối tượng và dùng giao diện Ngôn ngữ độc lập nền của .NET có một vài giới hạn riêng. Cụ thể trong lúc thực thi IL chắc chắn sẽ thực thi một cách thức lập trình riêng, và các ngôn ngữ khác phải chú ý đến việc tương thích với cách thức lập trình này. IL đã được Microsoft phát triển như là một ngôn ngữ hướng đối tượng cổ điển hỗ trợ đầy đủ thừa kế đơn giữa các lớp. Bên cạnh lập trình hướng đối tượng đơn, Intermediate Language còn nêu ra ý tưởng về interfaces (giao diện), cái đã được tích hợp trong Windows với giao diện COM. .NET nó không giống như giao diện COM; chúng không cần phải hỗ trợ bất kì một kiến trúc COM nào (ví dụ, chúng không xuất phát từ IUnknown, và chúng cũng không liên quan gì đến các GUID). Tuy nhiên chúng có thể dùng chung các giao diện COM. Hướng đối tượng và thực thi chéo ngôn ngữ Bây chúng ta sẽ tìm hiểu về hoạt động của .NET nghĩa là hoạt động biên dịch sang mã Intermediate Language, điều đó nói lên rằng bạn cần phải lập trình theo cách thức hướng đối tượng truyền thống. Không những thế chúng còn cung cấp cho chúng ta khả năng chuyển giao ngôn ngữ. Sau cùng, C++ và Java cả hai đều dùng những biến thể của hướng đối tượng, dù vậy chúng vẫn còn được quan tâm để có thể thực thi chéo. Chúng ta cần tìm hiểu một chút về thực thi chéo ngôn ngữ. Trước tiên chúng ta cần hiểu chính xác thực thi ngôn ngữ chéo là gì. Sau cùng, COM cho phép các thành phần được viết bởi các ngôn ngữ khác nhau có thể thực thi chéo. COM, là một nhị phân chuẩn, cho phép các thành phần có thể hiểu nhau và có thể gọi các phương thức cũng như thuộc tính lẫn nhau mà không cần quan tâm đến ngôn ngữ đã tạo ra chúng. Để làm được điều đó mỗi đối tượng phải có khả năng giao tiếp với thời gian chạy của COM, và phải có khả năng truy cập thông qua một giao diện. Các thành phần chỉ có thể giao tiếp với nhau trong thời gian chạy COM. Dù rằng các thành phần của COM có thể giao tiếp với nhau bất chấp ngôn ngữ đã tạo ra chúng, tuy nhiên COM không hỗ trợ hoạt động thừa kế, chính vì thế nó đã đánh mất các thuận lợi của lập trình hướng đối tượng. Một vấn đề xảy ra khi bẫy lỗi là các thành thành phần phải được bẫy lỗi trong ngôn ngữ đã tạo chúng, và bạn không thể bẫy lỗi từng bước trên các ngôn ngữ khác nhau. Vậy thực thi chéo ngôn ngữ được hiểu như là các lớp được tạo ra trong một ngôn ngữ có thể giao tiếp lẫn nhau với các lớp được tạo ra trong các ngôn ngữ khác. Cụ thể là: • Một lớp được tạo ra trong một ngôn ngữ có thể thừa kế từ một lớp được viết trong một ngôn ngữ khác. • Một lớp có thể chứa thể hiện của một lớp khác không quan tâm đến ngôn ngữ đã tạo ra hai lớp đó. • Một đối tượng có thể gọi trực tiếp phương thức của một đối tượng khác được viết bởi một ngôn ngữ khác. • Các đối tượng (hoặc các tham chiếu đến các đối tượng) có thể được truyền qua lại giữa các hàm • Bạn có khả năng bẫy lỗi từng bước chương trình nguồn giữa các ngôn khác nhau Thật bất ngờ về những gì mà .NET và thực thi ngôn ngữ chéo đã làm được. Tiện ích bẫy lỗi từng được giới thiệu như là khả năng của Visual Studio .NET IDE hơn là CLR. Sự khác biệt giữa kiểu dữ liệu giá trị và kiểu dữ liệu tham chiếu Như bất kì ngôn ngữ lập trình nào, IL cung cấp một số tiền định nghĩa về các kiểu dữ liệu nguyên thủy. Một đặc trưng của Intermediate Language là phân biệt rạch ròi giữa kiểu dữ liệu giá trị và kiểu dữ liệu tham chiếu. Kiểu giá trị là các biến được dùng để lưu trực tiếp giá trị, trong khi đó kiểu tham chiếu là các biến chứa địa chỉ của dữ liệu. Trong C++, kiểu tham chiếu có thể coi như là một con trỏ, trong khi đó ở Visual Basic, kiểu tham chiếu có thể coi là các đối tượng, trong VB 6 luôn truy cập thông qua tham chiếu. Intermediate Language cũng chỉ rõ về cách thức lưu trữ dữ liệu: ví như một kiểu tham chiếu luôn được lưu trong vùng managed heap của bộ nhớ, trong khi đó kiểu giá trị lại được lưu trong stack (tuy nhiên nếu kiểu dữ liệu được khai báo là một trường của kiểu tham chiếu, chúng vẫn được lưu ở heap). Chúng ta sẽ bàn về stack và heap trong chương 3. Định kiểu mạnh Một điểm mạnh trong IL là định kiểu mạnh. Nghĩa là tất cả các biếu đều được đánh dấu rõ ràng và chuyên biệt về kiểu dữ liệu (IL không còn hỗ trợ kiễu Variant cho Visual Basic và ngôn ngữ kịch bản). Cụ thể là IL không cho phép các hoạt động trả về các kiểu dữ liệu không rõ ràng. Trong trường hợp là người phát triển VB có lẽ bạn sẽ rất lo lắng về kiểu, bởi vì khi dùng kiểu dữ liệu Variant VB tự động ép kiểu giúp bạn. Còn là người phát triển C++, có lẽ bạn sẽ dùng các casting pointer giữa các kiểu. Lập trình theo cách này có thể là một lập trình mạnh, tuy nhiên nó phá vỡ tính an toàn kiểu. Từ bây giờ, nó chỉ còn hỗ trợ trong những trường hợp đặc biệt trong một số ngôn ngữ có khả năng biên dịch sang mã có quản. Thật vậy, các con trỏ (không phải là tham chiếu) chỉ còn cho phép trong các khối mã đặc biệt trong C#, trong VB không có (mặc dù nó cho phép trong C++). Nếu dùng con trỏ trong mã nguồn nó sẽ không chuyển thành mã có quản và sẽ không được kiểm tra bởi CLR. Bạn cũng nên biết rằng trong một số ngôn ngữ biết .NET, chẳng hạn như VB.NET, vẫn cho phép mơ hồ kiểu, tuy nhiên chỉ để có thể làm được như thể làm được như vậy thì trình biên dịch đã xác định kiểu bảo vệ kiểu trước khi phát ra IL. Mặc dù, kiểu bảo vệ lúc đầu có thể sinh ra nhiều cản trở trong lập trình nhưng trong nhiều trường hợp kiểu bảo vệ sẽ mang lại nhiều lợi ích to lớn trong các dịch vụ được cung cấp bởi .NET. Chẳng hạn các dịch vụ sau: • Language Interoperability • Garbage Collection • Security • Application Domains Hãy tìm hiểu xem tại sao kiểu dữ liệu mạnh lại là một trong những đặc tính quan trọng của .NET. Tầm quan trọng của Strong Data Typing đối với Language Interoperability Một khía cạnh quan trong của strong data typing là nếu một lớp xuất thân hoặc chứa một lớp khác thì nó cần phải biết tất cả các kiểu dùng trong các lớp đó. Thật vậy, nó đã từng các chướng ngại lớn trong việc thực thi ngôn ngữ chéo ở các hệ thống không hỗ trợ trước đấy. Thông tin này không có sẵn trong các file thi hành và DLL chuẩn. Giả sử rằng một phương thức trong VB.NET được định nghĩa là sẽ trả về một Integer, một trong những kiểu dữ liệu chuẩn của VB.NET. C# không có kiểu dữ liệu có tên như vậy. Chúng ta chỉ có thể dùng phương thức này để trả về một kiểu của C# nết trình biên dịch biết cách ánh xạ kiểu VB.NET's Integer đến một trong những kiểu được định nghĩa trong C#. Vậy .NET đã làm việc đó như thế nào? Common Type System (CTS) Vấn đề về kiểu dữ liệu này được .NET giải quyết bằng cách dùng Common Type System (CTS). CTS định nghĩa các kiểu dữ liệu tiền định và có sẵn trong IL, vì thế tất các các ngôn ngữ hướng .NET framework sẽ sinh ra mã cuối trên cơ sở các kiểu dữ liệu này. Trong ví dụ trên, VB.NET's Integer thực tế là một 32-bit signed integer, được ánh xạ từ kiểu Int32 trong IL. Nó phải được biên dịch thành mã IL. Bởi vì trình biên dịch C# cũng biết kiểu dữ liệu này nên không có vấn đề gì cả. Ở cấp mã nguồn, C# gọi Int32 là int, vì vậy khi biên dịch hàm VB.NET đơn giản trả về một kiểu int. CTS không chỉ đơn thuần là các kiểu dữ liệu đơn giản, doesn't merely specify primitive data types, mà nó còn cho phép chúng ta tự định nghĩa kiểu của riêng mình. Các kiểu được trình bày trong bảng dưới đây: Kiểu Giải thích Type Kiểu cơ bản dùng để mô tả các kiểu khác Kiểu Giải thích Value Type Kiểu cơ bản dùng để mô tả các kiểu giá trị. Reference Types Kiểu cơ bản dùng để môt tả các kiểu tham trị. Built-in Value Types Bao gồm các kiểu giá trị nguyên thủy chuẩn, như các kiểu số, kiểu luận lí, kiểu kí tự. Enumerations Bộ các giá trị liệt kêSets of enumerated values. User-defined Value Types Kiểu được định nghĩa trong mã nguồn như là một kiểu giá trị. Trong C# nó có là struct. Interface Types Các giao diện. Pointer Types Các con trỏ. Self-describing Types Kiểu dữ liệu có quản. Arrays Các kiểu chứa mảng các đối tượng. Class Types Các kiểu tự mô tả nhưng không phải là mảng. Delegates Kiểu được thiết kế để tham chiếu đến các phương thức. User-defined Reference Types Kiểu được định nghĩa trong mã nguồn và được lưu như là kiểu tham chiếu. Trong C#, nó có nghĩa là một lớp. Boxed Value Types Một kiểu giá trị được bọc thành một kiểu tham chiếu vì thế nó có thể được lưu trong heap. Chúng ta không thể liệt kê tât cả các kiểu giá trị ở đây, bởi vì chúng sẽ được bàn kĩ trong chương 2. Trong C#, mỗi kiểu có sẵn được nhận dạng bởi trình biên dịch ánh xạ đến một kiểu IL cài sẵn. Điều này cũng đúng cho cả VB.NET. Common Language Specification (CLS) Common Language Specification hoạt động cùng với Common Type System để bảo đảm thực thi ngôn ngữ chéo. CLS là một bộ con chuẩn mà tất cả các trình biên dịch hướng .NET đều phải hỗ trợ. Đều đó có nghĩa là các trình biên dịch đều sẽ hỗ trợ tất cả những gì được định nghĩa trong CLS. Chú ý: Các bạn có thể viết các mã non-CLS, tuy nhiên những mã này không đảm bảo việc thực thi ngôn ngữ chéo. IL là một ngôn ngữ phân biệt loại kí tự. Những nhà phát triển khi làm việc với các ngôn ngữ phân biệt loại kí tự có khả năng tạo nên sự mềm dẻo khi đặt tên biến. VB.NET, lại không phải là ngôn ngữ phân biệt loại kí tự. CLS xử lí việc này bằng các ra hiệu cho CLS rằng mã không cho phép hai tên chỉ khác nhau về mặt loại kí tự. Bởi vậy, mã VB.NET có thể hoạt động trong CLS. CLS hoạt động theo hai định hướng. Trước tiên nó là một trình biên dịch riêng không hỗ trợ đây đủ các đặc trưng của .NET điều này khuyến khích sự phát triển của các ngôn biết .NET khác. Thứ hai, nó bảo đảm rằng nếu bạn hạn chế các lớp của bạn trong những đặc tính của CLS, thì nó bảo đảm rằng các mã dùng trong những ngôn ngữ khác có thể dùng các lớp này. Nét đẹp của ý tưởng này là việc giới hạn trong những đặc tính của CLS chỉ nên áp dụng cho những thành phần public và protected của các lớp và chỉ dùng cho các lớp public. Trong các thành phần thực thi của các lớp của bạn, bạn có thể viết các mã non-CLS nếu muốn, bởi các ngôn ngữ khác không bao giờ có thể truy cập vào những phần này. Chúng ta không đi vào chi tiết của CLS ở đây. Về mặt tổng quát CLS không ảnh hưởng nhiều đến mã C# của bạn vì nó không có nhiều đặc tính khác CLS. Garbage Collection Garbage collector là một thành phần quản lí bộ nhớ của .NET, nó là một đáp án cho việc thu hồi bộ nhớ của các chương trình thực thi. Từ trước đến giờ có hai công nghệ được sử dụng cho việc huỷ bộ nhớ trong Windows, những tiến trình này được yêu cầu từ hệ thống: • Ứng dụng tự làm điều này một cách thủ công. • Tạo một bộ đếm tham chiếu đến đối tượng. Việc mã ứng dụng chịu trách nhiệm thu hồi vùng nhớ là một cộng nghệ dùng ở mức thấp, hoặc những ngôn ngữ thực thi cấp cao như C++. Nó mang tính hiệu quả cao, nó có thuận lợi là tài nguyên sẽ được giải phóng ngay khi không còn cần thiết. Một bất lợi lớn là nó thường xuyên sinh lỗi. Mã nguồn luôn phải chỉ rõ cho hệ thống biết khi nó không cần dùng bộ nhớ đó nữa . Dễ dàng nhìn ra rằng kết quả có thể dẫn đến rò rỉ bộ nhớ. Mặc dù các môi trường phát triển hiện đại có cung cấp một số công cụ giúp đỡ trong việc phát hiện sự rò rỉ bộ nhớ, nhưng rất khó theo vết, bởi vì nó không có hiệu lực cho đến khi có một khối lượng lớn bộ nhớ bị rò rỉ: Windows buộc phải ngưng các tiến trình xử lí. Tại thời điểm này máy tính chậm đi thấy rõ một sự trả giá cho các yêu cầu bộ nhớ. Việc duy trì một bộ đếm các tham chiếu là một ân huệ trong COM. Ý tưởng này cho rằng mỗi thành phần COM chứa một bộ đếm xem có bao nhiêu ứng dụng đang chứa tham chiếu đến nó. Khi bộ đếm này xuống đến zero, Thành phần có thể tự hủy nó và giải phóng vùng nhớ cũng như các tài nguyên tương ứng. Vấn đề ở đây là nó vẫn lệ thuộc vào sự thông báo của các ứng dụng khi chúng không còn dùng đến các thành phần này nữa. Trong một vài trường hợp, nó có khả năng tạo ra một vấn đề nghiêm trọng hơn là sự kiểu rò rỉ C++ thông thường, bởi vì đối tượng COM có thể nằm trong một tiến trình của riêng nó, điều này có nghĩa là nó sẽ không bao giờ được hủy bởi hệ thống (chí ít trong rò rỉ kiểu C++, hệ thống có thể giành lại toàn bộ vùng nhớ khi tiến trình kết thúc). Thời gian chạy .NET hoàn toàn phụ thuộc vào garbage collector instead. Đây là một chương trình hỗ trợ việc thu dọn bộ nhớ. Trong ý tưởng này tất cả các yêu cầu bộ nhớ đều được cấp phát trên heap (điều này đúng cho tất cả các ngôn ngữ, trong .NET, CLR chứa nó trong vùng heap có quản cho tất cả các ứng dụng .NET sử dụng). Thỉnh thoảng .NET sẽ kiểm tra xem vùng heap có quản có trở nên đầy chưa để nó tiến hành thu dọn, và nó gọi đây là tiến trình thu gôm rác. Trình thu dọn rác sẽ kiểm tra các tham chiếu từ mã của bạn, ví dụ các tham chiếu từ mã của bạn đến các đối tượng được lưu trên heap được nhận dạng, nó có nghĩa là đối tượng đó vẫn còn tham chiếu, các đối tượng không còn tham chiếu nữa sẽ bị huỷ. Trình thu gom rác hoạt động trong .NET bởi vì Intermediate Language được thiết kế để làm điều đó. Phải tuân thủ các nguyên tắc sau, thứ nhất bạn chỉ có thể tham chiếu đến một đối tượng có sẵn bằng cách sao chép cac tham chiếu có sẵn, thứ hai Intermediate Language bảo vệ kiểu, điều này có nghĩa là các tham chiếu đến các đối tượng có sẵn luôn chứa đựng thông tín nhận dạng chính xác của đối tượng đó. C++ Có thể không sử dụng trình thu gom một cách máy móc, bởi vì C++ cho phép các con trỏ tự do ép kiểu. Một điều đặc biệt quản trọng là tính không định trước của trình thu gom rác. Hay nói cách khác, bạn không thể bảo đảm được khi nào trình thu gôm rác sẽ được gọi; nó sẽ được gọi khi CLR cảm thấy cần (nếu bạn không thực hiện lời gọi tường minh). Bảo mật .NET thật sự xuất sắc trong việc bổ sung cơ chế bảo mật của Windows bởi vì nó hỗ trợ code-based security trong khi đó Windows chỉ thật sự hỗ trợ Role-based security. Role-based security là cơ sở để xác định tài khoản của các tiến trình đang thực thi, hay nói cách khác ai sở hữu các tiến trình đang thực thi. Code-based security là một cơ chế khác để xác định xem những mã nào và có bao nhiêu mã là đáng tin. Cảm ơn sự bảo vệ kiểu mạnh của IL, vì nhờ nó mà CLR có thể kiểm tra mã trước khi chạy trong một chế độ bảo vệ được đưa ra.NET cũng hỗ trợ một cơ chế những mã nào được phép phơi tra trong một cơ chế bảo mật nào đó. Một điều quan trọng là code-based security có thể làm giảm nguy cơ liên quan đến việc chạy các đoạn mã có xuất xứ không rõ ràng (chẳng hạn như mã mà bạn downloaded từ Internet). Một ví dụ, nếu mã được chạy dưới quyền administrator, nó có thể sử dụng code-based security để khai báo rằng mã không còn cho phép thực thi trong những kiểu mà quyền administrator hỗ trợ như: không thể đọc hoặc viết lên các biến môi trường, đọc hoặc viết lên registry, không truy cập vào các đặc trưng trong .NET. Security sẽ được bàn kĩ hơn trong chương 23. Application Domains Application domains là một cách tân quan trọng trong .NET và nó được thiết kế để có thể dễ dàng xử li các vấn đề khi chạy các ứng dụng cần sự biệt lập với các ứng dụng khác nhưng vẫn có thể thông tin với các ứng dụng khác. Một ví dụ cổ điển đó lá một ứng dụng web server application, nó phải phản hồi lại với một số lượng các yêu cấu từ các trình duyệt. Chắc chắn rằng sẽ tồn tại cùng lúc nhiều thành phần có khả năng phản hồi để phục vụ cho các yêu cầu đó. Trước thời .NET, sự lựa chọn giữa cho phép các thể hiện đó có thể dùng trong một tiến trình, cái mà sẽ mang lại sự rủi ro có thể làm giảm độ an toàn của trang web, hay là cho phép các thể hiện đó chạy trên các tiến trình biệt lập, cái mà sẽ mang lại sự gia tăng sự thực thi. Giờ đây, đó là sự biệt lập mã thông qua các tiến trình. Khi bạn kích khởi một ứng dụng mới, nó sẽ chạy trong ngữ cảnh của tiếnt trình. Các tiến trình Windows độc lập nhau thông qua vùng địa chỉ. Trong ý tưởng này mỗi tiến trình sẽ có sẵn 4 gigabytes bộ nhớ ảo để chữa dữ liệu và mã thực thi (4GB là dành cho hệ thống 32-bit; hệ thống 64-bit có thể nhiều hơn). Windows gián tiếp thực hiện cơ chê mở rộng để ánh xạ bộ nhớ ảo này với bộ nhớ vật lí thật hay đĩa. Mỗi tiến trình sẽ có sự ánh xạ khác nhau, sao cho các vùng nhớ vật lí thật sự không trùng lấp nhau. Nó được minh họa bởi sơ đồ sau: [...]... của C#, Viết một số đoạn code đơn giản, chương trình C# Chúng ta đã họ được nhiều nền tảng cơ bản trong C#, phong cách viết ngôn ngữ C#, tóm tắt các chủ đề các bạn cần phải nắm rõ như sau: • • Phạm vi của biến và các cấp độ truy cập Khai báo biến của các kiểu dữ liệu khác nhau • Điều khiển thi hành chương trình C# • Gọi và khai báo các lớp và các phương thức • Làm việc với mảng • Toán tử trong C# •... information, please refer to: http://www.macrobject.com Chương trình đầu tiên ! Chúng ta sẽ bắt đầu theo cách truyền thống là tạo một chương trình viết bằng C# rồi cho biên dịch và chạy thử nghiệm Việc phân tích chương trình con này sẽ dẫn dắt bạn vào những chức năng chủ chốt của ngôn ngữ C# Bạn có thể biên dịch chương trình này bằng cách khỏ vào chương trình soạn thảo văn bản đơn giản, Notepad chẳng hạn, rồi... chương trình hoàn chỉnh Để trả lời chúng ta làm việc với các class Lớp Như bạn đã biết , các class tạo nên một chương trình lớn trong C# , để biết thêm chúng ta sẽ được trình bày ở chương 3 toàn bộ về lập trình hướng đối tượng trong C# Tuy nhiên nó thực sự có khả năng viết một chương trình mà không sử dụng đến lớp, ở đây chúng ta chỉ cần một ít về lớp Chúng ta sẽ được trang bị cú pháp cơ bản để gọi... trình biên dịch dòng lệnh trong C# • Using System.Console để thực hiện I/O • Sử dụng chú thích trong C# và Visual Studio NET • Các định danh và từ khoá trong C# Cuối chương này bạn sẽ có đủ khả năng viết một chương trình đơn giản bằng C# mà bạn không cần phải biết sự kế thừa hay hướng đối tượng mà chúng tôi sẽ trình bày những phần này ở vài chương tới của quyển sách This document is created from a CHM... thi Thông thường các tiến trình sẽ hoạt động chung với nhau, bởi vậy cần phải có sự truyền thông giữa chúng Ví dụ như đâu đó một tiến trình gọi một thành phần COM khả thi, và bởi vì được yêu cầu chạy trong tiến trình của chúng Giống như cách mà COM vẫn làm Khi đó các tiến trình không thể dùng chung bộ nhớ, một tiến trình phức tạp được sử dụng để sao chép dữ liệu giữa các tiến trình Nó sẽ gây trở ngại... bản nền của C# FrameWork, để đi sau hơn trong ngôn ngữ C# bạn cần phải cần tìm hiểu thêm lập trình hướng đối tượng của C#, Đây là tính năng mạnh và quan trong bạn không thể bỏ qua, chương tới chúng ta sẽ được học về nó Lớp và Thừa kế: Chúng ta đã được xem cách sử dụng lớp trong chương 2 nhưng để nắm được mối liên hệ giữa các chương, chúng tôi sẽ tóm tắt một vài khái niệm về lớp Lớp trong C# được định... Language Runtime Chúng tôi cũng đã trình bày vai trò của các đặc tính sau trong NET trong quá trình biên dịch và thực thi: • • Các Assembly và thư viện lớp cơ sở của NET Các thành phần COM • Quá trình biên dịch JIT • Các Application domain • Garbage Collection Lưu đồi sau cho ta một cái nhìn về vài trò của các đặc tính này trong quá trình biên dịch và thực thi: Chúng tôi cũng đã trình bày những đặc trưng của... Explorer như bất cứ chương trình khả thi nào.Chạy chương trình như sau : csc First.cs Microsoft (R) Visual C# NET Compiler version 7.00.9466 for Microsoft (R) NET Framework version 1.0.3705 Copyright (C) Microsoft Corporation 2001 All rights reserved First This isn't at all like Java! Download First Nhưng trước tiên bạn nên biết trên C# cũng như trên các ngôn ngữ C khác chương trình được cấu thành bởi... thuận lợi khi sử dụng hằng trong chương trình của bạn : • Hằng làm cho chương trình đọc dễ dàng hơn, bằng cách thay thế những con số vô cảm bởi những tên mang đầy ý nghĩa hơn • Hằng làm cho dễ sữa chương trình hơn • Hằng làm cho việc tránh lỗi dễ dàng hơn, nếu bạn gán một trị khác cho một hằng đâu đó trong chương trình sau khi bạn đã gán giá trị cho hằng, thì trình biên dịch sẽ thông báo sai lầm Câu... khác, bao gồm C# Chúng tôi cũng đã chú thich cách mà định nghĩ kiểu mạnh có thể hỗ trợ tương hoạt ngôn ngữ chéo, cũng như các dịch vụ CLR chẳng hạn như trình thu gom rác và bảo mật Ở phần cuối của chương tôi đã nói về cách tạo các ứng dụng C# dựa trên các công nghệ của NET trong đó có ASP.NET Giờ đây chúng ta đã có cái nền, chương tới sẽ chỉ ra cách viết mã trong C# Chương 2: Cơ bản C# Tổng quan : . Giáo trình Lập trình với C# Chương 1 - Kiến trúc của C# và .NET Chương 2 - Căn bản C# Chương 3 - Hướng đối tượng trong C# Chương 4 - Những chủ đề tiến bộ trong C# Chương 5 - C# và. của .NET Framework. Là lập trình viên C#, chúng ta nên biết rằng mã C# sẽ luôn được dịch sang Intermediate Language trước khi nó được thực thi (thật vậy, trình biên dịch C# chỉ dịch sang mã có. liệt kê vắn tắt về các loại ứng dụng mà chúng ta có thể tạo ra trong C#. Mối quan hệ giữa C# và .NET C# là một ngôn ngữ lập trình mới, và được biết đến với hai lời chào: • Nó được thiết kế riêng