Here is an example of the output you can expect from this script:

By default, XML documents produced using C# and the .NET XMLSerializer class are encoded as UTF-16.  I recently needed to change this to the more commonly-used UTF-8, and learned a few things along the way.

The first thing that I discovered (and perhaps should have already known) is that internally .NET stores all string representations as UTF-16.  That is why, if you don’t change the default encoding, the XML is produced as UTF-16.

Next, I found that the Encoding property of the StringWriter class is read-only, so you can interrogate the default encoding (and see that it is in fact UTF-16) but cannot change it. 

As I learned from the blog posts that I referenced above, the solution to changing the default UTF-16 encoding is to subclass the native .NET StringWriter class and override the default Encoding property value.

Following is a solution for producing a UTF-8-encoded XML document.  The “StringWriterUtf8” class is the key to the solution.  It inherits from the native System.IO.StringWriter class and overrides the Encoding property (returning Encoding.UTF8 instead of Encoding.UTF16).  Using an instance of this class as the target for the XML serialization output produces UTF-8 output.

The target audience for this conference was scientists and librarians.  I am a software developer, but am also the lead developer for BHL.  As such, the attendees of the conference were my target users, so it made sense for me to attend and observe.

While attending the conference, I had two technology needs.  First was a way to follow the #LifeLit Twitter hashtag, and second, I needed a way to take a few notes.

To accomplish those goals, I chose to use my Nook Color instead of my laptop.  If you’re not familiar with the Nook Color, it can be considered a “tablet lite”.  While primarily an ebook reader, it runs a variant of the Android operating system and is capable of running apps and playing audio and video. 

I have been skeptical that a tablet can truly be a laptop replacement, particularly for creating content.  Just the same, this conference gave me a perfect opportunity to give it a try.  So, with my Nook Color, I used the Seesmic app to follow Twitter and the EverNote app to take notes.

Here I list the advantages and disadvantages of using a tablet computer.  I say “tablet”, because even though my experience is with a Nook Color, I believe that these apply to all popular tablets (iPad, Nook Color, and the soon-to-come Kindle Fire).

Tablet Advantages

• Instant on – This provided a much better experience than waiting a few minutes for the laptop to boot.
• Battery Life – I charged the Nook Color between day one and day two, but I didn’t have to.  The laptop wouldn’t have made it through a single day.
• Form factor – A light 7-inch tablet is much more convenient to handle than a 5.5 pound 14-inch laptop.

Tablet Disadvantages

• Lack of Multi-tasking – I found it inconvenient to have to exit the Seesmic app whenever I wanted to take a note, and then exit the EverNote app to go back to Seesmic so I could continue following the Twitter feed.
• On-screen Keyboard – I quickly became pretty good at typing with my thumbs on the on-screen keyboard, but I feel that if I had needed to take a lot of notes, then the laptop would have been a necessity.  It’s possible that a larger tablet (like the iPad) might help with this problem, but I’m not sure.

In conclusion, I can say that the tablet worked well.  I’m not convinced that it will be appropriate in all situations, but as a tablet skeptic, I can now admit that there are occasions where a tablet is useful for both consuming (in this case, the Twitter feed) and creating (my notes) content.

The T-SQL Script

I use a T-SQL script to check wait conditions. I don’t remember where I originally acquired this script (I didn’t write it myself), but it has proven to be very useful.  I have confirmed it to work on SQL Server 2005 and 2008.

The script queries the dm_os_wait_stats dynamic management view and performs calculations on the information found there. It outputs a list of the waits are occurring on the server, including the percentage each wait contributes to the total wait time.

Here is the script:

Usage

To analyze the wait conditions on a server, perform the following steps:

1) Open a query window in the SQL Server Management Studio

2) Execute the script

Upon this first execution of the script, you will get little useful information.  Really all the first execution does is populate a temp table with a snapshot of the current wait state of the server (selected from the dm_os_waits_stats view).

3) DON’T CLOSE THE QUERY WINDOW! 

You want to maintain the temp table created by the first execution of the script. 

4) Wait 30 seconds, or 1 minute, or 5 minutes, or 10 minutes (or whatever makes sense). 

