Dot Net FAQs
Dot Net FAQs
Dot Net FAQs
This FAQ was inspired by discussions on the DOTNET mailing list. The list has now been split into
several DOTNET-X lists - for details see http://discuss.develop.com/.
Christophe Lauer has translated the FAQ into French - you can find it at http://www.dotnet-
fr.org/documents/andy_faqdotnet_fr.html
Royal has translated the FAQ into Chinese - you can find it at
http://www.royaloo.com/articles/articles_2002/dotNetFAQ.htm
Disclaimer: The content of this FAQ is just my interpretation of information gleaned from various
sources, including postings to the DOTNET-X mailing lists and various MS documents. The answers
are not necessarily correct or up-to-date. Note that this FAQ has no official connection to the
DOTNET-X mailing lists, or to Developmentor (the company who host the lists), or to Microsoft.
Revision history:
Contents
1. Introduction
o 1.1 What is .NET?
2. Basic terminology
o 2.1 What is the CLR?
3. Assemblies
o 3.1 What is an assembly?
o 3.3 What is the difference between a private assembly and a shared assembly?
4. Application Domains
o 4.1 What is an Application Domain?
5. Garbage Collection
o 5.1 What is garbage collection?
o 5.2 Is it true that objects don't always get destroyed immediately when the last
reference goes away?
o 5.3 Why doesn't the .NET runtime offer deterministic destruction?
o 5.5 Does non-deterministic destruction affect the usage of COM objects from
managed code?
o 5.6 I've heard that Finalize methods should be avoided. Should I implement Finalize
on my class?
o 5.7 Do I have any control over the garbage collection algorithm?
o 5.8 How can I find out what the garbage collector is doing?
6. Serialization
o 6.1 What is serialization?
o 6.2 Does the .NET Framework have in-built support for serialization?
o 6.7 XmlSerializer is throwing a generic "There was an error reflecting MyClass" error.
How do I find out what the problem is?
7. Attributes
o 7.1 What are attributes?
o 8.7 I'm having some trouble with CAS. How can I diagnose my problem?
o 8.8 I can't be bothered with all this CAS stuff. Can I turn it off?
11. Miscellaneous
o 11.1 How does .NET remoting work?
o 11.2 How can I get at the Win32 API from a .NET program?
12.5.5 How do I know when my thread pool work item has completed?
13. Resources
o 13.1 Recommended books
o 13.3 Weblogs
1. Introduction
1.1 What is .NET?
A more practical definition would be that .NET is a new environment for developing and running
software applications, featuring ease of development of web-based services, rich standard run-
time services available to components written in a variety of programming languages, and inter-
language and inter-machine interoperability.
Note that when the term ".NET" is used in this FAQ it refers only to the new .NET runtime and
associated technologies. This is sometimes called the ".NET Framework". This FAQ does NOT
cover any of the various other existing and new products/technologies that Microsoft are attaching
the .NET name to (e.g. SQL Server.NET).
No. If you write any Windows software (using ATL/COM, MFC, VB, or even raw Win32), .NET may
offer a viable alternative (or addition) to the way you do things currently. Of course, if you do
develop web sites, then .NET has lots to interest you - not least ASP.NET.
1.3 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.
The final version of the 1.0 SDK and runtime was 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 Framework SDK: The SDK is free and includes command-line compilers for C++, C#,
and VB.NET and various other utilities to aid development.
ASP.NET Web Matrix: This is a free ASP.NET development environment from Microsoft. As
well as a GUI development environment, the download includes a simple web server that can
be used instead of IIS to host ASP.NET apps. This opens up ASP.NET development to users
of Windows XP Home Edition, which cannot run IIS.
Microsoft Visual C# .NET Standard 2003: This is a cheap (around $100) version of Visual
Studio limited to one language and also with limited wizard support. For example, there's no
wizard support for class libraries or custom UI controls. Useful for beginners to learn with, or
for savvy developers who can work around the deficiencies in the supplied wizards. As well as
C#, there are VB.NET and C++ versions.
Microsoft Visual Studio.NET Professional 2003: If you have a license for Visual Studio 6.0,
you can get the upgrade. You can also upgrade from VS.NET 2002 for a token $30. Visual
Studio.NET includes support for all the MS languages (C#, C++, VB.NET) and has extensive
wizard support.
At the top end of the price spectrum are the Visual Studio.NET 2003 Enterprise and Enterprise
Architect editions. These offer extra features such as Visual Sourcesafe (version control), and
performance and analysis tools. Check out the Visual Studio.NET Feature Comparison at
http://msdn.microsoft.com/vstudio/howtobuy/choosing.asp.
The runtime supports 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 Windows XP and Windows 2000. 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.
MS provides compilers for C#, C++, VB and JScript. Other vendors have announced that they
intend to develop .NET compilers for languages such as COBOL, Eiffel, Perl, Smalltalk and
Python.
2. Basic terminology
CLR = Common Language Runtime. The CLR is a set of standard resources that (in theory)
any .NET program can take advantage of, regardless of programming language. Robert Schmidt
(Microsoft) lists the following CLR resources in his MSDN PDC# article:
What this means is that in the .NET world, different programming languages will be more equal in
capability than they have ever been before, although clearly not all languages will support all CLR
services.
CTS = Common Type System. This is the range of types that the .NET runtime understands, and
therefore that .NET applications can use. However note that not all .NET languages will support all
the types in the CTS. The CTS is a superset of the CLS.
In theory this allows very tight interop between different .NET languages - for example allowing a
C# class to inherit from a VB class.
2.4 What is IL?
2.5 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.
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.
All C# and Visual Basic.NET code is managed by default. VS7 C++ code is not managed by
default, but the compiler can produce managed code by specifying a command-line switch
(/com+).
Managed data: This is data that is allocated and de-allocated by the .NET runtime's garbage
collector. C# and VB.NET data is always managed. VS7 C++ data is unmanaged by default, even
when using the /com+ switch, but it can be marked as managed using the __gc keyword.
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.
2.7 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.
3. Assemblies
3.1 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.
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" );
}
}
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.
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.
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.
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.
4. Application Domains
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 an application from other
applications.
Win32 processes provide isolation by having distinct memory address spaces. This is effective,
but it is expensive and doesn't scale well. 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.
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. Note that you must name the executable 'appdomaintest.exe' for this code to
work as-is.
using System;
using System.Runtime.Remoting;
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 (http://staff.develop.com/jasonw/clr/readme.htm ). There is also
a code sample in the .NET SDK called CorHost.
5. Garbage Collection
Garbage collection is a system whereby a run-time component takes responsibility for managing
the lifetime of objects and the heap memory that they occupy. This concept is not new to .NET -
Java and many other languages/runtimes have used garbage collection for some time.
5.2 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 is an interesting thread in the archives, started by Chris Sells, about the implications of non-
deterministic destruction of objects in C#: http://discuss.develop.com/archives/wa.exe?
A2=ind0007&L=DOTNET&P=R24819
In October 2000, Microsoft's Brian Harry posted a lengthy analysis of the problem:
http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572
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.
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 for the client 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.
Yes. When using a COM object from managed code, you are effectively relying on the garbage
collector to call the final release on your object. If your COM object holds onto an expensive
resource which is only cleaned-up after the final release, you may need to provide a new interface
on your object which supports an explicit Dispose() method.
5.6 I've heard that Finalize methods should be avoided. Should I implement Finalize on
my class?
An object with a Finalize method is more work for the garbage collector than an object without
one. Also there are no guarantees about the order in which objects are Finalized, so there are
issues surrounding access to other objects from the Finalize method. Finally, there is no
guarantee that a Finalize method will get called on an object, so it should never be relied upon to
do clean-up of an object's resources.
A little. For example, the System.GC class exposes a Collect method - this forces the garbage
collector to collect all unreferenced objects immediately.
Lots of interesting statistics are exported from the .NET runtime via the '.NET CLR xxx'
performance counters. Use Performance Monitor to view them.
6. Serialization
6.1 What is serialization?
Serialization is the process of converting an object into a stream of bytes. Deserialization is the
opposite process of 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).
There are two separate mechanisms provided by the .NET class library - XmlSerializer and
SoapFormatter/BinaryFormatter. Microsoft uses XmlSerializer for Web Services, and uses
SoapFormatter/BinaryFormatter for remoting. Both are available for use in your own code.
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.
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.
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.
XmlSerializer will refuse to serialize instances of any class that implements IDictionary, e.g.
Hashtable. SoapFormatter and BinaryFormatter do not have this restriction.
Look at the InnerException property of the exception that is thrown to get a more specific error
message.
7. Attributes
The other type of attribute is a context attribute. Context attributes use a similar syntax to
metadata attributes but they are fundamentally different. Context attributes provide an interception
mechanism whereby instance activation and method calls can be pre- and/or post-processed. If
you've come across Keith Brown's universal delegator you'll be familiar with this idea.
Yes. Simply derive a class from System.Attribute and mark it with the AttributeUsage attribute. For
example:
[AttributeUsage(AttributeTargets.Class)]
public class InspiredByAttribute : System.Attribute
{
public string InspiredBy;
class CApp
{
public static void Main()
{
object[] atts =
typeof(CTest).GetCustomAttributes(true);
CAS is the part of the .NET security model that determines whether or not a piece of code is
allowed to run, and what resources it can use when it is running. For example, it is CAS that will
prevent a .NET web applet from formatting your hard disk.
The CAS security policy revolves around two key concepts - code groups and permissions.
Each .NET assembly is a member of a particular code group, and each code group is granted the
permissions specified in a named permission set.
For example, using the default security policy, a control downloaded from a web site belongs to
the 'Zone - Internet' code group, which adheres to the permissions defined by the 'Internet' named
permission set. (Naturally the 'Internet' named permission set represents a very restrictive range of
permissions.)
Microsoft defines some default ones, but you can modify these and even create your own. To see
the code groups defined on your system, run 'caspol -lg' from the command-line. On my system it
looks like this:
Level = Machine
Code Groups:
Note the hierarchy of code groups - the top of the hierarchy is the most general ('All code'), which
is then sub-divided into several groups, each of which in turn can be sub-divided. Also note that
(somewhat counter-intuitively) a sub-group can be associated with a more permissive permission
set than its parent.
Use caspol. For example, suppose you trust code from www.mydomain.com and you want it have
full access to your system, but you want to keep the default restrictions for all other internet sites.
To achieve this, you would add a new code group as a sub-group of the 'Zone - Internet' group,
like this:
Now if you run caspol -lg you will see that the new group has been added as group 1.3.1:
...
1.3. Zone - Internet: Internet
1.3.1. Site - www.mydomain.com: FullTrust
...
Note that the numeric label (1.3.1) is just a caspol invention to make the code groups easy to
manipulate from the command-line. The underlying runtime never sees it.
Use caspol. If you are the machine administrator, you can operate at the 'machine' level - which
means not only that the changes you make become the default for the machine, but also that
users cannot change the permissions to be more permissive. If you are a normal (non-admin) user
you can still modify the permissions, but only to make them more restrictive. For example, to allow
intranet code to do what it likes you might do this:
Note that because this is more permissive than the default policy (on a standard system), you
should only do this at the machine level - doing it at the user level will have no effect.
Yes. Use caspol -ap, specifying an XML file containing the permissions in the permission set. To
save you some time, here is a sample file corresponding to the 'Everything' permission set - just
edit to suit your needs. When you have edited the sample, add it to the range of available
permission sets like this:
8.7 I'm having some trouble with CAS. How can I diagnose my problem?
Caspol has a couple of options that might help. First, you can ask caspol to tell you what code
group an assembly belongs to, using caspol -rsg. Similarly, you can ask what permissions are
being applied to a particular assembly using caspol -rsp.
8.8 I can't be bothered with all this CAS stuff. Can I turn it off?
caspol -s off
Yes. MS supply a tool called Ildasm which can be used to view the metadata and IL for an
assembly.
Yes, it is often relatively straightforward to regenerate high-level source (e.g. C#) from IL.
There is currently no simple way to stop code being reverse-engineered from IL. In future it is
likely that IL obfuscation tools will become available, either from MS or from third parties. These
tools work by 'optimising' the IL in such a way that reverse-engineering becomes much more
difficult.
Of course if you are writing web services then reverse-engineering is not a problem as clients do
not have access to your IL.
.assembly MyAssembly {}
.class MyApp {
.method static void Main() {
.entrypoint
ldstr "Hello, IL!"
call void System.Console::WriteLine(class
System.Object)
ret
}
}
Just put this into a file called hello.il, and then run ilasm hello.il. An exe assembly will be
generated.
Yes. A couple of simple examples are that you can throw exceptions that are not derived from
System.Exception, and you can have non-zero-based arrays.
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
FWIW my view is as follows: COM is many things, and it's different things to different people. But
to me, COM is fundamentally about how little blobs of code find other little blobs of code, and how
they communicate with each other when they find each other. COM specifies precisely how this
location and communication takes place. In a 'pure' .NET world, consisting entirely of .NET
objects, little blobs of code still find each other and talk to each other, but they don't use COM to
do so. They use a model which is similar to COM in some ways - for example, type information is
stored in a tabular form packaged with the component, which is quite similar to packaging a type
library with a COM component. But it's not COM.
So, does this matter? Well, I don't really care about most of the COM stuff going away - I don't
care that finding components doesn't involve a trip to the registry, or that I don't use IDL to define
my interfaces. But there is one thing that I wouldn't like to go away - I wouldn't like to lose the idea
of interface-based development. COM's greatest strength, in my opinion, is its insistence on a
cast-iron separation between interface and implementation. Unfortunately, the .NET framework
seems to make no such insistence - it lets you do interface-based development, but it doesn't
insist. Some people would argue that having a choice can never be a bad thing, and maybe
they're right, but I can't help feeling that maybe it's a backward step.
10.2 Is DCOM dead?
Pretty much, for .NET developers. The .NET Framework has a new remoting model which is not
based on DCOM. Of course DCOM will still be used in interop scenarios.
No. The approach for the first .NET release is 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 are provided to try to make this as painless as possible. The PDC release of the
.NET SDK includes interop support for core services (JIT activation, transactions) but not some of
the higher level services (e.g. COM+ Events, Queued components).
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
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
]
When you've built the component, you should get a typelibrary. Run the TLBIMP utility on the
typelibary, like this:
tlbimp cppcomserver.tlb
You now need a .NET client - let's use C#. Create a .cs file containing the following code:
using System;
using CPPCOMSERVERLib;
Note that we are using the type library name as a namespace, and the COM class name as the
class. Alternatively we could have used CPPCOMSERVERLib.CppName for the class name and
gone without the using CPPCOMSERVERLib statement.
You should now be able to run csharpcomclient.exe, and get the following output on the console:
Name is bob
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;
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;
}
}
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()
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. Go to http://staff.develop.com/jasonw/clr/readme.htm to check it out.
Yes, if you are writing applications that live inside the .NET framework. Of course many
developers may wish to continue using ATL to write C++ COM components that live outside the
framework, but if you are inside you will almost certainly want to use C#. Raw C++ (and therefore
ATL which is based on it) doesn't have much of a place in the .NET world - it's just too near the
metal and provides too much flexibility for the runtime to be able to manage it.
11. Miscellaneous
.NET remoting involves sending messages along channels. Two of the standard channels are
HTTP and TCP. TCP is intended for LANs only - HTTP can be used for LANs or WANs (internet).
Support is provided for multiple message serializarion formats. Examples are SOAP (XML-based)
and binary. By default, the HTTP channel uses SOAP (via the .NET runtime Serialization SOAP
Formatter), and the TCP channel uses binary (via the .NET runtime Serialization Binary
Formatter). But either channel can use either serialization format.
SingleCall. Each incoming request from a client is serviced by a new object. The object is
thrown away when the request has finished.
Singleton. All incoming requests from clients are processed by a single server object.
Client-activated object. This is the old stateful (D)COM model whereby the client receives a
reference to the remote object and holds that reference (thus keeping the remote object alive)
until it is finished with it.
Distributed garbage collection of objects is managed by a system called 'leased based lifetime'.
Each object has a lease time, and when that time expires the object is disconnected from the
.NET runtime remoting infrastructure. Objects have a default renew time - the lease is renewed
when a successful call is made from the client to the object. The client can also explicitly renew
the lease.
If you're interested in using XML-RPC as an alternative to SOAP, take a look at Charles Cook's
XML-RPC.Net site at http://www.cookcomputing.com/xmlrpc/xmlrpc.shtml.
11.2 How can I get at the Win32 API from a .NET program?
Use P/Invoke. This uses similar technology to COM Interop, but is used to access static DLL entry
points instead of COM objects. Here is an example of C# calling the Win32 MessageBox function:
using System;
using System.Runtime.InteropServices;
class MainApp
{
[DllImport("user32.dll", EntryPoint="MessageBox",
SetLastError=true, CharSet=CharSet.Auto)]
public static extern int MessageBox(int hWnd, String
strMessage, String strCaption, uint uiType);
12. Class Library
12.1 File I/O
FileStream inherits from Stream, so you can wrap the FileStream object with a StreamReader
object. This provides a nice interface for processing the stream line by line:
sr.Close();
Note that this will automatically call Close() on the underlying Stream object, so an explicit
fs.Close() is not required.
Similar to text files, except wrap the FileStream object with a BinaryReader/Writer object instead of
a StreamReader/Writer object.
12.2 Text Processing
Yes. Use the System.Text.RegularExpressions.Regex class. For example, the following code
updates the title in an HTML file:
12.3 Internet
Stream s = response.GetResponseStream();
Note that WebRequest and WebReponse objects can be downcast to HttpWebRequest and
HttpWebReponse objects respectively, to access http-specific functionality.
System.Net.GlobalProxySelection.Select = new
WebProxy( "proxyname", 80 );
HttpWebRequest request =
(HttpWebRequest)WebRequest.Create( "http://localhost" );
request.Proxy = new WebProxy( "proxyname", 80 );
12.4 XML
<PEOPLE>
<PERSON>Fred</PERSON>
<PERSON>Bill</PERSON>
</PEOPLE>
Console.WriteLine( personElement.FirstChild.Value.ToString() );
The output is:
Fred
Bill
No. Instead, a new XmlReader/XmlWriter API is offered. Like SAX it is stream-based but it uses a
'pull' model rather than SAX's 'push' model. Here's an example:
while( reader.Read() )
{
if( reader.NodeType == XmlNodeType.Element && reader.Name ==
"PERSON" )
{
reader.Read(); // Skip to the child text
Console.WriteLine( reader.Value );
}
}
12.5 Threading
Yes, there is extensive support for multi-threading. New threads can be spawned, and there is a
system-provided threadpool which applications can use.
In this case creating an instance of the MyThread class is sufficient to spawn the thread and
execute the MyThread.ThreadMain() method:
There are several options. First, you can use your own communication mechanism to tell the
ThreadStart method to finish. Alternatively the Thread class has in-built support for instructing the
thread to stop. The two principle methods are Thread.Interrupt() and Thread.Abort(). The former
will cause a ThreadInterruptedException to be thrown on the thread when it next goes into a
WaitJoinSleep state. In other words, Thread.Interrupt is a polite way of asking the thread to stop
when it is no longer doing any useful work. In contrast, Thread.Abort() throws a
ThreadAbortException regardless of what the thread is doing. Furthermore, the
ThreadAbortException cannot normally be caught (though the ThreadStart's finally method will be
executed). Thread.Abort() is a heavy-handed mechanism which should not normally be required.
class CApp
{
static void Main()
{
string s = "Hello, World";
ThreadPool.QueueUserWorkItem( new WaitCallback( DoWork
), s );
There is no way to query the thread pool for this information. You must put code into the
WaitCallback method to signal that it has completed. Events are useful for this.
Each object has a concurrency lock (critical section) associated with it. The
System.Threading.Monitor.Enter/Exit methods are used to acquire and release this lock. For
example, instances of the following class only allow one thread at a time to enter method f():
class C
{
public void f()
{
try
{
Monitor.Enter(this);
...
}
finally
{
Monitor.Exit(this);
}
}
}
C# has a 'lock' keyword which provides a convenient shorthand for the code above:
class C
{
public void f()
{
lock(this)
{
...
}
}
}
Note that calling Monitor.Enter(myObject) does NOT mean that all access to myObject is
serialized. It means that the synchronisation lock associated with myObject has been acquired,
and no other thread can acquire that lock until Monitor.Exit(o) is called. In other words, this class is
functionally equivalent to the classes above:
class C
{
public void f()
{
lock( m_object )
{
...
}
}
12.6 Tracing
Yes, in the System.Diagnostics namespace. There are two main classes that deal with tracing -
Debug and Trace. They both work in a similar way - the difference is that tracing from the Debug
class only works in builds that have the DEBUG symbol defined, whereas tracing from the Trace
class only works in builds that have the TRACE symbol defined. Typically this means that you
should use System.Diagnostics.Trace.WriteLine for tracing that you want to work in debug and
release builds, and System.Diagnostics.Debug.WriteLine for tracing that you want to work only in
debug builds.
Yes. The Debug and Trace classes both have a Listeners property, which is a collection of sinks
that receive the tracing that you send via Debug.WriteLine and Trace.WriteLine respectively. By
default the Listeners collection contains a single sink, which is an instance of the
DefaultTraceListener class. This sends output to the Win32 OutputDebugString() function and also
the System.Diagnostics.Debugger.Log() method. This is useful when debugging, but if you're
trying to trace a problem at a customer site, redirecting the output to a file is more appropriate.
Fortunately, the TextWriterTraceListener class is provided for this purpose.
Here's how to use the TextWriterTraceListener class to redirect Trace output to a file:
Trace.Listeners.Clear();
FileStream fs = new FileStream( @"c:\log.txt", FileMode.Create,
FileAccess.Write );
Trace.Listeners.Add( new TextWriterTraceListener( fs ) );
Trace.WriteLine( @"This will be writen to c:\log.txt!" );
Trace.Flush();
Note the use of Trace.Listeners.Clear() to remove the default listener. If you don't do this, the
output will go to the file and OutputDebugString(). Typically this is not what you want, because
OutputDebugString() imposes a big performance hit.
Yes. You can write your own TraceListener-derived class, and direct all output through it. Here's a
simple example, which derives from TextWriterTraceListener (and therefore has in-built support for
writing to files, as shown above) and adds timing information and the thread ID for each trace line:
(Note that this implementation is not complete - the TraceListener.Write method is not overridden
for example.)
The beauty of this approach is that when an instance of MyListener is added to the
Trace.Listeners collection, all calls to Trace.WriteLine() go through MyListener, including calls
made by referenced assemblies that know nothing about the MyListener class.
13. Resources
13.1 Recommended books
I recommend the following books, either because I personally like them, or because I think they
are well regarded by other .NET developers. (Note that I get a commission from Amazon if you
buy a book after following one of these links.)
Applied Microsoft .NET Framework Programming - Jeffrey Richter
Much anticipated, mainly due to Richter's superb Win32 books, and most people think it
delivers. The 'applied' is a little misleading - this book is mostly about how the .NET
Framework works 'under the hood'. Examples are in C#, but there is also a separate VB
edition of the book.
Essential .NET Volume 1, The Common Language Runtime - Don Box
Don's books don't always demonstrate the same dazzling ability to communicate that he
exhibits in person, but they are always chock full of technical detail you just don't get other
places. Essential .NET is likely to become a must-read for all .NET developers.
Programming Windows with C# - Charles Petzold
Another slightly misleading title - this book is solely about GUI programming - Windows Forms
and GDI+. Well written, with comprehensive coverage. My only (minor) criticism is that the
book sticks closely to the facts, without offering a great deal in the way of 'tips and tricks' for
real-world apps.
Developing Applications with Visual Studio.NET - Richard Grimes
Covers lots of interesting topics that other books don't, including ATL7, Managed C++,
internationalization, remoting, as well as the more run-of-the-mill CLR and C# stuff. Also a lot
of info on the Visual Studio IDE. This book is most suitable for reasonably experienced C++
programmers.
C# and the .NET Platform - Andrew Troelsen
Regarded by many as the best all round C#/.NET book. Wide coverage including Windows
Forms, COM interop, ADO.NET, ASP.NET etc. Troelsen also has a respected VB.NET book
called Visual Basic .NET and the .NET Platform: An Advanced Guide.
Programming Microsoft Visual Basic .NET - Francesco Balena
Balena is a reknowned VB-er, and the reviews of his VB.NET book are glowing.
.NET and COM - The Complete Interoperability Guide - Adam Nathan
Widely regarded as the bible of .NET/COM interop.
Advanced .NET Remoting - Ingo Rammer
Widely recommended.
13.2 Internet Resources