Does .NET replace COM?

This subject causes a lot of controversy, as you'll see if you read the mailing
list archives. Take a look at the following two threads:

http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&D=0&P=68241

http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R60761

The bottom line is that .NET has its own mechanisms for type interaction, and
they don't use COM. No IUnknown, no IDL, no typelibs, no registry-based activation.
This is mostly good, as a lot of COM was ugly. Generally speaking, .NET allows
you to package and use components in a similar way to COM, but makes the whole
thing a bit easier.

Is DCOM dead?

Pretty much, for .NET developers. The .NET Framework has a new remoting model
which is not based on DCOM. DCOM was pretty much dead anyway, once firewalls
became widespread and Microsoft got SOAP fever. Of course DCOM will still be
used in interop scenarios.

Is COM+ dead?

Not immediately. The approach for .NET 1.0 was to provide access to the existing
COM+ services (through an interop layer) rather than replace the services with
native .NET ones. Various tools and attributes were provided to make this as
painless as possible. Over time it is expected that interop will become more
seamless - this may mean that some services become a core part of the CLR, and/or
it may mean that some services will be rewritten as managed code which runs
on top of the CLR.

For more on this topic, search for postings by Joe Long in the archives - Joe
is the MS group manager for COM+. Start with this message:

http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R68370

Can I use COM components from .NET programs?

Yes. COM components are accessed from the .NET runtime via a Runtime Callable
Wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component
into .NET-compatible interfaces. For oleautomation interfaces, the RCW can be
generated automatically from a type library. For non-oleautomation interfaces,
it may be necessary to develop a custom RCW which manually maps the types exposed
by the COM interface to .NET-compatible types.

Here's a simple example for those familiar with ATL. First, create an ATL component
which implements the following IDL:

import "oaidl.idl";

import "ocidl.idl";



[

object,

uuid(EA013F93-487A-4403-86EC-FD9FEE5E6206),

helpstring("ICppName Interface"),

pointer_default(unique),

oleautomation

]

interface ICppName : IUnknown

{

[helpstring("method SetName")] HRESULT SetName([in] BSTR name);

[helpstring("method GetName")] HRESULT GetName([out,retval] BSTR *pName
);

};

[

uuid(F5E4C61D-D93A-4295-A4B4-2453D4A4484D),

version(1.0),

helpstring("cppcomserver 1.0 Type Library")

]

library CPPCOMSERVERLib

{

importlib("stdole32.tlb");

importlib("stdole2.tlb");

[

uuid(600CE6D9-5ED7-4B4D-BB49-E8D5D5096F70),

helpstring("CppName Class")

]

coclass CppName

{

[default] interface ICppName;

};

};

When you've built the component, you should get a typelibrary. Run the TLBIMP
utility on the typelibary, like this:

tlbimp cppcomserver.tlb

If successful, you will get a message like this:

Typelib imported successfully to CPPCOMSERVERLib.dll

You now need a .NET client - let's use C#. Create a .cs file containing the
following code:

using System;

using CPPCOMSERVERLib;

public class MainApp

{

static public void Main()

{

CppName cppname = new CppName();

cppname.SetName( "bob" );

Console.WriteLine( "Name is " + cppname.GetName() );

}

}

Compile the C# code like this:

csc /r:cppcomserverlib.dll csharpcomclient.cs

Note that the compiler is being told to reference the DLL we previously generated
from the typelibrary using TLBIMP. You should now be able to run csharpcomclient.exe,
and get the following output on the console:

Name is bob

Can I use .NET components from COM programs?

Yes. .NET components are accessed from COM via a COM Callable Wrapper (CCW).
This is similar to a RCW (see previous question), but works in the opposite
direction. Again, if the wrapper cannot be automatically generated by the .NET
development tools, or if the automatic behaviour is not desirable, a custom
CCW can be developed. Also, for COM to 'see' the .NET component, the .NET component
must be registered in the registry.