The length of time you wait depends on the load on your server.  The heavier the load, the less time you’ll need to wait. 

5) Execute the script again. 

It will select a new snapshot of the server’s wait state from the dm_os_waits_stats view, compare it to the original snapshot stored in the temporary table, and calculate the differences in wait times between the two.  Now the output will accurately show the wait conditions that have occurred since the first time the script was run. 

You can repeat this process as many times as necessary.  As long as you reuse the same the query window (without dropping the temp table), you’ll continue to see the cumulative statistics since the first execution of the script.

NOTE: It is important to first execute this process during a period of normal database usage, so that the baseline wait conditions on the server can be established.  There are always wait conditions occurring, even when a server is under no stress, so it is important to understand what is “normal” for the server.  That way, problems can be more easily identified when the wait conditions deviate from the baseline conditions.

Analyzing the Script Output

There are many different types of waits that might occur.  Here is an example of the script output:

 
On many servers, SQLTRACE_BUFFER_FLUSH will take up the majority of the wait time when the server is under no stress.  That wait type is related to the default server trace that is enabled in SQL Server 2005 and 2008.  Generally, it is a good thing if this wait type is taking up the majority of the wait time on the server.

CXPACKET and SOS_SCHEDULER_YIELD are related to parallelization and CPU usage.  Any sustained increase in wait times for these two wait types indicates CPU pressure.  An increase in PAGEIOLATCH_SH waits indicates IO issues.  Increased CPU and IO waits may indicate a problem with a SQL query, high traffic conditions, or a non-SQL-related server issue.  If waits like LCK_M_IX, LCK_M_X, or LCK_M_S (all generally very low) begin to increase, it is an indication of locking/blocking issues.  Many other wait types are documented here.

Generally, wait statistics will not pinpoint the exact cause of performance problems, but they can be very useful for identifying the areas that need investigation.

This investigation into unhandled exceptions was initiated by a stack overflow exception being thrown in a production application.  That type of error proved to be the most challenging “unhandled exception” to handle, not least because of some incomplete or unclear documentation.

The following examples were tested in an ASP.NET WebForms (yes, boring old WebForms) application compiled with ASP.NET 4.0 and hosted with IIS 7.5 on Windows 7.

One type of “unhandled exception” is an exception thrown by a section of code that is not wrapped in a try-catch block.  These types of exceptions can be caught by adding an exception handler to the Application_Error event in the global.asax file of a web application.

Most ASP.NET developers are familiar with the Application_Error event.  The following example shows an implementation of this event handler that catches and logs unhandled exceptions.  Notice that the InnerException of the Exception is what is actually logged.  This is because the original exception is wrapped in an HttpUnhandledException by the time it is caught by the Application_Error event.

A page with a single button can be used to test the Application_Error error handler.  The code for the button click event is shown here.

Another type of unhandled exception is an error (again not wrapped in a try-catch block) that occurs outside the normal request processing context of the ASP.NET runtime.  An example is an error that occurs on another thread.  An HttpModule that registers an event handler for the UnhandledException event of the current AppDomain can be used to catch such exceptions.

Http Modules are assemblies that are called on every request.  In that respect they are similar to ISAPI filters.  Unlike ISAPI filters, they are written in managed code and are integrated with the ASP.NET application life cycle.  ASP.NET itself uses modules to implement features such as forms authentication and caching.  In regards to handling exceptions, the most important feature of http modules is that can consume application events.

The following is the complete code of a class that implements the IHttpModule interface.  It includes an event handler for UnhandledException events.

To use the HttpModule within a web application, compile it and register the assembly in the web.config file, as shown here.

Testing this error handler is a bit more difficult, because the test needs to show that exceptions that bypass the Application_Error event handler are caught by the HttpModule.  An error needs to be thrown that is not caught by the “normal” ASP.NET error pipeline (for example, the Application_Error event). 

Again start with a single button on a web page.  The click event of the button needs to spawn a thread that throws an exception which is not wrapped in a try-catch block..  Here is the code for the click event.

