.NET Tutorial Objective
- 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 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:
- 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);
[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;
if(SUCCEEDED(CoCreateInstance(CLSID_TheCOMObject, NULL, CLSCTX_SERVER,
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
using namespace System;
Console::WriteLine(L"Hi from C++ / CLI");
// Hello world in C#.
public static void Main()
Console.WriteLine("Hi from C#");
'Hello world in VB.
Public Module MyApp
Console.WriteLine("Hi from VB")
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.