This is just too cool:

You can also use a $w to indicate a parameter.  For example:

@msdn2, http://msdn2.microsoft.com/library/\$w

…and then you can type msdn2 System.String – for the easiest way to lookup classes in the MSDN2 library.

[Simon Guest – Off Topic: MSN Toolbar Suite]

The simplest way to describe SQL Service Broker is “message queues in the database.” If the queues are tables in the database then you can do your entire message processing using a local transaction. If you use a separate queuing technology like MSMQ, you can still pull items off the queue, update data in the database and send out messages in the scope of a transaction – it just has to be a distributed transaction. Being able to use a local tx gives us a big performance gain. But, while important, this perf gain isn’t the most compelling reason to use SSB. It turns out that SSB provides important semantic messaging benefits in addition to perf benefits.

If you study at the semantic messaging model defined by message queuing systems such as MSMQ, MQ Series and WS-RM you’ll notice that it is inherently one way. Section 2 of the WS-RM spec defines the reliable messaging model to be between a source sending the messages and a destination receiving them. The problem with this model is that as message patterns between services gets richer, we’re going to want bi-directional reliable messaging. SSB calls this a dialog.

Before you can send messages between services in SSB (assuming everything’s been configured), you first have to BEGIN DIALOG and provide the initiating and target service, plus the message contract (more on that in a later post). Note that it’s called initiator and target, not sender and receiver. Either side of the dialog can send messages to the other as part of the contract by using SEND ON CONVERSATION – the only requirement is that the initiator sends the first message (hence the name “initiator”). All messages are guaranteed to be delivered exactly once and in order, or both sides of the conversation are notified of the failure and the dialog is torn down. I’m not sure if it guarantees in-order delivery of messages in opposite directions. There are cases where this might be important – I send an order cancellation as I send you a shipping notification – but typically there’s a business reason for who “wins” such a conflict. In this shipping/cancellation example, even if you sent me the cancellation before I sent shipment notification, it’s not like I can recall the shipment.

My only issue with this bi-directional reliable messaging is that I’m so used to thinking in terms of one-way RM that it’s taking me a while to wrap my head around it. Many of the sample interactions I come up with are simple patterns where the target simply acknowledges the incoming message. Order processing is a good example where I may get meaningful messages (i.e. not simple acks) coming from both ends. What are some others?

The new MSN Toolbar is now publicly available in beta. The big new feature is the integrated desktop search. I’ve been running internal builds for a while, and I love it. Obviously, comparisons will be drawn to Google Desktop but I can’t comment because Google Desktop wouldn’t run on my machine because I have the Microsoft ISA Server client (according to the Google Desktop Help Center, the latest version of the ISA client should work, but that’s what I was running). However, from looking at the Google Desktop screen shots, I know that Google doesn’t have my favorite feature of the MSN Toolbar – the Deskbar. It’s available via keyboard shortcut (Ctrl-Alt-M) and supports program execution (type “=appname” to launch appname) as well as typing shortcuts. I also like the search results page as I can narrow where my search executes in real time. For example, if I type “OOPSLA” into my deskbar it auto executes the the search across all locations on my desktop. As you would expect, the search screen is near-instant – just the time it takes to draw the window. Then I can narrow down to just show results from Documents, Email, Music, Pictures & Video, Email Attachments, Meetings, Contacts, etc. - in all around 19 different locations. I’m also only one click away from searching the web, news or images online from the search results screen.

Tom sent me a link to Jonathan Wells’ blog entry about the .netcpu:

.netcpu Corporation’s new ‘.NET’ Embedded development kit includes a .netcpu CPU Module, a general purpose microcontroller for programming embedded solutions using C# and the Microsoft .NET Embedded CLR. Use the kit to experiment with projects such as low-power and sensor applications( eg data collection and logging sensor) or create a simple, smart embedded device (eg smart refridgerator, robot or home automation system).

Note the words “Embedded CLR“…i.e. I’m 99% sure this is the same CLR that powers the SPOT watch. Rick Rashid had something in his OOPSLA keynote about this SDK. You can order the .netcpu Starter Kit for $499 or just the CPU module for $199.

I think I need to update my xmas list…

Update: There’s a good technical article about the .NET Embedded on WindowsForDevices.

How about this for transparency?

The Microsoft ASP.NET v1.1 Membership Management Component Prototype contains classes that allow a developer to more easily authenticate users, authorize users, and store per-user property data in a user profile. The authentication feature validates and stores user credentials which a developer can use to manage user authentication on a web site. The authorization feature lets you treat groups of users as a unit by assigning users to roles such as manager, sales, member, and so on. Combined with ASP.NET’s built-in authorization functionality, Windows Shared Hosting developers have end-to-end support for maintaining user-to-role mappings and authorizing users based on this information. The profile feature enables you to provide users of your Web site with a custom experience. By defining and using profile properties, you can track any custom information your application requires, including user information and user preferences.

Important: The functionality provided by this component is a preliminary version of the Membership, Roles, and Profile functionality coming in ASP.NET 2.0 and will change in the final release of ASP.NET 2.0. This means that any ASP.NET v1.1 applications you develop using this component will need to be updated when you migrate to the final release of ASP.NET 2.0. This is also a non Microsoft supported component.

What I love about this the most is that it really reflects a change in mindset. In the past, I doubt we would have shipped this because it is likey to change before release. Personally, I like this approach – ship early and often and be honest about the quality and longevity. Sure, you have to deal with a few people who don’t read things like “will change“ or “not supported“ but the benefits outweigh the issues dramatically.