Jeffrey Richter combines a deep technical knowledge of .NET with a great sense of humour and honesty about where things went bad, to provide a useful overview of what's new in C# 2.0 and .NET 2.0.  I find sessions like this useful in learning the story or intention behind features in the new technology, in a way that helps me understand them better.

The morning session covered an introduction to the new features in .NET 2.0 mostly around generics and anonymous methods.  Seeing some demos on the new yield statement helped me understand more about how it works.  He showed how you could use the yield statement to recursively walk all of the files and directories in the file system.  The demo was simply writing out the paths to the console window and as it was running there were obvious pauses in its performance.  Jeffrey said that these pauses were likely to be due to garbage collections, which highlighted that the ease of use of the yield statement came at the cost of performance (a class was created per directory/file which put a lot of pressure on the working set and garbage collection).  Jeffrey mentioned the C# team have a solution which reduces the performance costs of iterators but it wont ship until after C# 2.0.

He mentioned that another approach to getting the flexibility provided by the yield statement without the poor performance, was to use generics and anonymous methods instead.  For example, many of the generic collection types in .NET such as Array and List have useful generic delegate types, such as ForEach(Action<T>), FindAll(Predicate<T>) as Sort(Comparison<T>). 

As an example, I can sort a list of string types and print them to the screen in just two lines of code using this techniques:

List<string> names = new List<string>(new String[]{ "Timothy", "Benjamin", "Samuel" });

names.Sort(String.Compare);

names.ForEach(Console.WriteLine);

Whilst I've enjoyed these methods before I did enjoy hearing Jeffrey's positioning of these techniques as a pattern to use instead of the yield statement.  Jeffrey also mentioned that Microsoft had received many requests to add richer generic functionality to the generic collection classes.  His company, Wintellect, have been engaged by Microsoft to write these collections and make them available for free download, and they are currently available as the PowerCollection library.  Jeffrey believes that this functionality might eventually be made part of the Framework Class Library in future versions of .NET.

The great thing about Jeffrey's presentation is that draws on his experience as a consultant to the CLR team.  For instance, he mentioned that having different security levels on properties, a 'new' feature for C# 2.0, was originally part of .NET 1.0 Beta 1 but that it was removed since the C# team viewed properties as just a special kind of field.  From this perspective, having a different accessor made no sense.  But as Jeffrey said, after a large amount of customer features, the C# team has put this feature back. it just took them five years.

Jeffrey is also not afraid to mention the things that the CLR team have done badly.  He spoke about the justification for the static class feature of .NET 2.0.  Apparently in .NET 1.0 the Environment class that only had static methods, but late in the beta cycle a developer added a HasShutDownStarted method but forgot to make it static.  On top of this the Environment class had a private constructor so it was impossible for anyone to create a new instance of the Environment class and call this method.  The worst part of this is that it showed that the developer had not written a single test to check the method that he added!  If they had written a single test they would have seen that they could not have compiled the code that tried to write this method.

The session helped me see the benefits in understanding how a particular language feature works, particularly understanding whether it involves the language compiler or involves the CLR.  This knowledge provides the background behind some of the constraints on the features (such as why you can have a catch block inside an iterator).  The tension between the language compilers and the CLR was highlighted in the recent post-beta 2 changes to more fully support Nullable types in the CLR.  Don Box's idea last year was that many of the changes going forward are going to be driven by 'syntactic sugar' using the language compilers, while Jeffrey was more upbeat that there's still innovation happening inside .NET and the CLR.

Jeffrey is razor-sharp technically and very funny.  My favourite comments so was "Indigo loves using attributes.  They use attributes so much that you no longer have to write code"

The afternoon session started with a coverage of partial types, before spending a long time on CLR hosting and how the SQL team helped ensure that the CLR could be hosted in a secure and reliable way.  While Jeffrey is able to explain this stuff really well, it was a hard slog to keep up with the section on Constrained Execution Regions ... so I've nipped off to watch David Solomon and Mark Russinovich's Windows Internals section (or Sysinternals tools seminar as it seems to be).

I did a presentation on Indigo to the VBUG London group last night.  The turn out was pretty good, although it was obvious that many English football fans were missing (though they probably would have enjoyed the User Group more than the humiliating defeat).

Off the top of my head, here are the things that keep standing out for me about Indigo:

• The power of separating choices about the binding from the code that a developer writes.  Being able to switch from the tcp with a binary encoding, to reliable messaging over HTTP, to MSMQ just by changing the configuration file is great.
• The simplicity of the programming model.  The majority of the functionality that required Enterprise Services, such as Instancing and Sessions, are available using attributes on either an interface/class or a method such as ServiceBehavior or OperationBehavior.
• The fact that the details of the protocols are hidden under the covers.  Instead of focussing on the WS-* protocols, the focus is on the functionality required.  This has taken me a while to get my head around after having used WSE, which is powerful, but involved having to understand a lot of the details of the underlying protocols.