Because the exception happens on a separate thread, the Application_Error event does not catch it. However, the HttpModule does.

Note that such an HttpModule exception handler will also catch any exceptions that an Application_Error event handler in global.asax will catch. So, an HttpModule exception handler can be used in tandem with an Application_Error event handler , or in place of the Application_Error event.

The final type of unhandled exception to examine is an exception that corrupts the state of the application.  Probably the best-known example of this is a stack overflow.  Because they require special handling, it might seem that exceptions like a StackOverflowException are simply unhandled exceptions that occur outside the normal request processing context of ASP.NET, just as the error in the previous example.  In fact, exceptions that corrupt the state of the application are a different class of exception entirely, and by definition cannot be caught. 

This is true despite conflicting documentation that suggests that http modules can catch such errors, or that the legacyUnhandledExceptionPolicy setting in the aspnet.config file (located in the framework folder) can be modified to allow ASP.NET to handle such exceptions in a legacy manner (i.e. like ASP.NET 1.0 and 1.1). 

Furthermore, some documentation suggests that stack overflow errors can be caught if the block of code throwing the error is decorated with the System.Security.SecurityCritical and System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions attributes.  (This, of course, assumes that you know the block of code throwing the error.)

The following is the codebehind for a page that generates a stack overflow error by calling a recursive function that never exits.  It illustrates the use of the SecurityCritical and HandleProcessCorruptedStateExceptions attributes that are supposed to allow corrupted state exceptions, including stack overflows, to be caught.  The attributes have no effect; the exceptions are not caught by the try-catch block.

In addition, if this page is added to an application that implements the previously discussed Application_Error and HttpModule event handlers, the stack overflow error is not caught.  Even changing the legacyUnhandledExceptionPolicy setting in the aspnet.config file has no effect.  The stack overflow exception is not caught by any of the error handlers.  It seems that all of the documentation that suggests various methods for capturing stack overflow exceptions is incorrect or misleading.

It appears that there is NO WAY to catch and log a stack overflow error.  So, how can a stack overflow exception be “handled”?

The answer is to use the Debug Diagnostic Tool from Microsoft (the latest version at the time of this writing is 1.2).   This tool includes a debugger service that can capture a dump file when a stack overflow occurs.  That file can then be analyzed to find the code that is causing the stack overflow.

Complete configuration and usage details for the Debug Diagnostic Tool are outside the scope of this post.  In brief, the steps to follow to capture a stack trace when a stack overflow exception occurs are:

1. Install the Debug Diagnostic Tool
2. Create a Rule to capture Stack Overflow exceptions and perform a Log Stack Trace action.
3. Run the web application.
4. Run the Debug Diagnostic Tool.
5. Cause the exception to occur.

For more detailed information, see the documentation of the tool here.

When a stack overflow exception occurs, the Debug Diagnostic Tool will capture a stack trace and write it to a log file.  An example of the log contents can be seen here (with the function call that is producing the stack overflow highlighted):

The log shows a stack trace which positively identifies the part of the code that is throwing the error (the StackOverflowWebApp.StackOverflow.Overflow(Boolean) method).

Note that the Debug Diagnostic Tool service is set to start automatically.  This may not be desirable, especially if the tool is only needed briefly to debug a particular error.  Also, the tool seems to affect the performance of the web site being debugged.  Use this tool carefully, especially if it must be pointed at a production web site.

In summary, unhandled exceptions in an ASP.NET application can be caught with an Application_Error event handler in the global.asax, or by creating a HttpModule to catch the AppDomain.UnhandledException event.  An HttpModule is required to catch unhandled exceptions that occur outside the normal processing of requests by the ASP.NET runtime.  For errors that corrupt the state of the application, such as stack overflow exceptions, use the Debug Diagnostic Tool to capture a stack trace at the time of the error.

The complete source code for an application that includes all of the examples shown here is available for download.  Please note that the web site should be compiled and hosted under IIS to ensure that the the error handlers will behave properly.  Running the application in debugging mode from within Visual Studio produces different results than you will see in a production environment.  Visual Studio tries to help handle the errors, but that prevents some of the intended event handlers from working as expected, and does not allow for a complete understanding of how the various error handlers work outside the development environment.

