In .NET 2.0 the CLR allows unhandled exceptions in threads to proceed naturally - which in many cases probably means that the application will terminate. For certain cases (listed below) where exceptions are used for controlling program flow, the CLR does provide a backstop for unhandled exceptions in threads. Note, the CLR terminated the threads in these cases and does not propagate the exception further.

• Abort() is called causing a ThreadAbortException.
• AppDomain (in which the thread is running) is being unloaded, causing a AppDomainUnloadedException.
• The Host process (or CLR) terminates the thread via an internal exception.

This is a significant change from .NET v1.x where there is no concept of a Unhandled Exception in many situations such as a Thread pool. If an unhandled exception is thrown, the runtime prints that to the console and then returns the thread to the thread pool. Also, if an unhandled exception occurs in the Start() method of a Thread class, the runtime again prints the exception stack trace to the console and then gracefully terminating the thread. Lastly, if an unhandled exception occurs on a Finalizer thread, the trace is written to the console, and the finalizer thread is allowed to resume!

Needless to say, if you have code currently designed for this, it will break in .NET 2.0 and you would need to change your implementation. As a temporary workaround you can choose your app to still use the old style from v1.x by setting the flag in the runtime section, but this should be strictly till such a time you can port the code over to the new version:

If you are new to this, one of the classes I would recommend reading up on is called ExecutionContext class. This class essentially is the equivalent of the COM Apartment (from the good old COM days). This class provides a single container for all information relevant to a logical thread of execution which includes security context, call context, synchronization context, localization context, and transaction context. You cannot change context of the thread (to which a ExecutionContext is attached), you can only copy it to another thread. If you do try and copy it you will get an Exception.

Here is an example from MSDN on how to use this (also testing the new CopyAsHTML Addin):

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158

using System;
using System.Threading;
using System.Security;
using System.Collections;
using System.Security.Permissions;
using System.Runtime.Serialization;
using System.Runtime.Remoting.Messaging;

