It’s been a wild ride for the last 5 years. We’ve seen the best - what about the worst?

1)Visual Basic.NET

The problem isn’t with the language – VB is a great language, and I’m not formulating my “best and worst lists” based on technology virtues alone, but on the “experience”.

The controversy over Visual Basic.NET started before the product’s release date. Then came the salary surveys, the misinformation, disinformation, statistics, lies, videotapes, benchmarks, whining, moaning, and gnashing of teeth.

The debate over the merits of this language seem to be in an infinite loop.

Bill Vaughn is right: Microsoft should have named the new language B#. Same language – different name – it would be a success story.

2)Managed C++

Being a former C++ __type myself, I investigated the __new managed __extensions. __For some __reason I could __never __warm __up to the __syntax. I hear^ there are^ some changes^ in store^ for 2005.

3) Tight Coupling of Visual Studio to IIS

With an ASP.NET project, have you ever…
… had the wwwroot$ share disappear?
… wrestled with front page server extensions?
… seen an entire folder disappear?
… tried to put the project under source control?
… tricked Visual Studio into thinking the project isn’t really a web project?
… built the project with an automated build engine? No - no - without Nant!
… debugged as non-admin?
… been unable to open a web project?
… seen a ‘web access failed’ error message?
… had a problem moving a web project from one computer to the other?
… created a web application without admin privs?

This too shall pass in 2.0

4) IDisposable

If I had a dime for every time the intricacies of IDisposable were explained in newsgroups, mailing lists, conference halls, chat rooms, bathrooms, and blogs – I’d buy myself a Formula One race car, and drive it 6 days a week on my own private racetrack.

Then to find out there is special case reference counting in the framework...

5) Smart Clients

Despite all the hype – smart clients seem to have gained very little traction in the 1.x timeframe. Smart clients are once again poised to take the world by storm with Click-Once deployment in 2.0. Where has the love been for the HREF EXE? Do you think we can write an application like World Wind with AJAX?

The above opinions are my own, and do not necessarily represent the viewpoints of anyone else I know.

Given that .NET 1.x is entering legacy status before the end of the year, I thought it might be fun to explore the best and worst of what .NET developers have lived through for the past 5 years.

First: the best.

1) Metadata

Metadata is the lifeblood of the common language runtime. Just think of the number of features made possible (or made better) by the presence of metadata: garbage collection, form designers, code access security, and verification to name a few. The fact that metadata is extensible through custom attributes opens up a world of possibilities. Sure, we might have gotten tools like NUnit and Reflector without metadata, but they might have really sucked.

2) Visual Studio

The multilingual IDE does web, windows, and mobile development, too. If you face being stranded on a desert island with a Windows machine, AC power, and broadband access, but can install only one piece of software on top - take Visual Studio. Given enough time, you can write the rest. (What piece of software would you write first?).

Again, extensibility plays a huge rule in the success of Visual Studio. If you haven’t worked with one of the many great VS.NET ad-ins in Scott Hanselman's Ultimate List, you just haven’t lived.

3) Community

When people like Chris Brumme spend their time waiting at the dentist writing deep technical blog posts like “TransparentProxy”, then you know times are changing. When I'm at the dentist I usually hide behind large, potted vegetation reading National Geographic, pretending I’m somewhere else, and hoping they forget I’m there, but everyone handles thier phobias differently.

Besides blogs, we have an explosion of webcasts, chats, user groups, code camps, and geek dinners. There is no time to shower or pay bills - submerse yourself now in the world that Scoble built.

4).NET Class Libraries

Every non-trivial framework has the occasional bump in the road, but let’s not talk about the System.DirectoryServices namespace while we are in a good mood, ok? The usability, intuitiveness, and discoverability of the libraries have played a large role in the adoption of .NET and the productivity of .NET programmers.

5) The Common Type System (CTS)

The CTS lays the foundation for not only C#, C++, and Visual Basic to work together, but a slew of other languages (see former Bon Jovi look-alike Jason Bock’s .NET languages list). No small feat, the CTS. It’s a rewarding experience being able to jump into a new language with foreign syntax but still have some bearing as to what is happening underneath.

Next up: the worst. Don't miss this one.

What would you include in the “best of” list?

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.

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.