There is a Code Camp coming to the Mid-Atlantic.

The SiteMap.SiteMapResolve event is set to cause major headaches in ASP.NET 2.0 development. Jeff Prosise talks about the need for the event in a post entitled “Cool ASP.NET 2.0 Programming Trick”. Jeff appears to be taking the wrong approach.

As ASP.NET developers we are accustomed to wiring up events to methods in our Page derived classes. However, SiteMapResolve is a global (defined as public and static) event on the SiteMap class and will fire when resolving a node for any page in the application, not just the subscribing page. Also, we aren’t used to unsubscribing to events in ASP.NET but SiteMapResolve, being a root, will hold on to any references we hand off through a delegate until the universe collapses, or the AppDomain unloads, whichever happens first.

The best solution to work with SiteMapResolve is going to involve a singleton or static class. The best solution I have so far appears to be unfortunately very messy.

There seems to be a surge in ‘recruitment’ lately, but I use the term loosely.

I’ve been receiving emails from strangers like the following:

Subject: I have a C# developer position

Are you interested? If so, give me a call.

Is recruiting just so easy thee days that they don’t even have to try? Isn’t this like writing:

Subject: I have a sex organ

Are you interested? If so, give me a call.

I’d think it would be obvious that a few more minor details, like compensation, location, and type of work, are needed for someone to judge their interest in a sexual organ, but maybe I’m just conservative that way.

I’ve heard complaints about the poor state of example code. Example code, it seems, is ruining programmers across the globe.

Let’s divide the world’s code into two categories: production code, and example code. Much like matter and anti-matter, the two should never meet. They exist for different purposes, and have distinct goals.

The only feature these two have in common is that both production and sample code can be difficult to write. Yes, ask any author – coming up with sample code to illustrate a specific point can be a hair pulling experience. Do I contrive an example to keep the sample as short as possible while getting the point across? Alternatively, do I come up with a “real” example at the risk of complicating the explanation? Like everything else we do, there are tradeoffs to evaluate.

Improving sample code isn’t going to improve the developers of the world. The developer who cuts and pastes from MSDN documentation has other fundamental problems.

Don’t blame bad software on the authors of sample code. Instead, blame the authors of the software.

• Larry Osterman: Concurrency and the CLR.
• The ieBlog tells the tale of an HTTP Detective Story.
• Adam Machanic sees a downward trend in data quality.
• Eric Sink's latest source control HOWTO: Branches.
• Mike Robert's: How To Setup A .NET Development Tree.
• Microsoft Analysis Services widens the lead in OLAP market share.
• Nick points to some posts with insight on how Borland copes in the Microsoft ecosystem.
• STA console applications may have garbage collection problems when COM interop is in play.
• Mosha talks about a free thin client for Analysis Services (with code!).

Thread local storage (TLS) was a fun way to piggyback data into the thread environment block (TEB) in the old days. You can ask each thread in a process to reserve a location to store your special data, say for example, a pointer to a data structure representing a database transaction. No matter where the thread goes, you can always pull the transaction reference out of TLS and go to work – no function parameters required!

The managed equivalent of TLS is the ThreadStaticAttribute class.

Taking advantage of TLS has always been tricky in an environment using thread pooling. As Scott Hanselman and Jef Newsom point out – ASP.NET uses a thread pool, and one has to take extreme care using the ThreadStaticAttribute in ASP.NET. The majority of people asking about using TLS have not really wanted to track a resource associated with a thread, but a resource associated with an HTTP request - which is just what HttpContext.Items is in place to take care of.

I’ll offer up one more reason to avoid ThreadStatic in ASP.NET, and that is the new Async page feature coming in ASP.NET 2.0 (@Page Async=”True”).

Instead of blocking request threads during processing of web service calls to say, Reporting Services, marking an ASP.NET 2.0 Page as Async allows the thread to hop back into the pool and process other requests. When the web request finishes, a thread will return to finish rendering the page. Will it be the same thread? I don’t have proof yet but I would seriously doubt it will be guaranteed. Use TLS and you'll certainly be pooched sooner or later.

There is not a lot out yet about Async pages in 2.0 – I’m interested to see if it will be working in the Feb CTP. Looks like Frtiz Onion has an example up already.

I had some time to research SQL Server 2005 this weekend and ran across the HostProtectionAttribute (HPA).

The ability to write stored procedures and such with your favorite .NET language opens up a dangerous number of APIs, like Process.Start, which can kill a server’s throughput and reliability. The HostProtectionAttribute lets SQL Server look out for dangerous code.

Say we write the following stored procedure:

The above code will compile and deploy into the SAFE bucket of SQL Server without complaint. Execute the proc however, and the host protection kicks in:

Msg 6522, Level 16, State 1, Procedure PureEvil2, Line 1 A .NET Framework error occurred during execution of user defined routine or aggregate 'PureEvil2': System.Security.HostProtectionException: Attempted to perform an operation that was forbidden by the CLR host.

SQL Server doesn’t like our code trying to block a thread. Underneath the covers, SyncLock (VB) and lock (C#) use System.Threading.Monitor. Using Reflector on a v2.0 framework install we can see the Monitor class decorated with a custom HostProtectionAttribute.

SQL Server is looking for the attribute at execution time. Since the HPA can target a struct, class, method, constructor, delegate, or assembly, there must be a bit of overhead involved. I wonder why the verification can’t take place during the CREATE ASSEMBLY deployment?

It will also be interesting to see if the ASP.NET team can take advantage of HPA in the future to keep killer code out of ASP.NET.