Earlier this month (Dec 2/09) the Director/Product Manager for SharePoint, Arpan Shah, posted a wealth of resources on his blog to aid in ramping up on the new platform.  I encourage going over and taking a look – and add his feed to your aggregator.  Here are some of my favourites:

White Papers – The closest thing to “books” before the release next year:

SharePoint 2010 Overview Evaluation Guide 
SharePoint 2010 Professional Developers Evaluation Guide 
SharePoint Server 2010 Evaluation Guide for IT Professionals
SharePoint 2010 and Office 2010 Scenarios

When to use ASP.NET vs. SharePoint:

SharePoint Server 2010 as an Application Development Platform 
SharePoint 2010 Developer Platform

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.

Get them here.

I could relay the yadda-yadda on the virtues of applying the SPs, but I figure that’s being done to death out there already by more capable folks.  Ok, I’ll toss this bit of verbiage in:

1. SP1 advances the art of application development

The new ADO.NET Entity Framework feature in SP1 offers developers a model-based paradigm and a rich, standards-based framework for creating data-oriented applications shared across multiple applications and platforms. The separation of presentation, data, and business logic used in concert with a single data model will enable developers to spend less time writing plumbing code and more time refining business logic.

2. SP1 makes data-driven programming easier

SP1 offers developers support for ASP.NET Dynamic Data, which provides a rich scaffolding framework that enables rapid data-driven development. Since ASP.NET takes care of creating the presentation layer, a fully functional Website is output and ready for customization without the developer writing a single line of code. Furthermore, with ADO.NET Data Services, Web developers can create RESTful Web 2.0-style applications that have better server scalability and improved caching support.

3. SP1 is the fastest and easiest way to deploy Windows applications

With the .NET Framework Client Profile, a small subset of the Framework that powers client applications, developers can offer their end users a dramatically streamlined and rapid application download experience. In addition, improvements in SP1 result in dramatic reductions in cold start times, allowing developers to serve a broader set of customers with varying hardware profiles.

Via dotNetSlackers, an all-too-familiar story: If only we'd used ANTS Profiler earlier... we would have had a shot at the $2 million cash prize!.  The familiar part is how code profiling seems to always be a last consideration for developers – not the $2M part, obviously!

Written by a member of the Princeton DARPA Grand Challenge Team (the competition where entrants build driverless vehicles that must successfully negotiate a pre-set course), the post describes how an apparent “memory leak” in their .NET code was causing their test vehicle to literally crash:

We were unique among the teams in the finals, in that we used stereo vision, as opposed to scanning lasers, to detect and range obstacles. All in all, we wrote 10,000 lines of C# code to drive the cars.

In the finals, we ran for 9 miles before succumbing to a memory leak in the obstacle-detection code. Actually, most of our code is written in garbage-collected C#, so it wasn't a memory leak per se, but it wasn't until two weeks later that we discovered the true problem.

The nature of the problem?  Objects that while “deleted”, still maintained subscriptions to events, thus causing their heap to blow chunks.  How did they figure this out?  By profiling their code to see how it was working in real-time:

One of our team members downloaded the 14-day trial of ANTS Profiler, and we ran it on our car's guidance code. We profiled the memory usage and saw the obstacle list blowing up. How could this be? We called "delete" on those old obstacles! To our amazement, it was only minutes before we realized that our list of detected obstacles was never getting garbage collected. Though we thought we had cleared all references to old entries in the list, because the objects were still registered as subscribers to an event, they were never getting deleted.

We added one line of code to remove the event subscription and, over the next three days, we successfully ran the car for 300 miles through the Mojave desert.

Definitely a testament to the power of profiling!

Personally, I prefer AQTime to ANTS as the latter in my experience doesn’t profile SharePoint applications very well – if at all.  It also has an array of reports and dashboards that I like, eg. callgraphs, top-10 hit counts, longest methods to execute (with and without children) and more.  Nonetheless, it’s well worth trying the free versions of each on your own code to see how they work and what you prefer. 

To me, profiliers are the best investment you can make in your tools, outside of an IDE and refactoring aids.

Update:  'Seems I'm not the only one who's excited about the TDD potential that ASP.NET MVC opens up.  Phil Haack is already all over this one with his post Writing Testable Code Is About Managing Complexity.

I’m trying to curb my enthusiasm here, but I’m excited after reading this first part of ScottGu’s in-depth coverage on his team’s upcoming ASP.NET MVC Framework that we can expect to see in VS2008.

What’s got me really keyed-up is the potential that the MVC model will give us for unit testing web applications.  I could care two figs about the latest syntactic sugar that the product teams think we all want – they’re useless if I can’t do TDD (test-driven-development) and CI (continuous integration) against them.  And ASP.NET web apps have been public enemy #1 for most attempts to unit test – witness: SharePoint.

Here’s how Scott sees TDD happening under MVC (emphasis mine):

…part of what makes an MVC approach attractive is that we can unit test the Controller and Model logic of applications completely independently of the View/Html generation logic.  As you'll see below we can even unit test these before we create our Views.

The ASP.NET MVC framework has been designed specifically to enable easy unit testing.  All core APIs and contracts within the framework are interfaces, and extensibility points are provided to enable easy injection and customization of objects (including the ability to use IOC containers like Windsor, StructureMap, Spring.NET, and ObjectBuilder).  Developers will be able to use built-in mock classes, or use any .NET type-mocking framework to simulate their own test versions of MVC related objects.

The striking thing I see out of all of this is that Scott is envisioning an entirely new way of advancing the development paradigm:

1. ASP.NET MVC incorporates a best practice design pattern that’s long been known outside of our camp and one we’ve really wanted;
2. It’s taking some positive cues from our Ruby on Rails bretheren (eg. Models, Views and Controllers folders, ease of testing);
3. It is an alternative to, not a replacement for standard ASP.NET webforms – you can quite happily live in a coding cave if you wish;
4. You may use integrated MSFT technologies for testing and dependency injection, or use what you like, eg. NUnit, xUnit, Windsor, etc.

I like this.  I like this a lot.  I’m also hoping to hell that the higher-ups don’t foul this up for the rest of us – ScottGu’s on the right wavelength here and I’m really impressed he’s advancing so far with this.