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.

I'm on the Ask The Experts stand here at TechEd (back tomorrow and Wednesday at 2pm) and the first person I spoke to today asked me how to solve a socket access permission when using a when using a tcp service with WSE 3.0 Tech Preview.  Working through this also answered a second common question people have, which is 'what's the default port number that WSE uses when "soap.tcp://localhost/" is specified as the service address?'.

The exception in questions was:

An attempt was made to access a socket in a way forbidden by its access permissions.

This occurred when I was trying to run the TCPStockService sample application and here are the key lines:

Uri address = new Uri("soap.tcp://localhost/tcpstockservice");
// This starts a TCP-based listener if there isn't one already started.
SoapReceivers.Add(new EndpointReference(address), typeof(StockService));

Digging through reflector it turns out the the constructor of the Microsoft.Web.Services3.Messaging.SoapTcpTransportOptions options sets the defaultPort:

So, 0x1f91 in Hex turns out to be 8081 in decimal, so by default the WSE tcp transport listens on port 8081 if no port is specified.  Now the exception message made more sense, since I had another application listening on port 8081.  Changing the port number, or stopping the process that was listening on port 8081 solved the problem.

Thanks to the MSDN Product Feedback centre I can send a suggestion to improve this error reporting straight through to the product team.

It's been a long time since I last posted.  I've been busy with a mix of presentations, work and life, such as:

• Helping Kalido ship version 8 release 2 of their two core products, the Kalido Dynamic Information Warehouse and the Kalido Master Data Manager. 
• Speaking at the Microsoft UK Architect Council and Architect Forum about Services on the Microsoft Platform today.  You can find the slides on the Connected Systems Architect forum page.
• Presenting to the London .NET User Group on Programming Indigo.
• Facilitating a 'park bench panel' on Smart Client vs Web Development at the Microsoft UK MSDN Roadshow in London.
• Doing plenty of behind-the-scenes or out-in-the-community work with local User Groups.

Some technical topics that have been taking my time:

• We set up CruiseControl.NET in my team at Kalido.  This just rocks.  It monitors source safe for checkins, checks the code out, runs a Nant script (these are great: you can compile the code using a solution file (instead of hassling with the vbc.exe or csc.exe directly) to build the code, then it runs our NUnit tests as well as providing coverage reporting with NCover and even duplicate code checking using Simian.  It all comes together with a tray icon that monitors what's happening on our build server and lets the whole team know if a build fails.  Tracking down the reason for failure is easy since there's a central web page that pulls together the log file from all of the tools (including comments from the source safe checkin box - finally, an easy way to see these comments!).  It's so exciting I'm rambling even while blogging about it.  The key point for me was that it only took one developer a couple of days to set up, even with no previous experience of any of these tools.
• Schema design.  I'm working on a new WSDL interface and have been playing around with various strategies to build the interface most efficiently and effectively.  More on that in future posts.
• Consolas.  Like Scott Hanselman, I love this font.  I've embarrassed myself my gushing about this to colleagues who are less aesthetically inclined than I am.  It's a mono spaced font, which is part of the Longhorn font set, especially designed for reading code on screen.  I've also set it up as the Windows Console Font as well.

I've also been enjoying time with my daughter who's now walking, starting to 'talk' and generally just getting into trouble (I spent last Saturday morning in the accident and emergency section of the local hospital after a walking accident.  The doctor said 'ah, we always see a lot of head injuries from kids who've just learnt to walk').