Ok, so the question in the title a little misleading... I actually know why it's abstract, but what I don't understand why it was designed that way. It forces me to always subclass it and add my own methods, decorated with SoapMethodAttribute, just so I can send a SoapEnvelope from client to server.

What's lame about this is that all the information I need to send is in the SoapEnvelope already. I shouldn't need to pass it through some special method decorated with one attribute to set the SOAP action. I understand that this design is intended to simplify the strongly typed approach that Microsoft seems to be pushing, but if I've got an XmlDocument rarin' to go I should be able to just construct a SoapEnvelope set it up myself and pass the DocumentElement to SetBodyObject. The problem now is, there's no easy way to make a call to a Request-Response style web method. You can send a SoapEnvelope one way easily using a SoapSender's Send, but uhh... that unfortunately leaves you without a response. You can also receive a SoapEnvelope easily using SoapReceiver's Receive. The fact that you can't SendRequestResponse with SoapClient without subclassing it (because it's protected) just seems like a silly design decision.

In the end, I end up with a a class like this:

public sealed class MyWebServiceClient : SoapClient
{
    public MyWebServiceClient(EndpointReference endpointReference) : base(endpointReference)
    {
    }

    [SoapMethod("uri:SomeService:SomeMethod")]
    public SoapEnvelope DoSomething(SoapEnvelope requestEnvelope)
    {
        return base.SendRequestResponse(“DoSomething“, requestEnvelope);
    }
}

To call it like this:

XmlDocument document = new XmlDocument();
document.Load("somefile.xml");

SoapEnvelope envelope = new SoapEnvelope();
envelope.SetBodyObject(document.DocumentElement);

MyWebServiceClient client = new MyWebServiceClient();
client.DoSomething(envelope);

What did writing the proxy really buy me in this case? The following call that I could have written myself much more easily:

envelope.Context.Addressing.Action = new Action("uri:uri:SomeService:SomeMethod");

Chris Sells continues his Avalon based solitaire application by delving deeper into the databinding architecture of Avalon. My favorite part of the sample is his use of data transformers. They're really powerful because you can basically bind to any type of data, stick the transformer in the middle and let it interpret it how ever it likes... even transforming it a completely different type!

I don't know what kind of following there is for MotoGP amongst the developer community, but since motorcycle racing is one of my hobbies it's my favorite sport to watch. Valentino Rossi has just clinched the 2004 championship over rival Sete Gibernau in an AMAZING race at Phillip Island. Rossi only needed to place second and could have just sat back and settled, but he's such a warrior that he fought with Gibernau to wrestle the GP win away in the very last lap. Absolutely amazing!

Rossi, only 25, has won the past three championships. At the end of last year he did something that shocked the MotoGP world: he jumped ship from Honda to Yamaha. Rossi is now only the second champion to switch manufacturers and win championships back to back, the only other being Eddie Lawson.

Was f'n hilarious. Another one where the whole audience was laughing out loud the entire time. If you're into raunchy, side splitting humor it's a must see.

The cat's out of the bag and the word is spreading like wildfire: Microsoft has added Edit and Continue to C# for VS2005.

The VS/Framework developers are really knocking me over with their support for the community these days. I mean, I've always had good relationships with them and been able to affect minor features via feedback in betas I've participated in, but never have I seen something of this magnitude take place.

That said, I don't honestly believe Edit and Continue would have been worth holding the release of the product up over. People seem to make a really big deal out of it... as if VS.NET should not even bother coming out if it doesn't add the feature. While it's a nice feature to have for a limited range of simple inline fixes, I could easily live without it.

I've dealt with this before, but I'm bumping into it again so I figured I'd blog about it to vent a little...

If you implement IXmlSerializable to customize the output of your type when it partakes in XML serialization, you can't even decorate it with XmlRootAttribute. This basically means that if your type is the root of an object graph that needs to be serialized you have to explicitly pass an instance of XmlRootAttribute to the XmlSerializer via a constructor overload. Umm... what if I want to just deal with IXmlSerializable types abstractly? How do I know what the heck I'm supposed to setup for the root attribute? It needs to be the right element name in the right namespace or else it won't result in a valid instance document.

It's like whoever designed the code-path for IXmlSerializable support within the XmlSerializer just decided that: “Hey, they shouldn't use the serialization attributes if they use custom serialization, so I'm just gonna error if any are used!”. That's great, except you forgot that XmlSerializer always writes the start element out before handing control over to IXmlSerializable::WriteXml, so leaving XmlRootAttribute usable would make sense.

I have a work around, but it requires me to configure all types that I might ever serialize up front which defeats the entire purpose of dealing with these things generically. Damn this sucks. Yet another example of almost getting it right. Anyway, if I'm missing anything, please leave a comment and set me straight.

Update: FWIW, I checked last night and the .NET 2.0 (Whidbey) version of the XmlSerializer actually works as one would expect, honoring the presense of XmlRootAttribute even on IXmlSerializable isntances. Also, according to a comment from Matt Tavis, full support has been “re-enabled” for all attributes that still make sense even in the IXmlSerializable scenario.

I freakin' hate that when I click the music or radio tab in WMP10 that I'm not automatically logged in based on the Passport account linked to my Windows login. It looks like it logs me in automagically if I browse there with my MSN browser, so I'm guessing that this is WMP10's fault. What's the point in trying to push a single sign in service to tie everything together if you're not going to set a good example in your own software by leveraging the tie-in? Not only that, but if I check off the “Sign me in automatically” box during the sign-in process, it doesn't remember me that way either.

I know I can't be the only one frustrated by software that sucks at doing something that seems so core to its success. :P

Rob Relyea has posted a few tidbits on syntax changes we can expect in the next drop of XAML. I especially like the disconnection of resources, which are too closely tied to Avalon in current drops. I also loved the little jab that Rob makes at knockoff technologies about holding off on announcing the new syntax until they can implement it first. :)

