Why C#?
(Coding in the Microsoft world)
by
Ray Pla
©RayPla, 2007
Table of Contents
Introduction ................................................................................................................... 1
How We Got Here ......................................................................................................... 2
Programming for the .NET Framework ..................................................................... 3
Framework Class Library ............................................................................................ 4
C# - - What it is/ What it is not/ When do you use it ................................................. 5
Other Options ................................................................................................................ 7
Reading Suggestions ..................................................................................................... 8
©RayPla, 2007
i
Introduction
The answer to the question "Why C#?" is as varied as the technologies which it supports through
the .NET Framework. The .NET Framework, directly or indirectly, supports practically all of
Microsoft’s software features. Microsoft developed the .NET platform as a replacement for the
more complicated direct interface to the Win32 SDK libraries.
C#, through the .NET platform, is inextricably tied to the Win32 SDK which preceded it. The
.NET Framework Class Library basically “wraps” the Win32 SDK, using a language-neutral
calling structure. While this makes practically all system facilities available through C#, they are
(almost) equally available through any other language choice. In the Microsoft world, the other
major language, generally used for end-user application development, is Visual Basic (known as
VB). The .NET platform provides VB with effectively the same features as C# (or what
Microsoft calls “managed” C++).
The real answer to “Why C#?” is: when it fits. Some types of applications seem better suited to
C# simply because the people doing the coding are more comfortable with it. The same is true of
VB. Generally, the .NET Framework Class Library has leveled the programming field, but the
types of applications that are being developed haven’t really changed significantly. So the more
systems-oriented types of applications are better done using C#, while those that are more useroriented applications are better done using VB.
Clearly, there are exceptions. Someone doing admin-related coding might use VB with ADSI
(Microsoft’s network administration tool) to get answers to questions related to network
elements. But this is something that has been traditionally done using “scripts”, and these are
usually written in VB. On the other hand, an application which requires complicated server-side
interactions might be written into a web-based app using C#. Once you have decided on .NET,
there are really no clear rules for which language is the best choice. It really depends on who’s
doing the work and what they feel most comfortable with.
The underlying message is that .NET changed the rules for programmers. I think it was Don Box
that said, around 2001 or so, that .NET was the “blue pill” for programmers (referring to The
Matrix). The “red pill” was all the COM/ATL, C++ and associated complexities that Microsoft
had come up with for developing systems-based applications prior to the .NET Framework.
The “blue pill” is really the Framework Class Library and the underlying simplicity that this
structure brings to the programming paradigm. While Sun might have created the initial concepts
with Java, Microsoft solidified the development of any applications which depend on Microsoft’s
various libraries. This made it rather unimportant which language was actually chosen to develop
a Microsoft-based app. It becomes more a matter of taste and style rather than technical merit.
Having said that the choice of C# is mainly a matter of taste, I will spend the rest of this paper
showing why it might be a better choice in some classes of applications as opposed to others. But,
before that, I will try to explain its raison d’ettre – I do not believe this to be to give us a better or
different Java (although it may do either or both of those things, depending on your point of
view).
©RayPla, 2007
1
How We Got Here
Back in the dim dark past of the 1980s, programming a PC meant using the C language in a
single-process environment (MS-DOS). As the 1990s approached, Microsoft introduced
Windows and created a language called Visual Basic to make programming more accessible.
Windows was still running under a DOS environment, where it was effectively the only program
running in the PC. Applications ran under Windows and, until Windows 95, could only run one
application at a time.
When Microsoft built NT in the early 1990s, it created a true multitasking operating system,
similar to those commonly in use on the larger minicomputers and mainframes of the time. At the
same time, the microprocessors in use went from a 16-bit to a 32-bit architecture. This gave rise
to the Win32 libraries, where a large number of common routines became available. The concept
of Win32 was to allow programs written for the older Windows operating environment and the
new NT environment to coexist and provide a common “look and feel”.
The key point is that the Windows “look and feel” is central to the Microsoft programming
environment. Applications written to run in a Windows environment are likely to use a display
that is based on the Windows interfaces and structured to conform to those interfaces. While the
Win32 libraries will allow far more than simply graphical display, the Windows routines are
rarely far away.
After its introduction, Windows NT was the platform of choice in the corporate world, replacing
Windows 3.1, and Windows 95 and 98 became the platform for home use. Windows NT morphed
into Windows 2000. The older Windows 95, 98 and Millennium Edition (ME) basically dropped
away with the introduction of XP, which is simply a version of NT. During this period,
programming methods transformed substantially as well.
With the focus on the Internet toward the late 1990s, everything, including Microsoft’s view of
the world, became browser-centric. This meant that their desktop window became a variant of a
browser window. More importantly for programmers, the focus was less on a client-server
paradigm and more on the delivery of web pages through the browser. Using the browser as a key
information tool was adopted in both the corporate and home environments.
Programming, in the Microsoft world, became increasingly complex throughout the 1990s.
Before the introduction of Win32, there were the Win16 libraries. These were fundamental to
Windows 3.1, and could also be used in Windows 95. Programming in the NT world used the
Win32 libraries. Since NT had a strong set of security features and was geared toward networking
in a corporate environment, the Win32 libraries embraced these elements, as well as providing the
standard Windows calls. In effect, the Win32 libraries became the backbone set of calls on which
almost all Microsoft features are based.
The Win32 libraries included some important development features which added to the
complexity. There was a strong emphasis on creating reusable software components, and also on
attempting to make some of these – especially complex visual components – available to VB
programmers. Normally, these components were available through the Win32 Software
Developers Kit, which were only supported through C and C++. An example of an ActiveX
component which was supported in VB would be the visual representation of a calendar.
©RayPla, 2007
2
Programming for the .NET Framework
The complexities of programming support for things like ActiveX controls and the associated
Component Object Model paradigm made it necessary for Microsoft developers to learn a lot of
fairly arcane rules, based largely on the way COM was implemented. (Some of this is
unavoidable if you are going to encourage developers to build these components themselves.)
In order to get around these problems, Microsoft developed the .NET Framework to support a
language-neutral mechanism for exposing their various components. This is the set of libraries
known as the Framework Class Libraries (or FCL). In order to make the libraries languageneutral, Microsoft chose to use an intermediate language and to have this compiled, at run time,
into actual machine code.
Because Microsoft was already using an Interface Definition Language for COM development,
when the .NET Framework was developed, the Intermediate Language (or MSIL), which their
Common Language Runtime (or CLR) used to actually build the machine code, was a fairly
natural extension.
The first time the code runs, the runtime code is actually created from the MSIL by a Just-InTime compiler (abbreviated as JIT and usually referred to as the “jitter”). Once compiled, if the
same routine is needed again, the already compiled code is used. (This pretty much follows Sun’s
Java language paradigm, which uses the Java Virtual Machine, in a very similar way.)
When developing for the .NET Framework, a program is developed in a specific language (say,
C#) and then compiled into units, called Assemblies. The Assemblies are generally combined
using Microsoft’s Visual Studio IDE (Integrated Development Environment) through a linker
which ensures that another element, the Manifest, goes with the program when it is decoded by
the CLR. The Manifest contains Manifest Metadata, which defines the associated Assemblies and
resources needed by the program.
The fact that an Assembly can be created in any language can allow the intermixing of language
use, although this is not done very often. It is possible, though, to develop an Assembly in VB or
Managed C++ and combine them with an Assembly written using C# into one program (with one
common Manifest). General practice, however, is to use one language for one specific purpose.
Usually programs are based on historical design requirements, so they tend to be web-based,
network-oriented, database apps, and the like. Therefore, generally only one small portion of the
Framework Class Library is used, and usually this is done in a specific language. Web-based apps
are generally done in VB, for example.
Because Microsoft was trying to simplify the programming task, a fair amount of emphasis was
put on developing various solutions using VB. With the introduction of .NET and the Framework
Class Library, a lot of components became available to VB programmers which had not been
before. However, the complexity inherent in some of the features was still there, although easier
to control. This will be discussed in more detail in the section on C#.
©RayPla, 2007
3
Framework Class Library
The Framework Class Library are designed based on object-oriented principles, introduced to
widespread use through C++. Practically everything related to coding for the FCL is derived from
a single object: the System object. Each important set of classes has its own Namespace, another
concept introduced primarily through C++. Because it encompasses almost all of the features that
a developer would need to support a Microsoft-based application, it is huge. There are over a
hundred namespaces in the FCL and thousands of calls within the classes inside those
namespaces.
Within the FCL, the visual components of applications are exposed through Web Forms and
Windows Forms using the System.Web.UI and System.Windows.Forms namespaces, respectively.
XML Web Services (such as those using SOAP and run with .aspx extension) are built using the
System.Web.Services namespace.
As you might expect, there are a large number of namespaces within the FCL devoted to
supporting specific programming tasks, and many others which are specialized to internal data or
communication handling. Eight separate namespaces are used to allow access to data sources
(generally databases) and are derived from the System.Data namespace. (The System.Data
namespace itself is primarily dedicated to ADO.NET, which is Microsoft’s primary set of calls to
datasources, through various database providers.)
Since Microsoft has been prolific in the extension of its overall feature set, I will not attempt to
enumerate more than a few of the more important other namespaces The namespaces derived
from System.Drawing generally relate to the graphics images available through GDI+, their 2D
graphics package; it also simplifies printing from images on the screen. Printing based on screenbased text presents a number of problems, since you are using a large number of fonts and visual
type sizes which are handled differently when shown on a screen and when handled by a printer.
The System.Messaging namespace allows programs to exchange information in the form of
messages, where the System.Web.Mail namespace allows the creation and transmission of SMTPbased messages. About twenty namespaces derive from the System.Web namespace, including
seven specifically related to UI presentation, such as visual controls for both mobile and standard
web-page display.
System-level communications can be established through sockets using System.Net.Sockets.
Internal, corporate-type, network control (of users, devices and their allowed access) can be
developed using the System.Directory (Active Directory) namespace; the System.Management
namespaces will allow the events related to people and devices on a corporate network to be
monitored. When events are to be controlled on a different computer, the
System.Runtime.Remoting namespaces come into play. The System.Security namespaces were
improved in .NET 2.0 and control various access rights.
It should be clear, without going into the specifics of the individual namespaces that comprise the
FCL, that it can handle most of the programming chores that you might want to do using the
Microsoft feature set. In the discussion of C#, I’ll try to refine which are more appropriate for the
C# programmer and which fit better with another language (most likely VB).
©RayPla, 2007
4
C# - - What it is/ What it is not/ When do you use it
C# is a language defined in the ECMA-334 International Standard as submitted by HewlettPackard, Intel, and Microsoft. In the Introduction to the Standard (3rd Edition), two key elements
define its importance: providing “strong type checking, array bounds checking, detection of
attempts to use uninitialized variables, and automatic garbage collection” and “Source code
portability is very important, as is programmer portability, especially for those programmers
already familiar with C and C++."
C# follows C syntax and C++ conventions fairly closely. An example taken from page 26 of the
Standard should serve to clarify:
Class Test
{
static void Main(){
Stack s = new Stack();
for (int i=0; i < 10; i++)
s.Push(i);
s = null;
}
}
The following text accompanies the example:
The example shows code that uses the Stack class. A Stack is created and
initialized with 10 elements, and then assigned the value null. Once the variable s
is assigned null, the Stack and the associated 10 Node instances become eligible
for garbage collection. The garbage collector is permitted to clean up
immediately, but is not required to do so.
(The example, of course, assumes that the method Push will create a Node instance.)
The most important thing to note is that if one is familiar with C++, C# seems nearly intuitive.
Except for the reference to null, this could be C++ code. A few things differentiate C# from C++:
it allows for collections and enumerators, and it supports delegates
A collection allows a variable number of elements to be added to a structure which can be treated
as if it were an array (which is supported in both C# and C++), but it can also be enumerated as if
it were a Standard Template Library (STL) Container in C++. The concept of a delegate is not
really in the C++ world, since it is a general mechanism for handling events and callbacks on
those events. The STL refers to events in the context of ios_streams but there is not really a
general facility.
©RayPla, 2007
5
A delegate, on the other hand, is a rather general mechanism which allows for typesafe handling
of what would generally be handled in C++ with pointers (and then have to be carefully coded to
be typesafe). The declaration of a delegate allows for one piece of code (in one class) to send a
message to another piece of code (in another class). Using delegates, coding a multithreading
application is a fair amount safer than if coded in C++, since the compiler is far more likely to
catch easy errors. (It doesn’t catch the harder timing-dependent synchronization errors, but it does
provide the lock() method, which can help monitor a piece of code and make it effectively a
critical section.)
In general, an application written with C# is likely to be one which would have been written using
C++ in the past. Now that generics have been added in .NET 2.0, even the concept of templates
in C++ are now available, although this is not yet in widespread use. Also, with the addition of
most of the Win32 security APIs in .NET 2.0, most of the reasons for the interoperability with the
older COM coding has become unnecessary. C# is now a fairly robust development language,
especially when used with Visual Studio, as is normal.
It should also be clear that C# is not a low-level language. It cannot easily be used for
some applications (the most obvious are device drivers and other really time-critical apps,
as well as any apps that need direct control over real memory. These type of applications
will still have to be done primarily in C with the Win32 libraries, as needed.
As you might expect, standard UI-based applications would be the least likely candidates for C#.
But an awful lot of MFC programmers used C++ to develop any number of UI-based
applications. This can, and does, become a matter of what you are comfortable with and can do
easily. Applications that were designed for VB, such as Active Directory applications, can be
done in C#, if combined with other system-based calls. But, here too, it becomes a matter of taste,
since VB Script was the language of choice for Active Directory coding.
©RayPla, 2007
6
Other Options
As I’m sure I’ve already made clear, for applications, especially to be developed for the Web, a
programmer probably wants to use VB. This was largely the language of choice in the past, and
it’s the most obvious choice when using the .NET environment. This is equally true with
ASP.NET. With the use of the DataGrid control, display of database information has been
simplified. So, unless there’s a clear reason to interface to other information source or do other
back-end coding, the language of choice for Web applications is probably VB.
When developing applications outside of the Microsoft purview, i.e., In a UNIX/Linux
environment, the choices are numerous. Depending on what you want to do, Perl is often the best
choice, especially for Web applications. If you need to keep an application in an object-oriented
format and access component feature available in packages like JavaBeans, then Java is your
obvious choice. And the C language hasn’t gone away from UNIX development, especially if
you’re modifying the Kernel in any way.
As is true in all programming development, select the tools that seem to fit the job. This includes
the people working on it.
Ciao!
©RayPla, 2007
7
Reading Suggestions
C# Language Specification (Standard ECMA-334, 3rd Edition). Geneva: Ecma
International, 2005.
Chappell, David. Understanding .NET: A Tutorial and Analysis. Reading, MA: Addison
Wesley, 2002.
Newcomer, Joseph M., and Brent E. Rector. Win32 Programming. Reading, MA:
Addison Wesley, 1997.
Richter, Jeffrey. Applied Microsoft .NET Framework Programming. Redmond, WA:
Microsoft Press, 2002.
Troelsen, Andrew. Pro C# with .NET 3.0, Special Edition. Berkeley CA: Apress, 2007.
©RayPla, 2007
8