Datasheet

The compiler raises an error if you attempt to use features that are not supported by .NET on managed
types (for example, templates or multiple inheritance of classes). You will also find that you will need
to use nonstandard C++ features (such as the
_gc keyword shown in the previous code) when using
managed classes.
Because of the freedom that C++ allows in terms of low-level pointer manipulation and so on, the C++
compiler is not able to generate code that will pass the CLR’s memory type safety tests. If it’s important
that your code be recognized by the CLR as memory type safe, you’ll need to write your source code in
some other language (such as C# or Visual Basic 2005).
Visual J# 2005
The latest language to be added to the mix is Visual J# 2005. Prior to .NET Framework 1.1, users were able
to use J# only after making a separate download. Now the J# language is built into the .NET Framework.
Because of this, J# users are able to take advantage of all the usual features of Visual Studio 2005. Microsoft
expects that most J++ users will find it easiest to use J# if they want to work with .NET. Instead of being
targeted at the Java runtime libraries, J# uses the same base class libraries that the rest of the .NET-
compliant languages use. This means that you can use J# for building ASP.NET Web applications,
Windows Forms, XML Web services, and everything else that is possible — just as C# and Visual
Basic 2005 can.
Scripting Languages
Scripting languages are still around, although in general, their importance is likely to decline with the
advent of .NET. JScript, on the other hand, has been upgraded to JScript .NET. You can now write ASP.NET
pages in JScript .NET, run JScript .NET as a compiled rather than an interpreted language, and write
strongly typed JScript .NET code. With ASP.NET there is no reason to use scripting languages in server-
side Web pages. VBA is, however, still used as a language for Microsoft Office and Visual Studio macros.
COM and COM+
Technically speaking, COM and COM+ aren’t technologies targeted at .NET, because components based
on them cannot be compiled into IL (although it’s possible to do so to some degree using managed C++,
if the original COM component was written in C++). However, COM+ remains an important tool, because
its features are not duplicated in .NET. Also, COM components will still work — and .NET incorporates
COM interoperability features that make it possible for managed code to call up COM components and
vice versa (this is discussed in Chapter 23, “COM Interoperability”). In general, however, you will prob-
ably find it more convenient for most purposes to code new components as .NET components, so that
you can take advantage of the .NET base classes as well as the other benefits of running as managed code.
A Closer Look at Intermediate Language
From what you learned in the previous section, Microsoft Intermediate Language obviously plays a fun-
damental role in the .NET Framework. As C# developers, we now understand that our C# code will be
compiled into IL before it is executed (indeed, the C# compiler only compiles to managed code). It makes
sense, then, to now take a closer look at the main characteristics of IL, because any language that targets
.NET will logically need to support the main characteristics of IL, too.
7
Chapter 1: .NET Architecture
24727c01.qxd:WroxPro 5/7/07 12:12 PM Page 7