2005 2006 2007 2008 2009 2010 2011 2015 2016 2017 2018 aspnet azure csharp debugging docker elasticsearch exceptions firefox javascriptajax linux llblgen mongodb powershell projects python security services silverlight training videos wcf wpf xag xhtmlcss

C# 3.0 Features at MSDN Nuggets

The MSDN Nuggets website has just released a TON of awesome videos about new C# 3.0 features. Personally I love the stuff they are doing with the LINQ project. It's going to make the awesome C# 2.0 language even more powerful and flexible.

The site also released a cool video about how to get Vista's glass to work in your apps. By the way, if you're interested in the workflow foundation, there are a ton of videos on that as well.

Here are the videos...

The Uncatchable Exception

There's once aspect of exception handling that I've found that many seasoned .NET veterans know about. Take a look at the following code…

class Node {
    private Node node;

<span style="color: rgb(0,0,255)">public</span> <span style="color: rgb(43,145,175)">Node</span> ChildNode {
    <span style="color: rgb(0,0,255)">get</span> {
        <span style="color: rgb(0,0,255)">if</span> (node == <span style="color: rgb(0,0,255)">null</span>) {
            node = <span style="color: rgb(0,0,255)">new</span> <span style="color: rgb(43,145,175)">Node</span>( );
        <span style="color: rgb(0,0,255)">return</span> node;
    <span style="color: rgb(0,0,255)">set</span> { node = <span style="color: rgb(0,0,255)">value</span>; }


class Program { static void ProcessNode(Node node) { ProcessNode(node.ChildNode); }

<span style="color: rgb(0,0,255)">static</span> <span style="color: rgb(0,0,255)">void</span> Main(<span style="color: rgb(0,0,255)">string</span>[] args) {
    <span style="color: rgb(0,0,255)">try</span> {
        ProcessNode(<span style="color: rgb(0,0,255)">new</span> <span style="color: rgb(43,145,175)">Node</span>( ));
    <span style="color: rgb(0,0,255)">catch</span> (<span style="color: rgb(43,145,175)">StackOverflowException</span> ex) {
        <span style="color: rgb(43,145,175)">Console</span>.WriteLine(ex.Message);
    <span style="color: rgb(0,0,255)">catch</span> (<span style="color: rgb(43,145,175)">Exception</span> ex) {
        <span style="color: rgb(43,145,175)">Console</span>.WriteLine(ex.Message);


Code Segment 1

What do you figure the output will be? Well, most people say the output is something like "Operation caused a stack overflow." That's a nice guess, but this exception thrown from the CLR is actually not catchable. This is the uncatchable exception. It actually jumps directly outside of your try block and shuts your application down. What you actually see is what's in the below figure.


Figure 1

The CLR does not allow you to have infinite loops in your applications at all. So much so in fact that it will literally kill your entire application to make sure you follow the rules.

Now, if you're thinking about it... you may be think "CLR threw it? Hmm... I wonder... I read something about the ability to throw things that aren't exceptions". So, you may be tempted to try this...

try {
    ProcessNode(new Node( ));
catch {
    Console.WriteLine("Unknown exception");

Code Segment 2

This actually doesn't help the situation at all. Actually, if you've read my previous blog entry on the RuntimeWrappedException, then you would know about the .NET wrapping plan. Under .NET's default rules, thrown objects which do not inherit from System.Exception are wrapped in an instance of RuntimeWrappedException. So, even if the exception thrown was one of those, it would have been caught by the original code anyhow.

This StackOverFlowException application failure is actually a very helpful rule the CLR enforces. It forces you to go back and make sure you don't have a recursion bug in your code, because this is not really a user-specific exception it's literally a bug in your application. So, before you throw a fit when you see this, just go back and find the bug in your recursion code.

It's important to note however, that there's nothing inherently special about the StackOverFlowException itself. Take a look at this code...

static void ThrowStackOverFlowException( ) {
    throw new StackOverflowException( );

static void Main(string[] args) {
    try {
        ThrowStackOverFlowException( );
    catch (StackOverflowException ex) {

Code Segment 3

This time your output really is "Operation caused a stack overflow.". So, if you throw it yourself you can catch it. The uncatchable exception isn't really StackOverflowException, but rather the CLR's throwing of the StackOverflowException.

There are other ways to completely kill an application. One of the more subtle of ways is via use of System.Environment.FastFail(String message). This static method will immediately kill and application and will not be caught by any catch blocks anywhere. So, if you really want to screw up an application simply do the following...

public class SalesOrderException : Exception
    public SalesOrderException( ) {
<span style="color: rgb(0,128,0)">// More constructors go here...

Code Segment 4

Now every time your application has a SalesOrderException, it will explode into pieces. There's absolutely no way to recover from this. The above code is something that a disguntled employee would love to check in.

That said, looking at it in another light, Environment.FastFail(String) can actually be a great debugging tool. For example, say you have an application that is just downright giving you some weird output. You have no idea why. You know it's wrong, but there are just no exceptions bubbling to the surface to help you out. Well, if you have access to Visual Studio 2005's Debug->Exceptions... menu item, you can actually tell Visual Studio to allow you to see those first chance exceptions. If you don't have that, however you can put Environment.FastFail(String) in an exception, and use deductive reasoning and process of elimination to find out where your problem in.

You may actually be wondering "What is the point of Environment.FastFail(String)?" It's actually quite useful for anyone severely uptight about security or someone withing really low level in a system. If you're absolutely sure there's an unrecoverable corruption in your system, then you can call this method to kill this application. Basically what you're doing is "blue screening your application". The operating system is untouched, but you application is gone. Another situation someone can use Environment.FastFail in in security situations. If you absolutely need to verify some piece of security for the application to continue at all (i.e. you don't want anyone to catch an exception you throw and continue insecure), then you can use this method to "bluescreen" the app.

Troelsen's COM and .NET Interoperability Book

Now this is cool… Andrew Troelsen's book "COM and .NET Interoperability" is FREE in e-book format at apress.com (click on Free E-Books under one of the headings). I highly recommend this book to anyone who wants to either continue to use their current COM components in the .NET world or for people who want to use their .NET abilities in COM-based technologies.

Many times I hear people say they would have to need for this. Well, let me give you some ideas of what I do at the office. Every now and again the web developer at the office will get overloaded with work and it will bubble up to the architect (me!) Well... the older websites are all in classic ASP and while I spend my share of time in the trenches with classic web application development, there is NO way I'm going to do any VBScript development. (heck, even back then I did most of my work in PerlScript!)

My solution is simple: .NET to COM interop. Most of my work is done in .NET and I just expose the interfaces to COM. You really think I'm going to consume a web service with manual XML structures in VBScript? Uh... think again.

By the way, for those web services I consume and expose to COM I wrote my own web service consuming framework (because so many people expose COMPLETELY INVALID services to the world in pseudo-"SOAP" that .NET won't get near it). I then expose these new "services" to the COM world via component services. Oh yes, the book has an entire chapter just on serviced components (COM+ Interop).

XHTML 1.1 Escaping (Chapter Excerpt 3)

One thing you will inevitably notice when working with the ultra strict XHTML 1.1 is how the ampersand (&) works. In HTML you never had to worry much about the ampersand, though you could use it to implant an HTML space (&nbsp;). Now given that XHTML is XML, you simply can't get by with the rules of HTML. In the XML world, if you want to save an XML document with an ampersand, then you have to escape it. If you are familiar with C-based programming languages, then you know all about special characters like this. In those languages you have to "escape" certain characters such as the backslash (), with another backslash.

In fact, in Altova's XMLSpy application you will get a stopping warning if you have XML that looks something like <b>&</b>. The appropriate way to have an ampersand in XML is to write it as &amp;. This is very similar to what you could do with the   space in HTML and it's not that far off from what we already do. For instance, if you wanted to write &nbsp;. In fact if you want to write &amp;nbsp; you have to write &amp;amp;nbsp. So, if you know HTML, you already know the fundamentals of this rule. It's just that in the strict world of XHTML 1.1, you can no longer let little mistakes enter your code.

Now this rule about dealing with ampersands doesn't end with standalone ampersands, but also applies to ampersands in links. For instance, you can't just have a link like default.aspx?id=3&category=5. Your link has to transform to default.aspx?id=3&category=5.

Fortunately ASP.NET 2.0 is smart enough to deal with things like this in your databinding. For instance, look at the following code…

ASP.NET 2.0 Code

<asp:GridView ID="gvLinks" runat="server"></asp:GridView>

Code Behind


String[] links = new String[] { "http://jampad.net/default.aspx?id=1&name=2", "http://jampad.net/default.aspx?id=1&name=2&frog=3", "Amburgers & Wootbeer" };
gvLinks.DataSource = links;
gvLinks.DataBind( );

Believe it or not, ASP.NET will output produce the following...

<table cellspacing="0" rules="all" border="1" id="gvLinks" style="border-collapse: collapse;">
        <th scope="col">Item</th>

While I'm not a big fan of looking at table code, I am however a huge fan of automation. As you can see here, you don't have to fight with manually escaping data binding ampersands. Thus, you can give ampersands in XHTML data binding a vote towards deterministic.

XHTML 1.1 and DataBinding (Chapter Excerpt #2)

When doing serious data binding in ASP.NET you may want to reconsider using XHTML 1.1 or XHTML 1.0 Strict at all. The rule is simple: use the document type that can be deterministicly proven to be proper in your situation. Put another way, unless you have deterministicly proven that there will never be any invalid markup in the data, you should always use XHTML 1.0 Transitional.

If the binding data has some odd markup, then you will end up sending invalid XHTML 1.0 sent to IE breaking validation or sending invalid XHTML 1.1 markup to browsers such as Firefox, halting the rendering.

But what does it mean to be deterministicly proper? To put it simply it means to absolutely garuntee that the data will always be proper, that is, to be able to always predict the properness of data. This does not mean "well, it worked for 100,000 tests, so it's good enough", but rather it means that it absolutely will always work 100% of the time. You can get this level of determinism by looking at the symantics of what is going to be bound. For example, if you are binding a table with numbers, which will always be numbers, then you should have a level of determinism here. However, if you are binding a table with unvalidated under input, then you do not have determinism as you have no idea what a user will input. The user could input <b><i></b></i>, which will break the page. You have no idea. Having a proven, not demonstrated, view of data is what this is all about.

Here are a few guidelines that should help you with determining what is and not deterministic.

These things are never deterministic...

  • Unvalidated user input
  • Unvalidated external data
  • HTML
  • Anything else with angle brackets (<, >), except wellformed XML

Given symantical care, these things should be deterministic...

  • Wellformed XML
  • Alphanumeric strings
  • Base64 encoded data
  • Alphanumeric strings

To reiterate: only use the document type that is deterministicly proven to always be proper.

Excerpts from my XHTML 1.1 Chapter

One of the great things about XHTML 1.1 is that you are never allowed to serve it's content as text. You can send every type of XHTML 1.0 as text all day long, but never XHTML 1.1. You say you never send as text anyhow? Sure you do… that's what the text/html content-type is all about. The default for every web server (that I know of) is to send "browser" content (i.e. HTML, XHTML) as the text/html content-type. To use a different content-type you have to specifically say so.

The typical way to send XHTML 1.1 content is actually with the application/xhtml+xml content-type. To server a page using this type in .NET, you simply state the following in the early parts of your .NET page rendering (at the Init or Page events).


Response.ContentType = "application/xhtml+xml";


Response.ContentType = "application/xhtml+xml"

When you do this, you kick modern web browsers, like Firefox, into what I like to call "parsing mode", "ultra strict mode", or "application mode" depending on my mood, but what it really is is XML parsing mode. In my lectures I often say "HTML is fundamentally unparsable". What I really mean is "HTML is fundamentally unparsed". That is, browsers tokenize HTML (via scanning), rather than parse it via XML parsing. Not to say that web browsers parse XML per se, but they could fundamentally do so it they wanted to. XHTML is XML and therefore "XHTML is parseable". Kicking modern web browsers into this ultra strict mode actually forces the browser to parse the page in an XML centric manner. What's this mean? It means that if your XML (XHTML) is not well-formed, it will throw an error. It's important to note that when you are in this ultra strict mode, the browser is not a validator (that would be REALLY cool), but is more of a well-formedness checker and is the closest things we have to a runtime compiler (which, I know, seems like an oxymoron.)

So, why do this work to get this ultra strict mode? For one simple reason: QA! Quality assurance requires that you take your work seriously. You can't just throw together a bunch of pages and throw them out on the web. If you were writing C#, C++, or Java you would be forced to run your code through a compiler to check for errors. By using ultra strict XHTML mode, you again get this forced compliance.

One word of caution...and it's a common word of caution. Gosh, no matter what I say or what I do on the web it always seems to be the same word of caution: this doesn't work in IE! This is because IE, by default, has absolutely no idea what application/xhtml+xml is. If you try to send this type of content to IE, it will probably try to download the file locally. Now there are times when it will load fine, but what usually is happening in these cases is that the content type is specified in the Windows registry to tell IE how to render it. Since we are talking about the web here, and not the Intranet world we have to follow the universal rules of the W3C, ECMA, and...well least common modern denominators (I throw the word modern in there just in case anyone wants to say that Netscape Communicator 4 is the LCD...and for the record, I don't care about any 4th generation browsers.)

So we need to make sure that IE doesn't get this ultra strict content type. Consequently, we won't have ultra strict mode in IE. Now, if you're paying attention at all you will notice that we have a page with at least two content-types required to support two different planets of browsers (IE, the rest of Earth). You can't send two at the same time. Not a problem. All we need to do is whip out a quick condition based upon what the browser can and cannot do.

When it comes to server-side browser detection some people like like to rely on the UserAgent string of the browser. This is actually a very bad idea due to how easy it is to modify a browser's UserAgent string (especially in IE with all the IE toolbars out there!). I actually read somewhere where someone said that "using the UserAgent is the fastest way to hell" I'd have to go along with that hyperbole.

Here's what you really do: test if the browser can accept the application/xhtml+xml content-type. If they can use it, use it. If not, don't. That's all there is to it, but before I get into the code there's one more thing. We're not talking just about the content-type here, were also talking about the document type (the DTD). If the condition comes back negative, that is, it does not accept xhtml+xml, then you can't use XHTML 1.1 either. So you also have to control the content-type nad the document type in the same shot. This is also not a problem.

Here's a standard method I use in the pages I want to be in ultra strict mode.

In the ASP.NET page, I replace the doctype with the following.

<asp:literal id="litDoctype" runat="server"></asp:literal>

Now in the code-behind I do the following...


Boolean debugMode = false;
private void SetDoctype( ) {
    Boolean mimeTypeOverride = false;
    if (Request.QueryString["xhtml"] != null && Request.QueryString["xhtml"] == "1") {
        mimeTypeOverride = true;
<span style="color: rgb(43,145,175)">Boolean</span> realBrowser = <span style="color: rgb(0,0,255)">false</span>;
<span style="color: rgb(0,0,255)">if</span> (Request.ServerVariables[<span style="color: rgb(163,21,21)">"HTTP_ACCEPT"</span>] != <span style="color: rgb(0,0,255)">null</span> || mimeTypeOverride) {
    <span style="color: rgb(43,145,175)">String</span> httpAccept = Request.ServerVariables[<span style="color: rgb(163,21,21)">"HTTP_ACCEPT"</span>];
    <span style="color: rgb(0,0,255)">if</span> (httpAccept != <span style="color: rgb(0,0,255)">null</span> &amp;&amp; httpAccept.IndexOf(<span style="color: rgb(163,21,21)">"application/xhtml+xml"</span>) &gt; -1 || mimeTypeOverride) {
        realBrowser = <span style="color: rgb(0,0,255)">true</span>;

<span style="color: rgb(0,0,255)">if</span> (realBrowser &amp;&amp; !debugMode) {
    Response.ContentType = <span style="color: rgb(163,21,21)">"application/xhtml+xml"</span>;
    litDoctype.Text = <span style="color: rgb(163,21,21)">""</span>;
    litDoctype.Text = <span style="color: rgb(163,21,21)">"\n"</span>;
    litDoctype.Text += <span style="color: rgb(163,21,21)">"\n"</span>;
<span style="color: rgb(0,0,255)">else</span> {
    Response.ContentType = <span style="color: rgb(163,21,21)">"application/xml"</span>;
    litDoctype.Text = <span style="color: rgb(163,21,21)">"\n"</span>;


Dim debugMode As Boolean = False
Sub SetDoctype()
    Dim mimeTypeOverride As Boolean = False

    If Request.QueryString("xhtml") <> Nothing And Request.QueryString("xhtml") = "1" Then
        mimeTypeOverride = True
    End If

    Dim realBrowser As Boolean = False
    If Not (Request.ServerVariables("HTTP_ACCEPT") Is Nothing) Or mimeTypeOverride Then
        Dim httpAccept As String = Request.ServerVariables("HTTP_ACCEPT")
        If Not (httpAccept Is Nothing) And httpAccept.IndexOf("application/xhtml+xml") > -1 Or mimeTypeOverride Then
            realBrowser = True
        End If
    End If

    If realBrowser And Not debugMode Then
        Response.ContentType = "application/xhtml+xml"
        litDoctype.Text = ""
        litDoctype.Text = "" & vbNewLine
        litDoctype.Text += ""
        Response.ContentType = "application/xml"
        litDoctype.Text = ""
    End If
End Sub

This code is actually longer than you might expect, but this version is a bit more robust than a simple condition. The first to notice about this code is obvious: it checks to see if the browser can accept the application/xhtml+xml content type by checking the HTTP_ACCEPT server variable. Depending on the result, the browser either gets application/xhtml+xml content type and the XHTML 1.1 doctype or text/html content type and XHTML 1.0 Transitional.

Secondly, as you can also see, I've included a debug mode which, if set to true, will tell the page to serve the "less-strict" doctype. This comes in handy when you want to make sure you get the "less-strict" doctype. I'm using a private class boolean field named debugMode as a means to put the entire page into debugMode. You could also use a query parameter to put just this one part into debug mode.

Finally, you can see something rather odd towards the beginning of the code. Even though we are doing all of this to guarantee well formed XML, this does not in any way give us any information about validation. That's where this other part comes in. If you were go point the W3C validator at this page it would actually get the XHTML 1.0 Transitional doctype with the text/html content-type. That's all well and good for validating against that doctype, but you technically have two different versions of the same page here. You need to validate against the XHTML 1.1 version as well. So, with the inclusion of a quick query parameter check I'm allowing for the ability to give the W3C validator a Url such as default.aspx?xhtml=1 which will force the page to be in XHTML 1.1 mode. This is a little easier than always having to tell the W3C validator the XHTML 1.1 override (I never much liked the warning it gives you anyways when you do it their way anyhow). As I mentioned previously, you could use a similar technique for for it into the "less-strict" mode. One idea would be to set default.aspx?xhtml=0 to kick in "less-strict" mode.

Base64 PNG Server

In my mind, one of the coolest things tht modern web browsers can do is deal with base64 PNG images. PNG images are the "new standard" in web images. They can be very small in size or they can be larger as true color images depending on your needs. They don't replace everything, but they do replace a lot.

A base64 PNG image is a PNG image encoded as base64. Base64 encoding is a way to encode non-printable characters (stuff you can't see, but the computer can read) into printable characters (things like letters and numbers).

Base64 PNG images (which are text) can actually be read by modern web browsers as real images. In fact, it's one of my qualification requirements for being a modern web browser (actually there are MANY requirements in my mind). You can actually use base64 PNG images directly in CSS. Here's an example...


Well, it's not SUPPOSED to be small! It's supposed to be embeddable. And it is. But think for a moment. You can take an image (not just PNG mind you, GIF can do this as well) and turn it into Base64. Now, can't you dynamically load images on the client? Well, yes you can... All you have to do is do a remote call to somewhere which will send the Base64 stream back.

One you get the stream back all you have to do is prefix the base64 stream with "data:image/png;base64," and assign the entire value to the src property (attribute) of an img object.

Here's an example I put together a few months ago of how you can do all this... Firefox users only please! IE6 won't get NEAR base64 images.

PNG Client/Service Example

Actually, this is also a great example of how to work with web remoting (I just CAN'T call it Ajax, that's too weird) and how to dynamically work with XML files.

'+' sign in e-mails

Announcement: Plus signs in e-mail addresses ARE VALID! I can't tell you how many time I went to a blog, a forum, or a (poorly design web…)store and my e-mails didn't pass validation. On some blogs I even get ASP.NET exceptions.

Plus signs in e-mails are commonly used for sub-addressing. When you have an e-mail like help@gmail.com and you don't want to give that to a webstore you can simply hand out help+nospam@gmail.com or help+Amazon@gmail.com or whatever and you're still good.

So PLEASE... if you wrote a buggy application or script that disallows '+' in e-mail addresses, fix your bugs.

User Control Error: The base class includes the field 'xxx', but its type (yyy) is not compatible with the type of control (zzz).

I'm not a huge user of user controls, but today I was porting an ASP app over to the real world and I figured the particular scenario I was working with didn't really warrant the power of a server control. So after I went an took the 12 seconds out of the day to create a user control all was well. It was working beautifully and all that jazz…until I published the website to the test server!

The base class includes the field 'cltFemaleItems', but its type (Items)
is not compatible with the type of control (ASP.items_ascx).

WHAT!!!! I'm marking this one as an ASP.NET 2.0 bug. After a bit of searching online I realized that there aren't really ANY workarounds to this online.

I went back and read the message again and noticed this small hint: "( ASP.items_ascx)". Below is what my user control class declaration looked like and what the declarative directive looks like. Everything looks fine...

<%@ Control Language="C#" AutoEventWireup="true" CodeFile=" Items.ascx.cs" Inherits="Items" %>

public partial class Items : System.Web.UI.UserControl

Based on the error message hint, however, changed the name of the contro. Here is what I changed the above code to...

<%@ Control Language="C#" AutoEventWireup="true" CodeFile"Items.ascx.cs " Inherits="items_ascx" %>

public partial class items_ascx : System.Web.UI.UserControl 

Then I republished and viola! All it well... That's one really weird ASP.NET 2.0 bug. Anyhow, this workaround seems to work well.

"Common Language Runtime detected an invalid program"

If you've ever gotten this error you've probably been one of the most confused people in the world. In your debugging you may have seen that this message came from an InvalidProgramException.

Well, while this problem should be rare, here's an example harness of where you may see it.

// ThrowerHarness.cs
namespace ThrowerExample
  class ThrowerHarness
    static void Main(string[] args)
            Thrower.Start( );
        catch (System.Exception ex)
            System.Console.Write("Error: " + ex.Message);

Alright, so where's it coming from?

In this case, it's actually coming from the IL.

// Thrower.il
.assembly ThrowerLib { }

.class public Thrower {
  .method static public void Start( ) {

This actually comes from invalid IL. In this case I'm putting 0 on the stack and then throwing...well, nothing really. This is not something a good compiler would create. If you see this it's probably a bug in the compiler or manually written IL.

Anyhow, to test the above do this...

ilasm /dll ThrowerLib.il
csc /r:ThrowerLib ThrowerHarness.cs