Here's a simple example. Create a C# file called testcomserver.cs and put the
following in it:

using System;

using System.Runtime.InteropServices;

namespace AndyMc

{

[ClassInterface(ClassInterfaceType.AutoDual)]

public class CSharpCOMServer

{

public CSharpCOMServer() {}

public void SetName( string name ) { m_name = name; }

public string GetName() { return m_name; }

private string m_name;

}

}

Then compile the .cs file as follows:

csc /target:library testcomserver.cs

You should get a dll, which you register like this:

regasm testcomserver.dll /tlb:testcomserver.tlb /codebase

Now you need to create a client to test your .NET COM component. VBScript will
do - put the following in a file called comclient.vbs:

Dim dotNetObj

Set dotNetObj = CreateObject("AndyMc.CSharpCOMServer")

dotNetObj.SetName ("bob")

MsgBox "Name is " & dotNetObj.GetName()

and run the script like this:

wscript comclient.vbs

And hey presto you should get a message box displayed with the text "Name
is bob".

An alternative to the approach above it to use the dm.net moniker developed
by Jason Whittington and Don Box.

Is ATL redundant in the .NET world?

Yes. ATL will continue to be valuable for writing COM components for some time,
but it has no place in the .NET world.

What is serialization?

Serialization is the process of converting an object into a stream of bytes. Deserialization
is the opposite process, i.e. creating an object from a stream of bytes. Serialization/Deserialization
is mostly used to transport objects (e.g. during remoting), or to persist objects
(e.g. to a file or database).

Does the .NET Framework have in-built support for serialization?

There are two separate mechanisms provided by the .NET class library - XmlSerializer
and SoapFormatter/BinaryFormatter. Microsoft uses XmlSerializer for Web Services,
and SoapFormatter/BinaryFormatter for remoting. Both are available for use in
your own code.

I want to serialize instances of my class. Should I use XmlSerializer,
SoapFormatter or BinaryFormatter?

It depends. XmlSerializer has severe limitations such as the requirement that
the target class has a parameterless constructor, and only public read/write
properties and fields can be serialized. However, on the plus side, XmlSerializer
has good support for customising the XML document that is produced or consumed.
XmlSerializer's features mean that it is most suitable for cross-platform work,
or for constructing objects from existing XML documents.

SoapFormatter and BinaryFormatter have fewer limitations than XmlSerializer.
They can serialize private fields, for example. However they both require that
the target class be marked with the [Serializable] attribute, so like XmlSerializer
the class needs to be written with serialization in mind. Also there are some
quirks to watch out for - for example on deserialization the constructor of
the new object is not invoked.

The choice between SoapFormatter and BinaryFormatter depends on the application.
BinaryFormatter makes sense where both serialization and deserialization will
be performed on the .NET platform and where performance is important. SoapFormatter
generally makes more sense in all other cases, for ease of debugging if nothing
else.

Can I customise the serialization process?

Yes. XmlSerializer supports a range of attributes that can be used to configure
serialization for a particular class. For example, a field or property can be
marked with the [XmlIgnore] attribute to exclude it from serialization. Another
example is the [XmlElement] attribute, which can be used to specify the XML
element name to be used for a particular property or field.

Serialization via SoapFormatter/BinaryFormatter can also be controlled to some
extent by attributes. For example, the [NonSerialized] attribute is the equivalent
of XmlSerializer's [XmlIgnore] attribute. Ultimate control of the serialization
process can be acheived by implementing the the ISerializable interface on the
class whose instances are to be serialized.

Why is XmlSerializer so slow?

There is a once-per-process-per-type overhead with XmlSerializer. So the first
time you serialize or deserialize an object of a given type in an application,
there is a significant delay. This normally doesn't matter, but it may mean,
for example, that XmlSerializer is a poor choice for loading configuration settings
during startup of a GUI application.

Why do I get errors when I try to serialize a Hashtable?