namespace Contoso
 {
     class ExecutionContextSample
     {
         static void Main()
         {
             try
             {
                 Console.WriteLine("Executing Main in the primary thread.");
                 FileDialogPermission fdp = new FileDialogPermission(
                     FileDialogPermissionAccess.OpenSave);
                 fdp.Deny();
                 // Capture the execution context containing the Deny.
                 ExecutionContext eC = ExecutionContext.Capture();
 
                 // Suppress the flow of the execution context.
                 AsyncFlowControl aFC = ExecutionContext.SuppressFlow();
                 Thread t1 = new Thread(new ThreadStart(DemandPermission));
                 t1.Start();
                 t1.Join();
                 Console.WriteLine("Is the flow suppressed? " +
                     ExecutionContext.IsFlowSuppressed());
                 Console.WriteLine("Restore the flow.");
                 aFC.Undo();
                 Console.WriteLine("Is the flow suppressed? " +
                     ExecutionContext.IsFlowSuppressed());
                 Thread t2 = new Thread(new ThreadStart(DemandPermission));
                 t2.Start();
                 t2.Join();
                 // Remove the Deny.
                 CodeAccessPermission.RevertDeny();
                 // Capture the context that does not contain the Deny.
                 ExecutionContext eC2 = ExecutionContext.Capture();
                 // Show that the Deny is no longer present.
                 Thread t3 = new Thread(new ThreadStart(DemandPermission));
                 t3.Start();
                 t3.Join();
 
                 // Set the context that contains the Deny.
                 // Show the deny is again active.
                 Thread t4 = new Thread(new ThreadStart(DemandPermission));
                 t4.Start();
                 t4.Join();
                 // Demonstrate the execution context methods.
                 ExecutionContextMethods();
                 Console.WriteLine("Demo is complete, press Enter to exit.");
                 Console.Read();
             }
             catch (Exception e)
             {
                 Console.WriteLine(e.Message);
             }
         }

         // Execute the Demand.
         static void DemandPermission()
         {
             try
             {
                 Console.WriteLine("In the thread executing a Demand for " +
                     "FileDialogPermission.");
                 new FileDialogPermission(
                     FileDialogPermissionAccess.OpenSave).Demand();
                 Console.WriteLine("Successfully demanded " +
                     "FileDialogPermission.");
             }
             catch (Exception e)
             {
                 Console.WriteLine(e.Message);
             }
         }
 
         static void ExecutionContextMethods()
         {
             // Generate a call context for this thread.
             ContextBoundType cBT = new ContextBoundType();
             cBT.GetServerTime();
             ExecutionContext eC1 = ExecutionContext.Capture();
             ExecutionContext eC2 = eC1.CreateCopy();
             Console.WriteLine("The hash code for the first execution " +
                 "context is: " + eC1.GetHashCode());
 
             // Create a SerializationInfo object to be used for getting the
             // object data.
             SerializationInfo sI = new SerializationInfo(
                 typeof(ExecutionContext),
                 new FormatterConverter());
 
             eC1.GetObjectData(
                 sI,
                 new StreamingContext(StreamingContextStates.All));
 
             LogicalCallContext lCC = (LogicalCallContext)sI.GetValue(
                 "LogicalCallContext",
                 typeof(LogicalCallContext));
 
             // The logical call context object should contain the previously
             // created call context.
             Console.WriteLine("Is the logical call context information " +
                 "available? " + lCC.HasInfo);
         }
     }
 
 
     // One means of communicating between client and server is to use the
     // CallContext class. Calling CallContext effectivel puts the data in a thread
     // local store. This means that the information is available to that thread
     // or that logical thread (across application domains) only.
     [Serializable]
     public class CallContextString : ILogicalThreadAffinative
     {
         String _str = "";
 
         public CallContextString(String str)
         {
             _str = str;
             Console.WriteLine("A CallContextString has been created.");
         }
 
         public override String ToString()
         {
             return _str;
         }
     }
 
     public class ContextBoundType : ContextBoundObject
     {
         private DateTime starttime;
 
         public ContextBoundType()
         {
             Console.WriteLine("An instance of ContextBoundType has been " +
                "created.");
             starttime = DateTime.Now;
         }

         [SecurityPermissionAttribute(SecurityAction.Demand, Flags = SecurityPermissionFlag.Infrastructure)]
         public DateTime GetServerTime()
         {
             Console.WriteLine("The time requested by a client.");
             // This call overwrites the client's
             // CallContextString.
             CallContext.SetData(
                 "ServerThreadData",
                 new CallContextString("This is the server side replacement " +
                 "string."));
             return DateTime.Now;
         }
     } 
 }

For System.Transactions there is also a maximum transaction timeout. It is designed to be used by the System Administrator to limit transaction timeouts. If this setting is not specified, it defaults to 10 minutes.  It cannot be overridden in code.   If the app.config timeout or the timeout specified in the constructors above exceed the maximum timeout in the machine.config, the timeout is adjusted down to the maximum timeout value. That can be specified only in machine config.  To change that you would specify the maxTimeout property of the machine settings section.  For example, this specifies 30 seconds:

So, for example if your app.config setting specifies a defaultSettings timeout of zero, which implies (with a screwy sort of logic) infinite timeout, or if your application code specifies a zero timeout in one of the constructors, then the actual timeout of the transaction will not be infinite - it will be bound to the setting for machineSettings maxTimeout.

For any high-throughput transactional server, The default maxTimeout setting is probably not right for you.  You’re going to want to set this pretty low.

This is for any transaction managed by DTC - that would include transactions involving SQL Server, Oracle, MQ, DB2, and so on.  If your transactions are timing out after 10 minutes and you want to know why, check these settings.

[Listening to: I Am - Bon Jovi - Have A Nice Day (03:54)]

[Listening to: Boy in the Well - R.E.M. - Around the Sun (05:22)]

• Tips for making programming in the .NET CF environment easier
• Tricks for making your Pocket PC-based apps run faster
• Important .NET CF classes
• .NET CF windowing issues

If you do development on the CF then this is good article to read up on. As they conclude “Writing applications for the .NET Compact Framework is a wonderful experience. The applications are small enough that shareware developers can once again write something on their own and sell it online to make a little bit of money. But the simplicity and small capacity of mobile devices present new challenges to programmers. Without awesome power, you have awesome responsibility. Strive from the get-go to design code that is fast, tight, and highly, highly disposable.”

