.NET Tutorial
Table of Contents
.NET 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)
•        Implicit Types
•        Extension Methods
•        Anonymous Types
•        Lambda Expressions

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
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.
  • The VB 6.0 compiler would generate type libraries upon compilation.

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

    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"

    // 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
Training Resources
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.