XmlSerializer will refuse to serialize instances of any class that implements
IDictionary, e.g. Hashtable. SoapFormatter and BinaryFormatter do not have this
restriction.

XmlSerializer is throwing a generic "There was an error reflecting
MyClass" error. How do I find out what the problem is?

Look at the InnerException property of the exception that is thrown to get a
more specific error message.

Why am I getting an InvalidOperationException when I serialize an ArrayList?

XmlSerializer needs to know in advance what type of objects it will find in
an ArrayList. To specify the type, use the XmlArrayItem attibute like this:

public class Person

{

public string Name;

public int Age;

}

public class Population

{

[XmlArrayItem(typeof(Person))] public ArrayList People;

}

What is garbage collection?

What is garbage collection?

Garbage collection is a heap-management strategy where a run-time component takes
responsibility for managing the lifetime of the memory used by objects. This concept
is not new to .NET - Java and many other languages/runtimes have used garbage
collection for some time.

Is it true that objects don't always get destroyed immediately when
the last reference goes away?

Yes. The garbage collector offers no guarantees about the time when an object
will be destroyed and its memory reclaimed.

There was an interesting thread on the DOTNET list, started by Chris Sells,
about the implications of non-deterministic destruction of objects in C#. In
October 2000, Microsoft's Brian Harry posted a lengthy analysis of the problem.
Chris Sells' response to Brian's posting is here.

Why doesn't the .NET runtime offer deterministic destruction?

Because of the garbage collection algorithm. The .NET garbage collector works
by periodically running through a list of all the objects that are currently
being referenced by an application. All the objects that it doesn't find during
this search are ready to be destroyed and the memory reclaimed. The implication
of this algorithm is that the runtime doesn't get notified immediately when
the final reference on an object goes away - it only finds out during the next
'sweep' of the heap.

Futhermore, this type of algorithm works best by performing the garbage collection
sweep as rarely as possible. Normally heap exhaustion is the trigger for a collection
sweep.

Is the lack of deterministic destruction in .NET a problem?

It's certainly an issue that affects component design. If you have objects that
maintain expensive or scarce resources (e.g. database locks), you need to provide
some way to tell the object to release the resource when it is done. Microsoft
recommend that you provide a method called Dispose() for this purpose. However,
this causes problems for distributed objects - in a distributed system who calls
the Dispose() method? Some form of reference-counting or ownership-management
mechanism is needed to handle distributed objects - unfortunately the runtime
offers no help with this.

Should I implement Finalize on my class? Should I implement IDisposable?

This issue is a little more complex than it first appears. There are really
two categories of class that require deterministic destruction - the first category
manipulate unmanaged types directly, whereas the second category manipulate
managed types that require deterministic destruction. An example of the first
category is a class with an IntPtr member representing an OS file handle. An
example of the second category is a class with a System.IO.FileStream member.

