C# Tutorial

Intertech Tutorials

C# Tutorial Objective


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 problems: 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:

interface ITheCOMObject : IUnknown
HRESULT Speak([in] BSTR msg);

coclass TheCOMObject
[default] interface ITheCOMObject;

'VB 6.0 COM Mapping
Dim o as New TheComObject
o.Speak "Hello from VB"

// C++ COM Mapping
ITheCOMObject *pCOMObj = NULL;

CComBSTR test("Hi there.");

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.

Copyright (c) 2008-2013. 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.