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

New Blog Engine

The other day I got sick and tired of the fact that I didn't have labels on my entires... sure Blogger Beta allows for that, but you have to be on their server to use it (and understandably so). So last weekend I wrote my own blog engine in .NET 2.0. Sure I could have used a pre-built one (like DasBlog), but I kinda like the level of control I get from using things with my architecture and my coding style. Yes, I know that's a ridiculous and somewhat arrogant excuse, but I really do like to have it in my own architecture and design even if own as a training tool I can use in the future.

Anyhow... the new system has been up for a few days and if you see any weird behavior on it (like a blog entry link taking you to the homepage or whatever), please be assured that I get a notification e-mail about the problem and will quickly look into it. I'm still considering it in "beta".

With the new blog engine you can access labels to view various entires at once as well as see articles by month by going to http://www.netfxharmonics.com/year/month/ like http://www.netfxharmonics.com/2006/10/.

There are various other nice internal features too, like the ability for each entry to have more than one URL. Some of my blog entries are actually linked via different links, so that's something that is definitely important to me.

Oh, how did I do that you ask? HttpHandlers! These ASP.NET pieces of goodness are great. My entire blog is really just one public page: default.aspx (plus the internal supporting user controls, masterpage and clientside JavaScript and CSS pages). There isn't really a link called http://www.netfxharmonics.com/2005/12/video-1-fwd-setting-up-your-firefox.aspx. When ASP.NET sees that URL being requested, the HttpHandler parses it and sends the information off to the default.aspx page which then looks up the blog entry data (via an adapter which then accesses LLBLGen) and sends that data back to the client who thinks that's a real page (even Google indexes it as a real page).

Another cool thing is something I mentioned before: each page can have more than one url. So, for example, the following two URLs show the same data (via a simple lookup in a table which contains the URL names).

As far as tracking, I did throw in a simple tracking system so I can log all traffic via IP address, session, and many other things. I really only did that so I can watch myself go through the site for debugging purposes. My REAL tracking is done via the awesome Google Analytics service which I have been using since it's release. I even have it on all the e-commerce sites we host at the office (replacing WebTrends!). Google Analytics is awesome. Google is awesome!

This weekend I'm going to be builtng in a Atom/RSS creation system that will give a feed to FeedBurner for the RSS subscribers to see (if you aren't using FeedBurner to serve your feeds, you really should--it abstracts the URL from your site so you can change your REAL feed location all you want and it gives you great stats as well). I'm actually going to implement my IAP (doesn't really stand for anything) engine which allows developers to dynamically create report templates and RSS feeds declaratively. We also use this at the office... it's actually really cool. It's not only an RSS server, but also an RSS aggregator. So, at the office, we use my IAP engine in the company portal to show blocks of information (they are simply RSS feeds shown via a custom ASP.NET control like ). So... implementing the new RSS system should be really simple.

As far as a client... I think that the web is kind of a hassle for client work. Personally I've grown to hate it. Back in the day I was all about web applications. I thought they were so cool, but I'm all about smart clients now. So, I wrote my blog editing application in WPF which, naturally, communicates with the server via WCF. The interface was rather simple to build in WPF as WPF it has the the advantages of WinForms with regard to simplicity and the power and awesome control tree model of ASP.NET. Great stuff...

The internal database is SQL Server 2005 Express. I swear... that thing is so cool. I've been using it for some time now and I have to say that I SO don't see myself ever needing the standard edition. Even at the office we don't need the standard edition for most of our databases (our CRM system needs standard for it's 60GB database, but other than that... Express works great). Oh... and YES, LLBLGen Pro 2.0 is the data access layer. That thing is so awesome.

As far as hosting. I love abstraction and delegation, so I don't see myself ever doing self-hosting. That said, I'm always looking for the best deal. That doesn't mean LOWEST price. "Best deal" in my situation is a metric of many factors. So, I use CrystalTech's dedicated web hosting for hosting the site (as well as MANY others) and I use the same box for my development work as well. It may just be a Celeron, but I have 1GB of RAM it in with everything I need. I can do anything from WPF to WF to WCF to Atlas on this thing. Granted I have to work with my own DNS and IIS configuration... but, serious, if you can't do that, you shouldn't even be in the biz.

I think that covers most everything. So, if you see something weird in the system, I can almost guarantee that there was an internal exception thrown and that I was notified of it with detailed in information of the failure.

Brad Abram's Presentation

Anyone who knows me knows I'm an architect and designer at heart... every time I see construction work I just stare at it and study how everything is being planned. Heck, I learned much of software architecture from watching Discovery Channel's Extreme Engineering. I love the stuff... ergo, Brad Abrams is my hero. His work is astonishing. As far as I'm concerned he is the glue that kept the BCL together.

Everyone NEEDS to check out his latest presentation on design guidelines. This is some good stuff. Usually I think PowerPoint is a mind numbing waste of time, but this presentation is great. By the way, if you don't OWN the design guidelines book by Krzysztof Cwalina and Brad Abrams, YOU NEED TO. If you never looked at it, please stop writing code today.

Check it out...

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;

    public Node ChildNode {
        get {
            if (node == null) {
                node = new Node( );
            }
            return node;
        }
        set { node = value; }
    }
}

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

    static void Main(string[] args) {
        try {
            ProcessNode(new Node( ));
        }
        catch (StackOverflowException ex) {
            Console.WriteLine(ex.Message);
        }
        catch (Exception ex) {
            Console.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.

StackOverFlowException

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) {
        Console.WriteLine(ex.Message);
    }
}

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...

[Serializable]
public class SalesOrderException : Exception
{
    public SalesOrderException( ) {
        Environment.FailFast(String.Empty);
    }

    // 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).

Powered by
Python / Django / Elasticsearch / Azure / Nginx / CentOS 7

Mini-icons are part of the Silk Icons set of icons at famfamfam.com