For the first category, it makes sense to implement IDisposable and override
Finalize. This allows the object user to 'do the right thing' by calling Dispose,
but also provides a fallback of freeing the unmanaged resource in the Finalizer,
should the calling code fail in its duty. However this logic does not apply
to the second category of class, with only managed resources. In this case implementing
Finalize is pointless, as managed member objects cannot be accessed in the Finalizer.
This is because there is no guarantee about the ordering of Finalizer execution.
So only the Dispose method should be implemented. (If you think about it, it
doesn't really make sense to call Dispose on member objects from a Finalizer
anyway, as the member object's Finalizer will do the required cleanup.)

For classes that need to implement IDisposable and override Finalize, see Microsoft's
documented pattern.

Note that some developers argue that implementing a Finalizer is always a bad
idea, as it hides a bug in your code (i.e. the lack of a Dispose call). A less
radical approach is to implement Finalize but include a Debug.Assert at the
start, thus signalling the problem in developer builds but allowing the cleanup
to occur in release builds.

Do I have any control over the garbage collection algorithm?

A little. For example the System.GC class exposes a Collect method, which forces
the garbage collector to collect all unreferenced objects immediately.

Also there is a gcConcurrent setting that can be specified via the application
configuration file. This specifies whether or not the garbage collector performs
some of its collection activities on a separate thread. The setting only applies
on multi-processor machines, and defaults to true.

How can I find out what the garbage collector is doing?

Lots of interesting statistics are exported from the .NET runtime via the '.NET
CLR xxx' performance counters. Use Performance Monitor to view them.

What is the lapsed listener problem?

The lapsed listener problem is one of the primary causes of leaks in .NET applications.
It occurs when a subscriber (or 'listener') signs up for a publisher's event,
but fails to unsubscribe. The failure to unsubscribe means that the publisher
maintains a reference to the subscriber as long as the publisher is alive. For
some publishers, this may be the duration of the application.

This situation causes two problems. The obvious problem is the leakage of the
subscriber object. The other problem is the performance degredation due to the
publisher sending redundant notifications to 'zombie' subscribers.

There are at least a couple of solutions to the problem. The simplest is to
make sure the subscriber is unsubscribed from the publisher, typically by adding
an Unsubscribe() method to the subscriber. Another solution, documented here
by Shawn Van Ness, is to change the publisher to use weak references in its
subscriber list.

When do I need to use GC.KeepAlive?

It's very unintuitive, but the runtime can decide that an object is garbage
much sooner than you expect. More specifically, an object can become garbage
while a method is executing on the object, which is contrary to most developers'
expectations. Chris Brumme explains the issue on his blog. I've taken Chris's
code and expanded it into a full app that you can play with if you want to prove
to yourself that this is a real problem:

using System;

using System.Runtime.InteropServices;

class Win32

{

[DllImport("kernel32.dll")]

public static extern IntPtr CreateEvent( IntPtr lpEventAttributes,

bool bManualReset,bool bInitialState, string lpName);

[DllImport("kernel32.dll", SetLastError=true)]

public static extern bool CloseHandle(IntPtr hObject);

[DllImport("kernel32.dll")]

public static extern bool SetEvent(IntPtr hEvent);

}

class EventUser

{

public EventUser()

{

hEvent = Win32.CreateEvent( IntPtr.Zero, false, false, null );

}



~EventUser()

{

Win32.CloseHandle( hEvent );

Console.WriteLine("EventUser finalized");

}

public void UseEvent()

{

UseEventInStatic( this.hEvent );

}

static void UseEventInStatic( IntPtr hEvent )

{

//GC.Collect();

bool bSuccess = Win32.SetEvent( hEvent );

Console.WriteLine( "SetEvent " + (bSuccess ? "succeeded"
: "FAILED!") );

}

IntPtr hEvent;

}

class App

{

static void Main(string[] args)

{

EventUser eventUser = new EventUser();

eventUser.UseEvent();

}

}

If you run this code, it'll probably work fine, and you'll get the following
output:

SetEvent succeeded

EventDemo finalized

However, if you uncomment the GC.Collect() call in the UseEventInStatic() method,
you'll get this output:

EventDemo finalized

SetEvent FAILED!

(Note that you need to use a release build to reproduce this problem.)

So what's happening here? Well, at the point where UseEvent() calls UseEventInStatic(),
a copy is taken of the hEvent field, and there are no further references to
the EventUser object anywhere in the code. So as far as the runtime is concerned,
the EventUser object is garbage and can be collected. Normally of course the
collection won't happen immediately, so you'll get away with it, but sooner
or later a collection will occur at the wrong time, and your app will fail.

A solution to this problem is to add a call to GC.KeepAlive(this) to the end
of the UseEvent method, as Chris explains.

What is an application domain?

An AppDomain can be thought of as a lightweight process. Multiple AppDomains can
exist inside a Win32 process. The primary purpose of the AppDomain is to isolate
applications from each other, and so it is particularly useful in hosting scenarios
such as ASP.NET. An AppDomain can be destroyed by the host without affecting other
AppDomains in the process.

Win32 processes provide isolation by having distinct memory address spaces.
This is effective, but expensive. The .NET runtime enforces AppDomain isolation
by keeping control over the use of memory - all memory in the AppDomain is managed
by the .NET runtime, so the runtime can ensure that AppDomains do not access
each other's memory.

One non-obvious use of AppDomains is for unloading types. Currently the only
way to unload a .NET type is to destroy the AppDomain it is loaded into. This
is particularly useful if you create and destroy types on-the-fly via reflection.

Microsoft have an AppDomain FAQ.

How does an AppDomain get created?

AppDomains are usually created by hosts. Examples of hosts are the Windows Shell,
ASP.NET and IE. When you run a .NET application from the command-line, the host
is the Shell. The Shell creates a new AppDomain for every application.

AppDomains can also be explicitly created by .NET applications. Here is a C#
sample which creates an AppDomain, creates an instance of an object inside it,
and then executes one of the object's methods:

using System;

using System.Runtime.Remoting;

using System.Reflection;

public class CAppDomainInfo : MarshalByRefObject

{

public string GetName() { return AppDomain.CurrentDomain.FriendlyName; }

}

public class App

{

public static int Main()

{

AppDomain ad = AppDomain.CreateDomain( "Andy's new domain" );

CAppDomainInfo adInfo = (CAppDomainInfo)ad.CreateInstanceAndUnwrap(

Assembly.GetCallingAssembly().GetName().Name, "CAppDomainInfo" );


Console.WriteLine( "Created AppDomain name = " + adInfo.GetName()
);

return 0;

}

}

Can I write my own .NET host?

Yes. For an example of how to do this, take a look at the source for the dm.net
moniker developed by Jason Whittington and Don Box. There is also a code sample
in the .NET SDK called CorHost.

What is an assembly?

An assembly is sometimes described as a logical .EXE or .DLL, and can be an application
(with a main entry point) or a library. An assembly consists of one or more files
(dlls, exes, html files etc), and represents a group of resources, type definitions,
and implementations of those types. An assembly may also contain references to
other assemblies. These resources, types and references are described in a block
of data called a manifest. The manifest is part of the assembly, thus making the
assembly self-describing.

An important aspect of assemblies is that they are part of the identity of
a type. The identity of a type is the assembly that houses it combined with
the type name. This means, for example, that if assembly A exports a type called
T, and assembly B exports a type called T, the .NET runtime sees these as two
completely different types. Furthermore, don't get confused between assemblies
and namespaces - namespaces are merely a hierarchical way of organising type
names. To the runtime, type names are type names, regardless of whether namespaces
are used to organise the names. It's the assembly plus the typename (regardless
of whether the type name belongs to a namespace) that uniquely indentifies a
type to the runtime.

