Wow – I saw this tweet on my feed today:

And immediately hopped over to ScottGu’s blog for this:  Announcing NuPack, ASP.NET MVC 3 Beta, and WebMatrix Beta 2

So much good stuff all in one post!  NuPack, the OSS project for integrating 3^rd party libraries into your code, the Model View Controller update for ASP.NET and the WebMatrix deployment utility.  We are finally entering a golden era for building and deploying web applications without the arduous hassles we’ve had to contend with for so long.  But how cool is it that NuPack is going to ship with Visual Studio?  WOW!

Check out Scott’s blog for details and his links to Hanselman’s, Simser’s, Haack’s and Ebbo’s posts.  A goldmine of information to take your projects to the next level.

A quick reminder:  Say you have a SharePoint Survey List in a site that you want to populate using a console application.  Further, say that said Survey List has an Event Receiver attached to it that needs to pick up settings from the web.config file for the host web app – let’s say a connection string.

You run your console application and notice that nothing is happening – well, something is happening, just not what you intended.  A quick look in the Event Log reveals a bizarre error indicating that an object reference isn’t instantiated and it appears to be originating several lines of code before you make a call to the ConfigurationManager thus:

_connectionString = ConfigurationManager.ConnectionStrings[SQL_CONNECTION_STRING_NAME].ConnectionString;

The line that that is generating the error has nothing whatsoever to do with this line.  It is a puzzling sort of puzzle.

You decide to check first principles and see if you can trigger the event receiver by hitting the list in the browser.  Yup:  Works fine.  So what gives?

Then you remember:  Your console app isn’t running in the same context as the browser app.  Of course it can’t find the <connectionStrings> element – it doesn’t exist as far as it’s concerned.  The called code in the Event Receiver is running blind!

<foreheadSlap> Simply add a {nameOfConsoleApp}.exe.config file local to the console .exe file and stash the configuration settings from the web.config that the called code needs to find. </foreheadSlap>

I knew this, you know.  I was just not thinking clearly while debugging.

Just came across this rather interesting post by “morgan” on the blog PHP vs. .NET in the oft-used “Top x Tools to do Y” format (always popular in the dev community).  Despite being common, I think Morgan’s list is a good compilation of resources that should be in your kit if you’re developing ASP.NET solutions, including SharePoint:

1. Code Profiling – RedGate ANTS – Personally, I use AQTime because it works well with both ASP.NET and SharePoint 2003/2007 instances.
2. App Stress Tool – NeoLoad – Never used it myself, as I’ve preferred to use Visual Studio Team System’s web test projects for this purpose.
3. Performance Monitoring – perfmon – But of course!  You can also hook up VSTS to track performance counters and record results – this feature has been available in Visual Studio since 2005, and offers a better way of visualizing this critical operational data.  Mind you, if you are on a server and just need to see what’s what, perfmon is still the standard.  Looks even better on 2008!
4. HTTP Recorder – Fiddler 2 – No arguments here.
5. Interface Manipulation – FireBug – Definitely one of the best browser add-ons;  I use it interchangeably with the IE Developer Toolbar.
6. Debugger -Windbg – This is a given;  if you’ve never used it, give it a whirl:  It’s a great tool.
7. FX-Cop – For policing the standards to keep the code clean;  it’s worthwhile, even if you’re a one-man show.
8. ViewState Decoder – A good idea for ASP.NET and SharePoint apps – Sometimes ya gotta see what’s going on in that mess of stateful info on your page.
9. Text Editor – UltraEdit/Notepad2 – I prefer the latter – to each their own.  I definitely like being able to bring up a lightweight editor with syntax highlighting, regex patterns, hotkeys and shortcuts, etc.

Morgan also offers up the venerable .NET Reflector by Lutz Roeder – a staple if you’re developing against the SharePoint API since the documentation can be at odds with reality.  It’s great to be able to crack open Microsoft.Sharepoint, find your object and see how it works in disassembled C# or VB.NET or any other .NET language.

I’ve noticed some Google queries in my referrer’s log lately from folks looking to maintain their users’ scroll position after a postback.  This is a “classic” ASP.NET issue, and one that wasn’t handled very well in .NET 1.1 with an IE-specific page directive (somewhat ironically-named “SmartNavigation”) that kacked most of the time and caused sites to lock-up.

‘Good news is that under 2.0 this has been resolved with the MaintainScrollPositionOnPostback page directive which is designed to automagically track your user’s position on the page and snap right back to it after a round-trip to the server.  Here’s how I implemented this for dasBlog’s CommentView.aspx page:

When a user enters a comment to a post and fills out the reCaptcha challenge words, after postback the page will move to show the last comment entered.

How does it work?

Basically, by injecting some client-side Javascript that associates the web form’s OnSubmit handler with a function that’s supplied in the WebResource.axd library that tracks the user’s X/Y position on the page, and then restores it after postback.  For a deep-dive on how the MaintainScrollPositionOnPostback directive works on the client and server side, see Scott Mitchell’s piece on the 4Guys site, Client-Side Enhancements in 2.0.

Update: Dino Esposito has posted a top-notch article about the new MVC architecture on his blog.

Some anonymous bloke has done an simple writeup on the MVC pipeline lifecycle, complete with PDF diagram – it’s all very preliminary since we haven’t even really seen the CTP, but it’s a good way to check out what the intended implementation/architecture looks like.

In a couple of words, “this rocks”. 

I’m quite impressed with the design – total separation of concerns and a clean implementation of the MVC pattern to decompose the functional elements and make them completely extensible – all you need to do is implement an interface like IControllerFactory, for example, and Robert’s your father’s brother – instant inversion of control support.

This is really a cool technology that has the positive potential to completely upend how we think about ASP.NET applications in the future.  I for one welcome our new MVC overlords…