This series does not attempt to give complete accounts of the information presented in each session; it is just a way to capture the bullet points, notes, and opinions that I recorded while attending the conference. I have previously posted a list of all of the session materials and sample code that I have been able to find online, so if you are looking for a more precise account of a session, try looking there.

My favorite presenter at this year’s conference was Steve Bohlen.  He presented at three session; I attended two: “Taming Dependency Chaos with Inversion of Control Containers” and “Refactoring to a SOLID Foundation”.  Both were excellent.  Following are my notes from the SOLID session.

Single Responsibility Principle

There should never be more than one reason for a class to change.  Each class should do one thing.

Open-Closed Principle

Software Entities (classes, modules, functions, etc) should be open for extension, but closed for modification.

Instead of this:

     public class Report
     {
          public void Print()
          {
          }
     }

Use this:

     public class Report
     {
          public virtual void Print()
          {
          }
     }

So that you can do this:

     public class Report2 : Report
     {
          public override void Print()
          {
          }
     }

In this case, the old working code ("Report" class) still works, and we have also added new functionality ("Report2" class).

Liskov Substitution Principle

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. (Polymorphism; important part highlighted)

Instead of:

     public class LetterReport
     {
          public virtual void Print()
          {
          }
     }

     public class TabloidReport : LetterReport
     {
          public override void Print()
          {
          }
     }

Here, TabloidReport overrides a particular kind of report (LetterReport).

Do this instead:

     public abstract class Report
     {
          public abstract void Print()
          {
          }
     }

     public class LetterReport : Report
     {
          public override void Print()
          {
          }
     }

     public class TabloidReport : Report
     {
          public override void Print()
          {
          }
     }

Now, the base class for the reports is truly generic (it’s not a particular kind of report).

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use.

Do not build catch-all interfaces like this:

     public interface IDataAccess
     {
          public void SetConnectionString();
          public void Connect();
          public Data GetReportData();
     }

Instead, interfaces should "build upon" other interfaces, as such (interface composition):

     public interface IDataAccess
     {
          public void SetConnectionString();
          public void Connect();
     }

     public interface IReportDataAccess : IDataAccess
     {
          public Data GetReportData();
     }

Now, classes can select the interface that makes the most sense, rather than getting a single interface with everything.

Dependency Inversion Principle

High level modules should not depend on low level modules.  Both should depend on abstractions.  Abstractions should not depend upon details. Details should depend upon abstractions.

This is where dependency injection and object composition comes into play.  No easy code example to give here.

This series does not attempt to give complete accounts of the information presented in each session; it is just a way to capture the bullet points, notes, and opinions that I recorded while attending the conference. I have previously posted a list of all of the session materials and sample code that I have been able to find online, so if you are looking for a more precise account of a session, try looking there.

One of the better sessions I attended at this year’s conference was Ian Robinson’s “Building jQuery Plug-Ins”.  Too many sessions I attended this year skipped the how-to-get-started and jumped right into examining the code of a finished product.  This session, on the other hand, stepped through the entire process of building a jQuery plug-in.  Here are my notes from the session:

The Process

• Wrap business logic with plug-in logic
• The business logic can stay largely the same
• Modify to inject settings and context
• Modify for safety and to play well with others
  

First step

Wrap in a closure…

(function($) {
     // ahh… safety
})(jQuery);

This structure ensures that our code doesn’t conflict with others (takes it out of global scope and defines the plug-in’s own scope).  It also ensures that when a dollar sign ($) is used in the body of this code, it means jQuery (and not anything else).

http://nathansjslessons.appspot.com/ (What’s A Closure?)

Define the Plug-in

No selecting needed:

     $.fn.myPlugin = function(options) {…};

Select and return (chain):

     $.fn.myPlugin = function(options) {
          return this.each(function() {
               …
          });
     };

Establish Default Options

     $.fn.myPlugin.defaultOptions = {
          speed: ‘slow’
     };

     var opts = $.extend({}, $.fn.myPlugin.defaultOptions, options);