Assemblies are also important in .NET with respect to security - many of the
security restrictions are enforced at the assembly boundary.

Finally, assemblies are the unit of versioning in .NET - more on this below.

How can I produce an assembly?

The simplest way to produce an assembly is directly from a .NET compiler. For
example, the following C# program:

public class CTest

{

public CTest() { System.Console.WriteLine( "Hello from CTest" ); }

}

can be compiled into a library assembly (dll) like this:

csc /t:library ctest.cs

You can then view the contents of the assembly by running the "IL Disassembler"
tool that comes with the .NET SDK.

Alternatively you can compile your source into modules, and then combine the
modules into an assembly using the assembly linker (al.exe). For the C# compiler,
the /target:module switch is used to generate a module instead of an assembly.

What is the difference between a private assembly and a shared assembly?

Location and visibility: A private assembly is normally used by a single application,
and is stored in the application's directory, or a sub-directory beneath. A
shared assembly is normally stored in the global assembly cache, which is a
repository of assemblies maintained by the .NET runtime. Shared assemblies are
usually libraries of code which many applications will find useful, e.g. the
.NET framework classes.

Versioning: The runtime enforces versioning constraints only on shared assemblies,
not on private assemblies.

How do assemblies find each other?

By searching directory paths. There are several factors which can affect the
path (such as the AppDomain host, and application configuration files), but
for private assemblies the search path is normally the application's directory
and its sub-directories. For shared assemblies, the search path is normally
same as the private assembly path plus the shared assembly cache.