Ryan Dawson made a post called “Avalon 3D Must-Haves”. In the post he makes a few good points about the 3D stack in Avalon that I figured I'd chime in on. Here goes...

I think his first point is the most important. If we can't use another scene as an interactive texture on a 3D surface then that's a major let down. Anybody remember a technology called Chrome? Most likely not since it didn't make it into the real world. It was next-generation rendering technology for IE that was going to bring mixed 3D/HTML content to the browser. This was back in '98, but even then, when 3D hardware was basically just taking off (think nVidia Riva 128 with 4MB of RAM) and all they had was DirectX3(?) at the time, they had the ability to use another web page as a surface on another 3D object. Not only that, but the web page was fully interactive! Links worked, you could navigate around, you could interact with other DHTML content, etc. I did a couple demos with it back in the day and even though it never made it back then, I knew it was only a matter of time before it showed up in the mainstream. Anyway, my point is, if they could hack it together then by getting IE to render itself to an offscreen buffer, then map that as a texture onto a 3D object and then translate the mouse movements from 3D coordinates to back to the underlying IE instance that contained the web page so you could interact with it, they should certainly be able to pull it off today with an architecture built from the ground up on today's massive GPUs.

I do, however, disagree with the point about animation not being important. UIs of the future need to be more fluid. They need to move and react to the user and make better use of all three dimensions. Animation is the key to acheiving that, but much like any other technology it can certainly be misused/overdone. That said, I do agree it needs to perform better than it does at the moment (let's not forget this is alpha software though). What I don't need is full fledged DoomIII quality scenes flowing at 160fps in my Avalon application, but a guarenteed 30fps for the foreground app is a must. This is going to be extremely difficult for Avalon on “older” kernels since this kind of functionality requires a new driver model for dealing with the GPU.

.NET XML API pundit, Daniel Cazzulino, has brought to light a bug in the way the Whidbey version of the XmlSerializer works with respect to fixed attribute values. If you used fixed values and expect them to be emmitted correctly to the instance document, I suggest you go vote this bug up.

That said, I think I understand why they don't emit it. When you define a default value attribute in an XML Schema, it's pretty much like saying: "If an instance document does not specify an explicit value for this attribute, this is the value that people interpreting the instance document should use instead." Fixed is basically the same thing, except they can't change the value at all. They can include it in the document, which is what Daniel is looking for here, but they cannot change the value. So, based on this logic, what the XmlSerializer is doing is saying: "Hey, this is the default/fixed value for the attribute, why should I pollute the instance document by stating the obvious when the person interpreting the document already knows what the value should be if I leave it out?".

Update:

Ok, I somehow completely missed an important part of Daniel's post so I need to correct myself. The part I missed is the all important use="required" setting on the attribute that Daniel clearly pointed out in his post. How I missed it is beyond me, but obviously with that attribute in place the XmlSerializer is completely in the wrong for not outputting it. Thanks to Sam for pointing this out to me, I appreciate it.