I'm looking forwad to some of the Level 400 sessions at the PDC, such as Kenny Woolf's presentation on Channels.

As Mehran noticed, I couldn't help but show off the Refactor! tool that's shipping for free in Visual Basic 2005.  This was in response to an attendee who believed that Visual Studio was 'a multi-megabyte bloated version of notepad'. 

Mike Taulty has a sign-up page for UK PDC Attendee Bingo.  I'm going to be at PDC and it would be great to catch up with others, especially those from the UK.  There's already a very interesting bunch of people heading over from the UK whom I look forward to catching up with.

Strong bodily reactions are a great way to measure the impact of new technologies.  While many US technical conference crowds like clapping when they see new features demoed, I think the best reaction is a more modest bodily reaction. I'll never forget the time I shivered after seeing Eric Gamma demonstrate the Refactoring support in Eclipse a couple of years ago.  One area of .NET 2.0 that is generating strong bodily feedback is ASP.NET 2.0's support for Custom Build Providers.

First there was Fritz dropping his jaw when he created a custom build provider that took his custom XML metadata file which he dropped into the app_code directory that automatically generated the strongly-typed classes for him.  Tonight I discovered that Kirk Allen Evans had a similarly-sized bodily reaction when he created a Custom Build Provider that automatically created XmlSerializer classes that allows you to drop a schema into the app_code directory and automatically generate the XmlSerializer class.

I'm with these guys: Custom Build Providers are cool (bodily reaction: light goosebumps).  I'm passionate about finding ways of driving application development through the use of metadata files and the Custom Build Providers are an innovative way that ASP.NET provides to support this kind of development.  The only downside I can see is that the creation of these classes is slightly 'automagical' and requires that developers understand what the framework is providing under the covers.  However, I think this initial learning curve is more than compensated for by the productivity that Custom Build providers enable.

Kirk Allen Evans has an interesting post about proposing a distributed architecture for a client where he finds, after doing performance testing, that the speed difference between different transports reduces as the amount of work done within each call increases.  Based primarily on this finding he's recommending ASMX web services as a better strategy than using COM+/Enterprise Services for his client.

I remember coming across this arguement at TechEd 2004 in Amsterdam where Christian Weyer spoke about some Thinktecture research which showed that the difference in speed between Web Services and other distributed technologies (remoting, enterprise services/COM+) was significant if the work done in the distributed call was minimal, but once a reasonable amount of work was being done the performance difference became less and less important.  Worrying about the speed of the transport without thinking about the amount of work done in each call is a little bit like worrying how fast a car can rev if you have it in neutral.

Of course, this is all keeping with the long-known guidance from the Indigo team, which is to start with ASMX and only go to other options if you need specific features that they provide.  Richard Turner's recent white paper provides more details.

Save the date - Saturday 22nd October 2005 is the next DeveloperDeveloperDeveloper day!.  We're planning another free community-driven day of talks on developer-related topics.  Craig Murphy has more details.  Jonathan Hodgson has updated the event website (including a countdown ... 84 days to go!).  There's a form you can fill in if you'd like to present a session.

For now, feel free to join in the discussion on the Channel 9 site.

I observed two minutes silence in Trafalgar Square in London today to remember the victims of last week's bombings.  I enjoyed being part of a public display of solidarity by gathering in a large crowd in the streets again.  My thoughts go out to those where were affected by the events.  It was strange experience to be in the centre of London and have relative silence as the only sound was of some vehicle's engines on idle as all of the traffic was stopped.  I felt very proud that London is a place where so many people from different countries, with different religious beliefs can get along together. 

You can see the Kalido offices on the fifth floor of the building shown below (from the BBC News website) and if you looked hard enough you could see me in the crowd.

Bill Wagner, fellow RD, and author of the excellent 'Essential C#' has an article on Code Project that debunks the conventional wisdom that String.Equal is better than Operator == for strings:

... for the string class, Operator == and String.Equal() will always give the same result. Period. You can use either interchangeably without affecting the behavior of your program. Which you pick will depend on your own personal style, and the compile-time types you're working with.

The == operator is strongly typed, and will only compile if both parameters are strings. That implies that there are no casts or conversions inside its implementation.  String.Equal, on the other hand, has multiple overloads.  There is a strongly-typed version, and another version that overrides the System.Object.Equals() method. If you write code that calls the override of the Object version, you will pay a small performance penalty. That penalty comes because there is a (slight) performance hit for the virtual function call, and another (slight) performance hit for the conversion. Of course, if either operand has the compile-time type of object, you'll pay for the conversion costs anyway, so it doesn't much matter.

The bottom line on equality and strings is that if you use the method that matches the compile time types you're working with, you will certainly get the expected behavior, and you'll likely get the best performance. If you want all the details, see Item 9 in Effective C#.

I'm posting this because I've had this discussion a few times and believe that Bill's explanation is the best I've seen.