How does assembly versioning work?

Each assembly has a version number called the compatibility version. Also each
reference to an assembly (from another assembly) includes both the name and
version of the referenced assembly.

The version number has four numeric parts (e.g. 5.5.2.33). Assemblies with
either of the first two parts different are normally viewed as incompatible.
If the first two parts are the same, but the third is different, the assemblies
are deemed as 'maybe compatible'. If only the fourth part is different, the
assemblies are deemed compatible. However, this is just the default guideline
- it is the version policy that decides to what extent these rules are enforced.
The version policy can be specified via the application configuration file.

Remember: versioning is only applied to shared assemblies, not private assemblies.

How can I develop an application that automatically updates itself
from the web?

For .NET 1.x, use the Updater Application Block.

What is the CLI? Is it the same as the CLR?

The CLI (Common Language Infrastructure) is the definiton of the fundamentals
of the .NET framework - the Common Type System (CTS), metadata, the Virtual Execution
Environment (VES) and its use of intermediate language (IL), and the support of
multiple programming languages via the Common Language Specification (CLS). The
CLI is documented through ECMA - see http://msdn.microsoft.com/net/ecma/ for more
details.

The CLR (Common Language Runtime) is Microsoft's primary implementation of
the CLI. Microsoft also have a shared source implementation known as ROTOR,
for educational purposes, as well as the .NET Compact Framework for mobile devices.
Non-Microsoft CLI implementations include Mono and DotGNU Portable.NET.

What is the CTS, and how does it relate to the CLS?

CTS = Common Type System. This is the full range of types that the .NET runtime
understands. Not all .NET languages support all the types in the CTS.

CLS = Common Language Specification. This is a subset of the CTS which all
.NET languages are expected to support. The idea is that any program which uses
CLS-compliant types can interoperate with any .NET program written in any language.
This interop is very fine-grained - for example a VB.NET class can inherit from
a C# class.

2.3 What is IL?

IL = Intermediate Language. Also known as MSIL (Microsoft Intermediate Language)
or CIL (Common Intermediate Language). All .NET source code (of any language)
is compiled to IL during development. The IL is then converted to machine code
at the point where the software is installed, or (more commonly) at run-time
by a Just-In-Time (JIT) compiler.

2.4 What is C#?

C# is a new language designed by Microsoft to work with the .NET framework.
In their "Introduction to C#" whitepaper, Microsoft describe C# as
follows:

"C# is a simple, modern, object oriented, and type-safe programming language
derived from C and C++. C# (pronounced “C sharp”) is firmly planted
in the C and C++ family tree of languages, and will immediately be familiar
to C and C++ programmers. C# aims to combine the high productivity of Visual
Basic and the raw power of C++."

Substitute 'Java' for 'C#' in the quote above, and you'll see that the statement
still works pretty well :-).

If you are a C++ programmer, you might like to check out my C# FAQ.

What does 'managed' mean in the .NET context?

The term 'managed' is the cause of much confusion. It is used in various places
within .NET, meaning slightly different things.

Managed code: The .NET framework provides several core run-time services to
the programs that run within it - for example exception handling and security.
For these services to work, the code must provide a minimum level of information
to the runtime. Such code is called managed code.

Managed data: This is data that is allocated and freed by the .NET runtime's
garbage collector.

Managed classes: This is usually referred to in the context of Managed Extensions
(ME) for C++. When using ME C++, a class can be marked with the __gc keyword.
As the name suggests, this means that the memory for instances of the class
is managed by the garbage collector, but it also means more than that. The class
becomes a fully paid-up member of the .NET community with the benefits and restrictions
that brings. An example of a benefit is proper interop with classes written
in other languages - for example, a managed C++ class can inherit from a VB
class. An example of a restriction is that a managed class can only inherit
from one base class.