Inject HTML Context

Options aren’t just for settings.

Inject all context through options.  For example:

     $(‘.nav’).myPlugin({
          speed: ‘fast’,
          subNavSelector: ‘li.subnav’
     });

Events

Determine if you need to enforce document.ready.  If not, let the user of the plug-in do it.

If you’re ever unbinding events, bind with a namespace first.  For example:

     $(‘elem’).unbind(‘click.Namespace’, function(){…});

Complete Example

(function($) {
     $.fn.myPlugin = function(options) {
          var opts = $.extend({}, $.fn.myPlugin.defaultOptions, options), $moduleWrap = this;
          // Iterate over all elements contained in the current context ($moduleWrap = ".myClass"???)
          $moduleWrap.each(function() {
               // Grab the element being evaulated
               var $module = $(this);
               … do something …
          })
     };

     $.fn.myPlugin.defaultOptions = { 
          speed: ‘slow’ 
          subNavSelector: ‘li.subnav’
     };

     $(document).ready(function() {
          $(‘.myClass’).myPlugin();
     });
})(jQuery);

More examples and documentation
http://css-tricks.com/snippets/jquery/jquery-plugin-template/
http://docs.jquery.com/Plugins/Authoring
http://jquery.ian-robinson.com (jQuery Crash Course)

This series does not attempt to give complete accounts of the information presented in each session; it is just a way to capture the bullet points, notes, and opinions that I recorded while attending the conference. I have previously posted a list of all of the session materials and sample code that I have been able to find online, so if you are looking for a more precise account of a session, try looking there.

Brad Tutterow presented The Tasty Flavors of Entity Framework 4.1, which introduced the various ways (Code-First, Model-First, and Database-First) to develop with the latest version of Entity Framework.  Here are my (rather brief) notes from the session.

• More information about Entity Framework on Julie Lerman’s blog:  http://thedatafarm.com/blog/
• A very good decision tree for which "flavor" (database-first, model-first, code-first)  of Entity Framework 4.1 to use can be found at http://thedatafarm.com/blog/data-access/model-first-database-first-or-code-first-ndash-update-to-data-points-column/
• The ‘DbContext’ object was added in Entity Framework 4.1, and is the preferred object for interacting with Entity Framework.  Previously, the only option was ‘ObjectContext’.
• If you have existing data access classes that represent your data model, you can use the code-first method for EF.  (This is Interesting… worth trying out to see how it works.  Perhaps offers another way to migrate to EF from existing code.)
• Code-first requires *manual* creation of the DBContext class.  Then, add a connection string with a name that matches the name of the DBContext class.  On the first run of the code-first application, the database will be created automatically.  (Whoa, really?  Will have to think about how this can work in a controlled production environment.)
• With the code-first approach, use the Fluent API if your entities (classes) differ from the data model.

.

This series does not attempt to give complete accounts of the information presented in each session; it is just a way to capture the bullet points, notes, and opinions that I recorded while attending the conference. I have previously posted a list of all of the session materials and sample code that I have been able to find online, so if you are looking for a more precise account of a session, try looking there.

Jeff Ayers presented a session on a very new add-on to Visual Studio, Code Contracts.  I have been reading Dino Esposito’s ongoing series of articles about Code Contracts in MSDN Magazine, and was interested in hearing another perspective on the technology.  The verdict seems to be that the technology is not quite ready for prime-time.  Here are my notes from the session..

