NET Framework FA Q's
NET Framework FA Q's
NET Framework FA Q's
This FAQ tries to answer some commonly asked questions about the fundamentals of
the .NET Framework - topics like assemblies, garbage collection, security, interop
with COM, and remoting. The most commonly-used parts of the class library are also
covered. Other aspects of the .NET Framework such as ASP.NET, ADO.NET and
WinForms are not covered.
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
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?
• 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.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?
• 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?
• 13. Resources
o 13.1 Recommended books
o 13.3 Weblogs
1. Introduction
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.
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.
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.
In theory this allows very tight interop between different .NET languages - for
example allowing a C# class to inherit from a VB class.
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.
2.6 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. 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.
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.
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:
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.
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.
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.
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
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.
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.
In the normal case the client calls Dispose(), the object's resources are freed, and
the garbage collector is relieved of its Finalizing duties by the call to
SuppressFinalize(). In the worst case, i.e. the client forgets to call Dispose(), there is
a reasonable chance that the object's resources will eventually get freed by the
garbage collector calling Finalize(). Given the limitations of the garbage collection
algorithm this seems like a pretty reasonable approach.
A little. For example, the System.GC class exposes a Collect method - this forces
the garbage collector to collect all unreferenced objects immediately.
5.8 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.
6. Serialization
6.2 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 uses SoapFormatter/BinaryFormatter for remoting. Both are
available for use in your own code.
There are at least two types of .NET attribute. The first type I will refer to as a
metadata attribute - it allows some data to be attached to a class or method. This
data becomes part of the metadata for the class, and (like other class metadata)
can be accessed via reflection. An example of a metadata attribute is [serializable],
which can be attached to a class and means that instances of the class can be
serialized.
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.)
8.3 Who defines the CAS code groups?
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:
Then, to apply the permission set to a code group, do something 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
9. Intermediate Language (IL)
Yes. MS supply a tool called Ildasm which can be used to view the metadata and IL
for an assembly.
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.
Yes. Peter Drayton posted this simple example to the DOTNET mailing list:
.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.
10. Implications for 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=682
41
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.
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
]
[
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
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.
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
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".
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.
• 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.
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);
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.3 Internet
The GetResponse method blocks until the download is complete. Then you can
access the response stream like this:
Stream s = response.GetResponseStream();
HttpWebRequest request =
(HttpWebRequest)WebRequest.Create( "http://localhost" );
request.Proxy = new WebProxy( "proxyname", 80 );
12.4 XML
<PEOPLE>
<PERSON>Fred</PERSON>
<PERSON>Bill</PERSON>
</PEOPLE>
Fred
Bill
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.
12.5.2 How do I spawn a thread?
class MyThread
{
public MyThread( string initData )
{
m_data = initData;
m_thread = new Thread( new
ThreadStart(ThreadMain) );
m_thread.Start();
}
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 );
12.5.5 How do I know when my thread pool work item has completed?
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.
Trace.Listeners.Clear();
FileStream fs = new FileStream( @"c:\log.txt",
FileMode.Create, FileAccess.Write );
Trace.Listeners.Add( new TextWriterTraceListener( fs
) );
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:
13. Resources
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.)
13.3 Weblogs
Q1:
For example, version 1.5.1254.0 indicates 1 as the major version, 5 as the minor version,
1254 as the build number, and 0 as the revision number.
Is it possible to do this without having to first compile the C# module (a single .cs file)
into a seperate DLL? I thought that part of the hype about .NET was the fact that you
could easiliy combine 2 or more languages for a single project.
With the .NET toolset you can, but VS.NET doesn't support it directly.
What you want to do is build what's called a multi-module assembly. Each module can be
written in whatever language you want, then you link them all together into a single
assembly.
Unfortunately, VS.NET only supports single module assemblies, so if you want to go this
route you'll need to use the .NET command line tools.
Q3:
I have had a lot of people ask, "How to I ‘disable’ the back button?" or, "How do I
prevent a user from clicking the back button and going back to the previous screen?" In
fact, this is one of the most commonly asked questions on the ASPMessageboard and,
sadly, the answer is quite simple: You CANNOT disable the back button of the browser.
Initially I could not figure why anyone would want or need to do that. Then it struck me
as to why so many people would want to disable the back button. (Not the forward button
mind you only the back button.) When a user submits an application and then goes back
"using the back button" to make a change instead of clicking on "Edit," a new record will
be inserted – we don’t want that, now do we? Again if the user finished a page and then
went back to that page and continued to make changes and saved them we would not
want that either.
So I decided to figure a way or ways to prevent this scenario. I started doing a bit of
research all over the Net going into various sites so basically this article will have a lot
of stuff you might have already read if you looked on the Net. I am just trying to put it all
in one place and find the "best" way of doing it!
One of the many suggestions I got was to prevent the page from being cached. This can
be done with server-side script:
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
%>