A few notes on C#/.NET after attending a MS developers conference
(thanks to Intertrader Ltd, for sending me, but these notes were
written in my own time and express my personal out-of-work opinions,
not those of my employers):|
- .NET is not COM, but has two (apparently only slightly) related
components: First, a common runtime environment for VB, C# and
(partially) C++. Second, XML based web services.
- Although the .NET runtime (CLR) includes many services, it is more
than "another COM wrapper". COM objects still exist, separately,
and can be accessed from .NET languages, but the services provided
by the CLR are more closely integrated. For example, it appears
that class-like services can be subclassed, errors handled as
exceptions rather than return codes, and memory management is
- 14 languages are available (most not by MS). I didn't have time to
write down the whole list while the overhead was displayed, but
believe that they include: Perl, Python, Cobol, Oberon, OCaml, ML,
Haskell, JScript, Oz, Mercury, C#, VB, Eiffel (which makes 13).
- Language implementations can either take advantage of the CLR or,
more compreehensively, provide services (libraries) to other .NET
languages. A service appears to be a class that follows certain
restructions (CLS) - single inheritance, safe code (see below), etc.
(I may be using the term "service" incorrectly here, but you get the
- The source language of a CLS compliant service should be irrelevant
to a user of that service.
- All 14 languages can apparently provide (as well as use) .NET
services. This struck me as odd, when some don't support classes
(ML, for example) - when I asked the "experts" later, the response
was first "what's ML?" and then "Hmm. Who own's it - you'll have to
ask them". The idea of a language wasn't (i) commercial and (ii)
didnt support OOP, was apparently very odd... (if that sounds like a
cheap shot at MS I should add that I really enjoyed the conference).
- C# is, apart from the .NET library, closer to C++ than Java (IMHO).
It has things like enums, conversion methods (but not constructors
as in C++) and even pointers and explicit relative positioning of
structure components in memory (to allow binary level compatability
with data structures provided by alien libraries, for example).
However, objects are "reference values" (on the heap), so the C++
emphasis on consturctors has gone.
- C# still has a preprocessor. It is restricted to definitions and
simple logic, so C# also introduces attributes which are commands
inside  that instruct the compiler to take special action. They
are used for a variety of purposes - from adding properties to
classes (for documentation) to requesting the compiler to provide an
HTML driver interface to a method (data is retruned as XML - this is
also how object persistence is implemented and, since XML is
ubiquitous in the next set of MS server products this can presumably
- The use of pointers indicates that the code is "unsafe". Unsafe
code affects security (see later). In the last talk I went to we
were told that a cast that might fail is also an unsafe operation,
but I think this was either an error or a less strict definiton of
unsafe, because (as far as I can see) C# suffers from the same
problems as Java with containers (which store objects as object
instances which must be cast back to the appropriate subclass when
extracted). I can't believe that all C# code that uses containers
will be rated as unsafe, especially when any cast error is detected
at runtime (throwing an exception).
- C# has virtual method versioning, which Chris mentioned a while back
(this detects when a method is introduced "below" what was
previously the "bottom" virtual method in a class hierarchy).
Methods have to be marked explicitly as virtual and it is also
possible to have "value types" which are like classes, but have no
inheritance and are allocated on the stack (structures with
- Various quirks (like the value types, the "as" operator that saves a
test for class type, and being able to turn IEEE numerical handling
off) indicate that MS is trying to keep the potential performance of
C# code close to C++ (esp. managed C++ - see later). The speakers
all seemed to follow the school of thought that advocates discarding
lifebelts before taking to the roughest seas...
- All .NET languages compile to a platform independent Intermediate
Language. This is then either passed to a JIT at execution time or
compiled on installation. When I asked there was no explanation for
how MS would avoid the problems that face Java developers in
ensuring that the appropriate JIT version is available on the client
- Perhaps assemblies will help with this. Applications are now
packaged as directory trees that include all components -
assemblies. Each application can then use local libraries (or,
depending on configuration, global libraries). This is to avoid
problems when different versions of the same library exist.
- Security doesn't seem to be finalized in detail, but will be based
on the program's requirements (familiar to anyone who's written for
the MS Java VM and wanted to get outside the sandbox). Programs
will be able to request priveliges (like access to files). Whether
access is granted or not will depend on a variety of factors:
unsafe/safe, source (both from signatures and delivery method),
privilege requested, etc. I asked for more details about
signatures, but couldn't get a firm answer - it is "unlikely" that
everything will need to be signed, although quite possible that an
administrator and/or user will be able to configure a machine so
that this is the case. You might read that as "it would be
possible, if you were sufficiently lax with security, to run
- Interestingly, the C# talks were not very popular. The convention
had two halls for talks and parallel talks on C# and ADO (I believe)
were swapped, moving C# to the smaller hall. The final two
(parallel) talks were optional - one was a repeat of the C# talk.
But at the last minute the C# talk was moved to an even smaller hall
and an extra VB talk was also run (yes, the C# talk was then packed,
but it was a very small room....).
- Finally, something I've not heard much fanfare over: MS are
introduciing "managed C++". By including an optional keyword in the
class definition the memory management can be handed over to the
.NET runtime. Given this, and the availability of the .NET
libraries to C++ and (fully OO) VB, what is the point of C#?
- Oh, and has anyone managed to get MS's search engine to recognise
C#? It seems to return matches to C.