• Code Contracts Standard/Premium from Microsoft DevLabs is the Visual Studio plug-in that is needed to enable the technology.  Available from http://msdn.microsoft.com/en-us/devlabs/dd491992.
• Description from the download site: "Code Contracts provide a language-agnostic way to express coding assumptions in .NET programs. The contracts take the form of pre-conditions, post-conditions, and object invariants. Contracts act as checked documentation of your external and internal APIs. The contracts are used to improve testing via runtime checking, enable static contract verification, and documentation generation. Code Contracts bring the advantages of design-by-contract programming to all .NET programming languages."
• An example of a code contract in C# is data validation that that be defined simply by adding attributes to a method or class.
• Looking at the above description of code contracts, an example  "coding assumption" is that an input value to a method will be between 1 and 10.  This would be a "pre-condition" for the execution of the method.  The method is decorated with an attribute that specifies the contract conditions.  The contract conditions are verified via "runtime checking".  The attributes also enable "static verfication" and "documentation generation".
• Contracts are checked at run-time.
• After working with Code Contracts for three weeks, the presenter believes that the tool, while useful, is not completely mature.  The session demonstrations illustrated the difficultly in working with the toolset at the present time.
• System.Diagnostics.Contracts is the namespace to include to gain access to the code contract functionality
• Exceptions of type "ContractException" cannot be caught.  (Perhaps something that will change in the future?)  Instead, you can specify the type of exception to be thrown when a contract is violated.  For example, you can choose to throw an ArgumentException.  Those exception types can be caught as usual.
• Examination of the IL revealed that a lot of additional code is generated by the compiler to handle contracts.  The presenter stated that while good for producing developer feedback, contracts should not yet be included in production builds, at least for object invariant contracts.  It adds too much overhead to a running application, affecting performance.
• The tool does not work for WCF, because the WSDL doesn’t reflect the contract feedback that is so useful to users of the service (developers).

This series does not attempt to give complete accounts of the information presented in each session; it is just a way to capture the bullet points, notes, and opinions that I recorded while attending the conference. I have previously posted a list of all of the session materials and sample code that I have been able to find online, so if you are looking for a more precise account of a session, try looking there.

I took only brief notes in sessions focusing on Objective-C, LINQ, and NHibernate, so I’m combining all of them into this post.

First up is Looking at Objective-C Through the Glass of a Typical .NET Developer, presented by Muljadi Budiman.  This session, on a decidedly NON-Microsoft topic, was filled to overflowing… needed a bigger room for this one.  Perhaps my favorite sound-bite of the conference came from this session… “does anyone think this is NOT weird?”.

• Objective-C is a superset of C, very different from C#
• Each class made up of two files:  header files (*.h) provide an provide interface, and source files (*m) provide the implementation
• XCode is the OSX-based Objective-C development environment
• Classes must be referred to with a pointer syntax.  For example, NSString* instead of NSString, or Person* instead of Person
• Accessibility operators (@private, @public, @protected) are valid only for variables, not classes, methods, or properties.  Because of this, *any* method or property can be overridden.
• In Objective-C, you must allocate (alloc) and initialize (init) objects.  Use "new" to alloc, init, and call constructor.  In addition, objects should be "release" when you are done with them.  If not, the objects stay in memory.
• "Protocols" behave something like interfaces in C#
• There are no static classes.

Next is Deliver Cleaner Code with LINQ to Objects.  Not the best choice of sessions on my part.  The material presented was fine, but it didn’t teach me much I didn’t already know.

• Don’t use "var" just because you can.  Use it when you truly don’t know the return type until run-time.
• When using LINQ, you can use either extension methods or LINQ queries.  Queries are typically easier for developers with database experience, but some functionality is only available via extension methods.
• Extension methods utilize lambda expressions.
• The compiler turns the LINQ query syntax into extension methods.

LINQ Extension Method Example
var list = contacts.Where(x => x.State == "TX").Select (c => c.BirthDate);

LINQ Query Syntax Example
var list = from c in contacts where c.State == ‘TX" select c;

The last couple notes are from Lee Brandt’s session on NHibernate, titled NHibernate, Fluent NHibernate, and the Repository Pattern.  The demos given in this session mostly focused on (relatively) complex completed code.  There was no from-the-start “Hello World” example given.  So while I was able to get a general sense of what it takes to work with NHibernate, I was left with a lot of unanswered questions.

• It looks like extensive up-front work is needed to wire up the database (create mappings, etc)
• Unanswered question:  Is there no way to auto-generate the initial class-to-database mappings?

These links may be useful for future research into NHibernate:

http://wiki.fluentnhibernate.org/Auto_mapping
http://www.fincher.org/tips/Languages/NHibernate.shtml
http://stackoverflow.com/questions/278046/free-nhibernate-helper-tools