We were fortunate enough to have Kenny Wolf from the Indigo team in Atlanta visiting one of our large customers who is doing some amazing work with Indigo. Since he was already going to be in town, I signed him up to speak at the Atlanta MS Professionals user group that was already going on.
Unfortunately, his machine didn’t have Visual Studio on it, so we decided to use my machine. Kenny decided that I would be the code monkey while he talked about the bits. I didn’t have a canned demo, just kind of seat-of-pants coding. I created ASMX, and to drive the point home about how easy Indigo is and how comparable, I was going to convert ASMX to Indigo.
Created the ASMX, changed the namespace, copied the .asmx to .svc… and here was the bonehead move… I copied the code-behind file from the asmx to a new file, service.cs, and didn’t change the class name. When I tried to run the page, it blew up (of course, two classes with the same name). I bailed, created a new service in a new instance of VS 2005, and compared them side-by-side.
Man… that nagged me all day. Flubbed a demo showing how simple it is to move from ASMX to Indigo, when it really is simple.
A couple days later, Kenny was doing a presentation for the same customer, and he showed something about how the .svc indicates that Indigo would handle the request and read its attributes. The customer asked about ASMX and migration, and he said something to the effect of “well yeah, Indigo doesn’t know anything about the ASMX attributes, so you could just leave them there.”
I opened the keyboard and started typing in Visual Studio. In just a couple keystrokes, I had a code-behind that was both an Indigo service as well as an ASMX service.
Kenny shows the resulting double-decorated service. That was a very cool idea, had never occurred to me that Indigo would just ignore the System.Web.Services attributes… makes complete sense, just wasn’t something that sprang to mind.
Since then, I have done that demo (along with a couple additions, like moving the code-behind to another assembly, then hosting the same service in a console and a Windows Service). It makes SO much more sense than the demos I used to do, showing the Calculator examples from the SDK.
And thanks, Steve, for coining the term “double-decorator pattern”.