More Information:  http://tinyurl.com/6xvsl

If you rather get to it yourself, then there is an wsdl endpoint exposed and Stripe has written a version that is proxy friendly . If you happen to be a Delphi.NET (strange as that might be) kind of guy or gal, you can get the check out Shenoy’s implementation of this.

After installing the add-in you can right-click in the source code to see the following two menu items:

Clicking on the first item opens a dialog allowing you to enter the signature e.g.:

[Listening to: City of Blinding Lights - U2 - How to Dismantle an Atomic Bomb [Bonus Track] (05:48)]

In Whidbey, the name of the .snk file is included as a property on the project and is picked up my msbuild when compiling.  To get to it:

• Right-click on the project in the solution explorer and select Properties.
• Click on the Signing tab.
• Provide the path to the .snk file.

How is it done today? As Bruce reminds us (and I verbatim here) signing assemblies in VS2003 and earlier meant adding attributes to the AssemblyInfo file, something similar to the following.

[assembly: AssemblyKeyFile("..\\..\\ObjectSharp.snk")]
[assembly: AssemblyDelaySign(false)]

But there are a couple of issues associated with these attributes.  First, the path to the key file is actually embedded in the assembly.  If you use a full path, it is possible that information about your machine (servers and directories, for example) can be easily extracted by using ildasm.  Not overtly dangerous, but not the best situation.

Also, providing a relative path to the key file is annoying.  I’m sure most of you have dealt with the trial and error of finding exactly where the .snk file is relative to the compilation directory.

Finally, because compilation cleanliness is important to all of us, keeping the AssemblyKeyFile attribute in AssemblyInfo generates a warning message.  Not always critical, but annoying.

The key takeaway to remember for shell extension in addition to the COM Interop basics is the Win32 data types (constants, structs, enums, etc.) that need to be imported. You specify how do you want the type layout - either sequential or offset based - which one you would of course base on the structure of the COM data type.

If you have not played with Interop till now, then I would recommend reading up on the COM Interop tutorials first and trying out some simpler stuff. Also in Longhorn, the shell is running managed code, so there is no interop involved.

• Pocket PC and Smart Phone Development
• MSDN
• Getting Started with .NET CF

The beta2 includes:

• ECMA CLI-based virtual execution system.
• Java VM: allows Java and .NET code to run side-by-side. It contains the latest release of IKVM.
• Optimising compiler for x86, PowerPC, SPARC and S390 based architectures.
• Just-in-Time (JIT) and Ahead-of-Time (AOT) compilation modes supported.
• A new, faster interpreter for the above platforms and also for StrongARM and HPPA.
• Support for Linux, MacOS X, Windows, Solaris and HP-UX operating systems. C# 1.0 compiler.
• Development toolchain.
• API documentation browser, with Wiki-like capabilities.
• Embeddable runtime: make your application scriptable and extensible with C# or any other .NET language using our embedding API.

The following are in preview and not supported at this time, but from my interpretation of the read, should be out soon after Whidbey ships (for some of them):

• Preview C# 2.0 compiler with generics support (gmcs).
• Generics-enabled virtual machine.
• System.Windows.Forms.
• Mono Basic compiler.

It is important to note that some key pieces are also missing which one should keep in mind when deciding when to do pick a framework:

• COM support of any kind in Unix or Windows.
• EnterpriseServices is only a set of stub routines.
• Windows.Forms is only available as a preview, and it is not meant for production use.
• Code Access Security (CAS) is not supported: missing in the runtime and class libraries.

I personally would be interested in seeing what the implementation of Remoting, Web Services and the Garbage Collection would be. While we are on the topic, if you have not then check out Rotor implementation by Microsoft which runs on Windows XP, FreeBSD and Mac OS X 10.2. I used a very early implementation of Mono (more than a year ago) when there was not much one could do, I need to take out some time now to play with this now, but was curious to know what your experience has been or if you are thinking of using this, is so how?