C# Tutorial
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
Table of Contents
C# Tutorial Objectives:
• Understand the scope of the .NET platform
• Examine the Common Language Runtime (CLR)
• Examine the Common Type System (CTS)
• Examine the Common Language Specification (CLS)
• Survey the core .NET Namespaces
• Understand the role of the Common Language Infrastructure (CLI)
• Understand the core of C#
• Learn about custom classes
• Learn constructors and finalizers
• Understand decision constructs and looping
• Learn C# modifiers, overloading, and exception handling
• View the pillars of OOP through C#
• Define and use abstract classes and interfaces
• Learn why and how to define nested types
Overview
The point of this first chapter is to provide a foundation for the remainder of the class, by illustrating the scope
of the .NET platform.
We begin by examining the core aspects of the .NET world, including the role of types, assemblies and
namespaces. We will also spend some time digging into the CLR to understand the key features of this runtime
and the related specifications.
The final aspect of this chapter is to survey a number of languages (and tools) which can be used to build managed
code, including VB, C# and C++/ CLI. With this foundation in place, you will have the proper mindset to build .
NET solutions using VB.
Remembering the World of COM
If you have been doing any programming for the Windows operating system, chances are COM has played an
important role.
COM aspires to the following goals:
Actually, .NET shares these goals. .NET just does it better.
COM Problems and .NET Solutions
Despite the widespread use of COM, this programming model had a number of issues. These problems have
been eliminated in the .NET universe. First, begin by examining a number of COM problems and .NET solutions.
Even if you do not have a background with COM, the next few pages will provide a conceptual background for
understanding .NET. As VB 6.0 programmers are well aware, ActiveX projects are in fact, COM applications.
COM problem: Language mapping issues
COM does not completely deliver on the notion of cross-language reuse. Types in one language do not translate
completely into another language (strings, arrays, etc). C++ developers have to take great care to ensure their
COM components can be consumed by VB6 COM components.
COM language independence relies on fragile metadata known as ‘type libraries’. The problem with type libraries
is that they are not guaranteed to be present. While VB6 did generate type libraries automatically, this was not
the case with all COM-based programming languages. Also, the type library does not describe the external types
that are needed by a COM server, only the internal types defined by the COM server.
To illustrate the problems with the COM-type system, assume the following IDL describes the interface for an
existing COM component. As you may know, IDL code is compiled into a binary-type library. A type library
can be referenced by applications to understand the composition of external COM types.
[object,uuid(5E917E51-2AF2-41B7-B2AE-E9D55F4EB820)]
interface ITheCOMObject : IUnknown
{
HRESULT Speak([in] BSTR msg);
};
[uuid(421BC46D-54A1-474F-B3EC-F03CB63566C9),version(1.0)]
library CLASSICCOMSERVERLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");
[uuid(14787E80-CAF5-4BD3-B3EA-0D53E8AA73E3)]
coclass TheCOMObject
{
[default] interface ITheCOMObject;
};
};
Consider the following clients, written in VB6 and C++:
'VB 6.0 COM Mapping
Dim o as New TheComObject
o.Speak "Hello from VB"
ITheCOMObject *pCOMObj = NULL;
if(SUCCEEDED(CoCreateInstance(CLSID_TheCOMObject, NULL, CLSCTX_SERVER,
IID_ITheCOMObject,(void**)&pCOMObj)))
{
CComBSTR test("Hi there.");
pCOMObj->Speak(test.Copy());
pCOMObj->Release();
}
Although each language is creating and using the same COM object, both do things very differently. Tote the
drastic difference in object creation syntax. Also note how the IDL BSTR type is represented in VB6 (as a
simple String) versus C++ (using an ATL CComBSTR). Finally, note that in C++ the issue of memory
management via reference counting is a manual task, while VB6 takes care of the details behind the scenes.
.NET solution: .NET offers interoperability between all .NET languages. You can even use cross-language
inheritance (e.g., a VB class can derive from a C# class). All .NET languages share a common set of programming
data types (integers, characters, float, etc.) as defined by the Common Type System (CTS). All .NET languages
share a common class library and runtime called the Common Language Runtime (CLR).
Here is the classic “Hello World” application in three different .NET languages. Note the similarities!
// Hello world in C++ / CLI.
#include "stdafx.h"
using namespace System;
int main(array<System::String ^> ^args)
{
Console::WriteLine(L"Hi from C++ / CLI");
return 0;
}
// Hello world in C#.
using System;
class MyApp
{
public static void Main()
{
Console.WriteLine("Hi from C#");
}
}
'Hello world in VB.
Imports System
Public Module MyApp
Sub Main()
Console.WriteLine("Hi from VB")
End Sub
End Module
COM problem: The registry. COM is dependent on hardcoded paths. If a binary is moved, renamed, or
deleted, the COM runtime is upset and nothing works. COM demands registration for CLSIDs, IIDs, LIBIDs,
AppIDs, CATIDs, etc.
.NET solution: No registration of components. The problem is solved as .NET does not use the system
registry to catalog objects. Instead, all custom types (classes, interfaces, enumerations, and structures) are
packaged into self-describing assemblies. Assemblies are described using a manifest. The location of an assembly
can be relative to the application root or may be placed within a machine-wide Global Assembly Cache (GAC).
COM problem: COM. COM is complex. IDL is terse, does not describe external types used by the COM
server, and is a GIGO (garbage in, garbage out!) proposition. COM demands lots of infrastructure (IUnknown,
class factories, type information, registration entries, etc.). Although VB6 helps hide the infrastructure goo, it
exists nonetheless.
NET solution: No COM (just interop). All the familiar COM atoms are simply not part of a pure .NET
application (things are not ‘hidden away’ so they don’t exist). However, .NET does provide an interop layer to
ensure .NET code can talk to COM code and vice versa.
COM problem: Platform dependence. For all practical purposes, COM is a Windows-only technology.
Worse, different flavors of the Windows OS offer different levels of COM(+) / MTS support.
.NET solution: Platform independence. .NET is a platform-independent architecture. In fact, .NET currently
works on Mac OS X and numerous Linux / Unix distributions. More details are coming at the end of this chapter.
In general then, although COM is a powerful means of expression, it has been taken over by its big brother, .NET.
Like all technologies, .NET will evolve and improve over time and add support for more features with each new
edition. So, is COM dead? COM legacy code is still usable, but .NET will steadily take over COM development
in new projects.
• Understand the scope of the .NET platform
• Examine the Common Language Runtime (CLR)
• Examine the Common Type System (CTS)
• Examine the Common Language Specification (CLS)
• Survey the core .NET Namespaces
• Understand the role of the Common Language Infrastructure (CLI)
• Understand the core of C#
• Learn about custom classes
• Learn constructors and finalizers
• Understand decision constructs and looping
• Learn C# modifiers, overloading, and exception handling
• View the pillars of OOP through C#
• Define and use abstract classes and interfaces
• Learn why and how to define nested types
Overview
The point of this first chapter is to provide a foundation for the remainder of the class, by illustrating the scope
of the .NET platform.
We begin by examining the core aspects of the .NET world, including the role of types, assemblies and
namespaces. We will also spend some time digging into the CLR to understand the key features of this runtime
and the related specifications.
The final aspect of this chapter is to survey a number of languages (and tools) which can be used to build managed
code, including VB, C# and C++/ CLI. With this foundation in place, you will have the proper mindset to build .
NET solutions using VB.
Remembering the World of COM
If you have been doing any programming for the Windows operating system, chances are COM has played an
important role.
- COM is a programming architecture for building reusable binary components.
- COM is a set of rules (COM white paper), types (interfaces, enums, co-classes), and runtime
environment (SCM, system registry). - For over 10 years, COM has been the fundamental technology for nearly all Microsoft initiatives.
COM aspires to the following goals:
- Language independence. COM clients and COM servers can be written and used by different
languages (as long as each language understands the binary layout of a COM server). - Location transparency. Client code calling a local (in-proc) COM object is identical to code calling a
remote (out-of-proc) COM object. Details are handled through configuration rather than code. - Robust versioning. As a COM class matures, new interfaces can be added without breaking existing
code. Old clients will never ask for the new interfaces and, thus, will not break.
Actually, .NET shares these goals. .NET just does it better.
COM Problems and .NET Solutions
Despite the widespread use of COM, this programming model had a number of issues. These problems have
been eliminated in the .NET universe. First, begin by examining a number of COM problems and .NET solutions.
Even if you do not have a background with COM, the next few pages will provide a conceptual background for
understanding .NET. As VB 6.0 programmers are well aware, ActiveX projects are in fact, COM applications.
COM problem: Language mapping issues
COM does not completely deliver on the notion of cross-language reuse. Types in one language do not translate
completely into another language (strings, arrays, etc). C++ developers have to take great care to ensure their
COM components can be consumed by VB6 COM components.
COM language independence relies on fragile metadata known as ‘type libraries’. The problem with type libraries
is that they are not guaranteed to be present. While VB6 did generate type libraries automatically, this was not
the case with all COM-based programming languages. Also, the type library does not describe the external types
that are needed by a COM server, only the internal types defined by the COM server.
To illustrate the problems with the COM-type system, assume the following IDL describes the interface for an
existing COM component. As you may know, IDL code is compiled into a binary-type library. A type library
can be referenced by applications to understand the composition of external COM types.
[object,uuid(5E917E51-2AF2-41B7-B2AE-E9D55F4EB820)]
interface ITheCOMObject : IUnknown
{
HRESULT Speak([in] BSTR msg);
};
[uuid(421BC46D-54A1-474F-B3EC-F03CB63566C9),version(1.0)]
library CLASSICCOMSERVERLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");
[uuid(14787E80-CAF5-4BD3-B3EA-0D53E8AA73E3)]
coclass TheCOMObject
{
[default] interface ITheCOMObject;
};
};
Consider the following clients, written in VB6 and C++:
'VB 6.0 COM Mapping
Dim o as New TheComObject
o.Speak "Hello from VB"
ITheCOMObject *pCOMObj = NULL;
if(SUCCEEDED(CoCreateInstance(CLSID_TheCOMObject, NULL, CLSCTX_SERVER,
IID_ITheCOMObject,(void**)&pCOMObj)))
{
CComBSTR test("Hi there.");
pCOMObj->Speak(test.Copy());
pCOMObj->Release();
}
Although each language is creating and using the same COM object, both do things very differently. Tote the
drastic difference in object creation syntax. Also note how the IDL BSTR type is represented in VB6 (as a
simple String) versus C++ (using an ATL CComBSTR). Finally, note that in C++ the issue of memory
management via reference counting is a manual task, while VB6 takes care of the details behind the scenes.
.NET solution: .NET offers interoperability between all .NET languages. You can even use cross-language
inheritance (e.g., a VB class can derive from a C# class). All .NET languages share a common set of programming
data types (integers, characters, float, etc.) as defined by the Common Type System (CTS). All .NET languages
share a common class library and runtime called the Common Language Runtime (CLR).
Here is the classic “Hello World” application in three different .NET languages. Note the similarities!
// Hello world in C++ / CLI.
#include "stdafx.h"
using namespace System;
int main(array<System::String ^> ^args)
{
Console::WriteLine(L"Hi from C++ / CLI");
return 0;
}
// Hello world in C#.
using System;
class MyApp
{
public static void Main()
{
Console.WriteLine("Hi from C#");
}
}
'Hello world in VB.
Imports System
Public Module MyApp
Sub Main()
Console.WriteLine("Hi from VB")
End Sub
End Module
COM problem: The registry. COM is dependent on hardcoded paths. If a binary is moved, renamed, or
deleted, the COM runtime is upset and nothing works. COM demands registration for CLSIDs, IIDs, LIBIDs,
AppIDs, CATIDs, etc.
.NET solution: No registration of components. The problem is solved as .NET does not use the system
registry to catalog objects. Instead, all custom types (classes, interfaces, enumerations, and structures) are
packaged into self-describing assemblies. Assemblies are described using a manifest. The location of an assembly
can be relative to the application root or may be placed within a machine-wide Global Assembly Cache (GAC).
COM problem: COM. COM is complex. IDL is terse, does not describe external types used by the COM
server, and is a GIGO (garbage in, garbage out!) proposition. COM demands lots of infrastructure (IUnknown,
class factories, type information, registration entries, etc.). Although VB6 helps hide the infrastructure goo, it
exists nonetheless.
NET solution: No COM (just interop). All the familiar COM atoms are simply not part of a pure .NET
application (things are not ‘hidden away’ so they don’t exist). However, .NET does provide an interop layer to
ensure .NET code can talk to COM code and vice versa.
COM problem: Platform dependence. For all practical purposes, COM is a Windows-only technology.
Worse, different flavors of the Windows OS offer different levels of COM(+) / MTS support.
.NET solution: Platform independence. .NET is a platform-independent architecture. In fact, .NET currently
works on Mac OS X and numerous Linux / Unix distributions. More details are coming at the end of this chapter.
In general then, although COM is a powerful means of expression, it has been taken over by its big brother, .NET.
Like all technologies, .NET will evolve and improve over time and add support for more features with each new
edition. So, is COM dead? COM legacy code is still usable, but .NET will steadily take over COM development
in new projects.
| C# Tutorial | C#.NET Tutorial | .NET Tutorial Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited. |
Courseware
Training Resources
Tutorials
Services