What is reflection?

All .NET compilers produce metadata about the types defined in the modules they
produce. This metadata is packaged along with the module (modules in turn are
packaged together in assemblies), and can be accessed by a mechanism called
reflection. The System.Reflection namespace contains classes that can be used
to interrogate the types for a module/assembly.

Using reflection to access .NET metadata is very similar to using ITypeLib/ITypeInfo
to access type library data in COM, and it is used for similar purposes - e.g.
determining data type sizes for marshaling data across context/process/machine
boundaries.

Reflection can also be used to dynamically invoke methods (see System.Type.InvokeMember),
or even create types dynamically at run-time (see System.Reflection.Emit.TypeBuilder).

Take it from http://www.andymcm.com/dotnetfaq.htm

What is .NET?

.NET is a general-purpose software development platform, similar to Java. At its
core is a virtual machine that turns intermediate language (IL) into machine code.
High-level language compilers for C#, VB.NET and C++ are provided to turn source
code into IL. C# is a new programming language, very similar to Java. An extensive
class library is included, featuring all the functionality one might expect from
a contempory development platform - windows GUI development (Windows Forms), database
access (ADO.NET), web development (ASP.NET), web services, XML etc.

See also Microsoft's definition.

When was .NET announced?

Bill Gates delivered a keynote at Forum 2000, held June 22, 2000, outlining
the .NET 'vision'. The July 2000 PDC had a number of sessions on .NET technology,
and delegates were given CDs containing a pre-release version of the .NET framework/SDK
and Visual Studio.NET.

What versions of .NET are there?

The final versions of the 1.0 SDK and runtime were made publicly available around
6pm PST on 15-Jan-2002. At the same time, the final version of Visual Studio.NET
was made available to MSDN subscribers.

.NET 1.1 was released in April 2003, and was mostly bug fixes for 1.0.

.NET 2.0 was released to MSDN subscribers in late October 2005, and was officially
launched in early November.

What operating systems does the .NET Framework run on?

The runtime supports Windows Server 2003, Windows XP, Windows 2000, NT4 SP6a
and Windows ME/98. Windows 95 is not supported. Some parts of the framework
do not work on all platforms - for example, ASP.NET is only supported on XP
and Windows 2000/2003. Windows 98/ME cannot be used for development.

IIS is not supported on Windows XP Home Edition, and so cannot be used to host
ASP.NET. However, the ASP.NET Web Matrix web server does run on XP Home.

The .NET Compact Framework is a version of the .NET Framework for mobile devices,
running Windows CE or Windows Mobile.

The Mono project has a version of the .NET Framework that runs on Linux.

What tools can I use to develop .NET applications?

There are a number of tools, described here in ascending order of cost:

The .NET Framework SDK is free and includes command-line compilers for C++,
C#, and VB.NET and various other utilities to aid development.

SharpDevelop is a free IDE for C# and VB.NET.

Microsoft Visual Studio Express editions are cut-down versions of Visual Studio,
for hobbyist or novice developers.There are different versions for C#, VB, web
development etc. Originally the plan was to charge $49, but MS has decided to
offer them as free downloads instead, at least until November 2006.

Microsoft Visual Studio Standard 2005 is around $300, or $200 for the upgrade.


Microsoft VIsual Studio Professional 2005 is around $800, or $550 for the upgrade.


At the top end of the price range are the Microsoft Visual Studio Team Edition
for Software Developers 2005 with MSDN Premium and Team Suite editions.

You can see the differences between the various Visual Studio versions here.

Why did they call it .NET?

I don't know what they were thinking. They certainly weren't thinking of people
using search tools. It's meaningless marketing nonsense.

Take it from http://www.andymcm.com/dotnetfaq.htm