Adventures in HttpContext

UPDATE: This post is outdated since ASP.NET MVC Beta.  Use the DependencyResolver static class instead.

Read More

Updated 3/21/2011:

Now with twitter and oauth support. See the latest update

Read More

Over the past couple of years there has been a slow progression in the .NET web app world to fully separate out client/server interaction.  Long gone are the horrible days of ViewState and Events; MVC provided a nice step to better structure web applications for powerful Web 2.0 experiences.  But the barrier between client and server interaction has never really been clean-  MVC markup has always been littered with C# code and there hasn’t always been widespread tools available to easily build desktop class applications in the browser.  Sure, spark and haml provide alternatives, but these are essentially make a core problem easier to bear.

Read More

I hereby propose renaming ASP.NET MVC to just “.MVC”. It’s just so much easier to type.

Performance is one of the most important, yet often overlooked, aspects of programming.  It’s usually not something you worry about until it gets really bad.  And at that point, you have layers of code you need to sift through to figure out where you can remove bottlenecks.  It’s also tricky, especially on complex, process orientated systems, to aggregate performance information for analysis.  That’s where this gist for a utility performance tracer class comes into play.  It’s meant to hook into Enterprise Library Logging Block by aggregating the elapsed time or information statements and pass them to the Event Log (or other listeners you’ve hooked up).  Even though the gist is designed for the Enterprise Library, it can easily be modified for other utilities like Log4Net.  Below is an example of how the entry looks in the EventLog. Read More