Clemens Vasters, Bldg 42 : WCF

XML-RPC with WCF (Updated)

clemensv — Fri, 03 Apr 2009 11:09:14 GMT

I had updated my WCF XML-RPC stack for PDC’08 but never got around to post it (either too busy or too lazy when not busy). The updated source code is attached to this post.

Contrary to the code that I’ve posted a while back, the new XML-RPC implementation is no longer a binding with a special encoder, but is implemented entirely as a set of behaviors and extensions for the WCF Service Model. The behavior will work with WCF 3.5 as it ships in the framework and also with the .NET Service Bus March 2009 CTP.

The resulting Service Model programming experience is completely "normal". That means you can also expose the XML-RPC contracts as SOAP endpoints with all the advanced WCF bindings and features if you like. The behaviors support client and service side. I stripped the config support from this version – I’ll add that back once I get around to it. Here's a snippet from the MetaWeblog contract:

  1: [ServiceContract(Namespace = http://www.xmlrpc.com/metaWeblogApi)]
  2: public interface IMetaWeblog : IBlogger
  3: {
  4:    [OperationContract(Action="metaWeblog.editPost")]
  5:    bool metaweblog_editPost(string postid,
  6:                              string username,
  7:                              string password,
  8:                              Post post,
  9:                              bool publish);
 10: 
 11:    [OperationContract(Action="metaWeblog.getCategories")]
 12:    CategoryInfo[] metaweblog_getCategories( string blogid,
 13:                                             string username,
 14:                                             string password);
 15:     ...
 16: 
 17: }

Setting up the endpoint is very easy. Pick the WebHttpBinding (or the WebHttpRelayBinding for .NET Service Bus), create an endpoint, add the XmlRpcEndpointBehavior to the endpoint and you’re good to go.

  1: Uri baseAddress = new UriBuilder(Uri.UriSchemeHttp, Environment.MachineName, -1, "/blogdemo/").Uri;
  2: 
  3: ServiceHost serviceHost = new ServiceHost(typeof(BloggerAPI));
  4: var epXmlRpc = serviceHost.AddServiceEndpoint(
  5:                   typeof(IBloggerAPI), 
  6:                   new WebHttpBinding(WebHttpSecurityMode.None), 
  7:                   new Uri(baseAddress, "./blogger"));
  8: epXmlRpc.Behaviors.Add(new XmlRpcEndpointBehavior());

The client is just as simple:

  1: Uri blogAddress = new UriBuilder(Uri.UriSchemeHttp, Environment.MachineName, -1, "/blogdemo/blogger").Uri;
  2:             
  3: ChannelFactory<IBloggerAPI> bloggerAPIFactory = 
  4:      new ChannelFactory<IBloggerAPI>(
  5:              new WebHttpBinding(WebHttpSecurityMode.None), 
  6:              new EndpointAddress(blogAddress));
  7: bloggerAPIFactory.Endpoint.Behaviors.Add(new XmlRpcEndpointBehavior());
  8: 
  9: IBloggerAPI bloggerAPI = bloggerAPIFactory.CreateChannel();
 10:

For your convenience I've included complete Blogger, MetaWeblog, and MovableType API contracts along with the respective data types in the test applications. The test app is a small in-memory blog that you can use with the blogging function of Word 2007 or Windows Live Writer or some other blogging client for testing.

Of the other interesting XML-RPC APIs, the Pingback API has the following contract:

  1:  [ServiceContract(Namespace="http://www.hixie.ch/specs/pingback/pingback")]
  2:  public interface IPingback
  3:  {
  4:      [OperationContract(Action="pingback.ping")]
  5:      string ping(string sourceUri, string targetUri);
  6:  }

and the WeblogUpdates API looks like this:

  1:     [DataContract]
  2:     public struct WeblogUpdatesReply
  3:     {
  4:         [DataMember]
  5:         public bool flerror;
  6:         [DataMember]
  7:         public string message;
  8:     }
  9: 
 10:     [ServiceContract]
 11:     public interface IWeblogUpdates
 12:     {
 13:         [OperationContract(Action = "weblogUpdates.extendedPing")]
 14:         WeblogUpdatesReply ExtendedPing(string weblogName, string weblogUrl, string checkUrl, string rssUrl);
 15:         [OperationContract(Action="weblogUpdates.ping")]
 16:         WeblogUpdatesReply Ping(string weblogName, string weblogUrl);
 17:     }

The code is subject to the Microsoft samples license, which means that you can freely put it into your (blogging) apps as long as you keep the house out of trouble.

Sin, Sin, Sin: How to do Simple, Webby, and Completely Insecure ASP.NET Membership Authentication and Role Authorization with WCF

clemensv — Wed, 22 Aug 2007 11:20:05 GMT

We're all sinners. Lots of the authentication mechanisms on the Web are not even "best effort", but rather just cleartext transmissions of usernames and passwords that are easily intercepted and not secure at all. We're security sinners by using them and even more so by allowing this. However, the reality is that there's very likely more authentication on the Web done in an insecure fashion and in cleartext than using any other mechanism. So if you are building WCF apps and you decide "that's good enough" what to do?

WCF is - rightfully - taking a pretty hard stance on these matters. If you try to use any of the more advanced in-message authN and authZ mechnanisms such as the integration with the ASP.NET membership/role provider models, you'll find yourself in security territory and our security designers took very good care that you are not creating a config that results in the cleartext transmission of credentials. And for that you'll need certificates and you'll also find that it requires full trust (even in 3.5) to use that level of robust on-wire security.

dasBlog has (we're sinners, too) a stance on authentication that's about as lax as everyone else's stance in blog-land. There are not many MetaWeblog API endpoints running over https (as they rather should) that I've seen.

So what I need for a bare minimum dasBlog install where the user isn't willing to get an https certificate for their site is a very simple, consciously insecure, bare-bones authentication and authorization mechanism for WCF services that uses the ASP.NET membership/role model (dasBlog will use that model as we switch to the .NET Framework 3.5 later this year). The It also needs to get completely out of the way when the service is configured with any real AuthN/AuthZ mechanism.

So here's a behavior (some C# 3.0 syntax, but easy to fix) that you can add to channel factories (client) and service endpoints (server) that will do just that. If you care about confidentiality of credentials on the wire don't use it. For this to work, you need to put the behavior on both ends. The behavior will do nothing (as intended) when the binding isn't the BasicHttpBinding with BasicHttpSecurityMode.None). The header will not show up in WSDL.

On the client, you simply add the behavior and otherwise set the credentials as you would usually do for UserName authentication. This makes sure that the client code stays compatible when you upgrade the wire protocol to a more secure (yet still username-based) binding via config.

MyClient remoteService = new MyClient();
remoteService.ChannelFactory.Endpoint.Behaviors.Add(new SimpleAuthenticationBehavior());
remoteService.ClientCredentials.UserName.UserName = "admin";
remoteService.ClientCredentials.UserName.Password = "!adminadmin";

On the server, you just configure your ASP.NET membership and role database. With that in place, you can even use role-based security attributes or any other authorization mechnanism you are accustomed to in ASP.NET. Just as on the client, the behavior goes out of the way and gives way for the "real thing" once you turn on security.

using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.ServiceModel.Security;
using System.Threading;
using System.Web.Security;
using System.Xml.Serialization;

namespace dasBlog.Storage
{
    [DataContract(Namespace = Names.DataContractNamespace)]
    class SimpleAuthenticationHeader
    {
        [DataMember]
        public string UserName;
        [DataMember]
        public string Password;
    }

    public class SimpleAuthenticationBehavior : IEndpointBehavior
    {
        #region IEndpointBehavior Members

        public void AddBindingParameters(ServiceEndpoint endpoint,
                                         BindingParameterCollection bindingParameters)
        {

        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint,
                                        ClientRuntime clientRuntime)
        {
            if (endpoint.Binding is BasicHttpBinding &&
                ((BasicHttpBinding)endpoint.Binding).Security.Mode == BasicHttpSecurityMode.None )
            {
                var credentials = endpoint.Behaviors.Find<ClientCredentials>();
                if (credentials != null && credentials.UserName != null && credentials.UserName.UserName != null)
                {
                    clientRuntime.MessageInspectors.Add(new ClientMessageInspector(credentials.UserName));
                }
            }
        }

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
        {
            if (endpoint.Binding is BasicHttpBinding &&
                ((BasicHttpBinding)endpoint.Binding).Security.Mode == BasicHttpSecurityMode.None)
            {
                endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new DispatchMessageInspector());
            }
        }

        public void Validate(ServiceEndpoint endpoint)
        {

        }

        #endregion

        class DispatchMessageInspector : IDispatchMessageInspector
        {
            #region IDispatchMessageInspector Members

            public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
            {
                int headerIndex = request.Headers.FindHeader("simpleAuthenticationHeader", "http://dasblog.info/2007/08/security");
                if (headerIndex >= 0)
                {
                    var header = request.Headers.GetHeader<SimpleAuthenticationHeader>(headerIndex);
                    request.Headers.RemoveAt(headerIndex);
                    if ( Membership.ValidateUser(header.UserName, header.Password) )
                    {
                        var identity = new FormsIdentity(new FormsAuthenticationTicket(header.UserName, false, 15));
                        Thread.CurrentPrincipal = new RolePrincipal(identity);
                    }
                }
                return null;
            }

            public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
            {

            }

            #endregion
        }

        class ClientMessageInspector : IClientMessageInspector
        {
            #region IClientMessageInspector Members

            UserNamePasswordClientCredential creds;

            public ClientMessageInspector(UserNamePasswordClientCredential creds)
            {
                this.creds = creds;
            }

            public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
            {

            }

            public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel)
            {
                request.Headers.Add(MessageHeader.CreateHeader("simpleAuthenticationHeader", http://dasblog.info/2007/08/security,
                                    new SimpleAuthenticationHeader{ UserName = creds.UserName, Password = creds.Password }));
               return null;
            }

            #endregion
        }
    }
}

XML-RPC with WCF

clemensv — Tue, 21 Aug 2007 01:46:33 GMT

UPDATE: The code has been updated. Ignore this post and go here.

I'm writing lots of code lately. I've rejoined the dasBlog community and I'm busy writing a prototype for the .NET Framework 3.5 version of dasBlog (we just released the 2.0 version, see http://www.dasblog.info/).

One of the goals of the prototype, which we'll eventually merge into the main codebase once the .NET Framework 3.5 is available at hosting sites is to standardize on WCF for all non-HTML endpoints. Since lots of the relevant inter-blog and blogging tool APIs are still based on XML-RPC, that called for an implementation of XML-RPC on WCF. I've just isolated that code and put it up on wcf.netfx3.com.

My XML-RPC implementation is a binding with a special encoder and a set of behaviors. The Service Model programming experience is completely "normal" with no special extension attributes. That means you can also expose the XML-RPC contracts as SOAP endpoints with all the advanced WCF bindings and features if you like.

The binding supports client and service side and is completely config enabled. Here's a snippet from the MetaWeblog contract:

[ServiceContract(Namespace = http://www.xmlrpc.com/metaWeblogApi)]
public interface IMetaWeblog : Microsoft.ServiceModel.Samples.XmlRpc.Contracts.Blogger.IBlogger
{
   [OperationContract(Action="metaWeblog.editPost")]
   bool metaweblog_editPost(string postid,
                             string username,
                             string password,
                             Post post,
                             bool publish);

   [OperationContract(Action="metaWeblog.getCategories")]
   CategoryInfo[] metaweblog_getCategories( string blogid,
                                            string username,
                                            string password);
    ...
}

For your convenience I've included complete Blogger, MetaWeblog, and MovableType API contracts along with the respective data types in the test application. The test app is a small in-memory blog that you can use with the blogging function of Word 2007 as a client or some other blogging client for testing.

Of the other interesting XML-RPC APIs, the Pingback API has the following contract:

    [ServiceContract(Namespace="http://www.hixie.ch/specs/pingback/pingback")]
    public interface IPingback
    {
        [OperationContract(Action="pingback.ping")]
        string ping(string sourceUri, string targetUri);
    }

and the WeblogUpdates API looks like this:

    [DataContract]
    public struct WeblogUpdatesReply
    {
        [DataMember]
        public bool flerror;
        [DataMember]
        public string message;
    }

    [ServiceContract]
    public interface IWeblogUpdates
    {
        [OperationContract(Action = "weblogUpdates.extendedPing")]
        WeblogUpdatesReply ExtendedPing(string weblogName, string weblogUrl, string checkUrl, string rssUrl);
        [OperationContract(Action="weblogUpdates.ping")]
        WeblogUpdatesReply Ping(string weblogName, string weblogUrl);
    }

I'm expecting some interop bugs since I've done a clean implementation from the specs, so if you find any please let me know.

The code is subject to the Microsoft samples license, which means that you can put it into your (blogging) apps. Enjoy.

Webcast Today....

clemensv — Wed, 21 Jun 2006 11:57:52 GMT

In the ongoing MSDN Architecture Webcast Series with broad coverage of all things WCF (see the "Next Generation: .NET Framework 3.0 and Vista" section for archived and upcoming content), I am on today (8AM PST, 11AM EST, 17:00 CET), live from my kitchen table in Germany, with a remix of my "RSS, REST, POX, Sites-as-Services" talks from MIX06 and TechEd.

WCF Goes To Hollywood.

clemensv — Wed, 21 Jun 2006 11:39:35 GMT

Cool. I hadn't even seen this demo until now, even though we already have it for a while. Our technical evangelist Craig McMurtry posted the "Digital Fortress" demo, which is an implementation of the computer systems that play major roles in Dan Brown's novel "Digital Fortress". There are several reasons why I find this demo interesting and pretty amusing.

First of all, it has a "Hollywood-Style UI", which is funny. It's got the huge full-screen login screen with a "sort-of-looks-like-the-NSA" logo, a big count-down clock and a "control screen" (below) with the gratuitous graphics and big buttons one might expect. The other thing that's very interesting is that it is a management tools demo (of all things). The key to bust the evil conspiracy is to trace suspicious network activity across many nodes on the network and the script packaged with the demo shows you how to get that done using the built-in WCF tracing facilities. Download.

MSDN TV: WCF Bindings.

clemensv — Sun, 18 Jun 2006 15:56:50 GMT

[Note to self: Schedule the video taping session early in a bound-to-be-stressful week, not 2 hours before you need to leave for the airport on Friday.]

MSDN TV has a new episode featuring yours truly speaking about WCF bindings (and what they cause in the channel stack).

Code-Name WinFX vs .NET Framework 3.0

clemensv — Sun, 18 Jun 2006 15:39:48 GMT

I was sad when "Indigo" and "Avalon" went away. It'd be great if we'd have a pool of cool legal-approved code-names for which we own the trademark rights and which we could stick to. Think Delphi or Safari. "Indigo" was cool insofar as it was very handy to refer to the technology set, but was removed far enough from the specifics that it doesn't create a sharply defined, product-like island within the larger managed-code landscape or has legacy connotations like "ADO.NET". Also, my talks these days could be 10 minutes shorter if I could refer to Indigo instead of "Windows Communications Foundation". Likewise, my job title wouldn't have to have a line wrap on the business card of I ever spelled it out in full.

However, when I learned about the WinFX name going away (several weeks before the public announcement) and the new "Vista Wave" technologies (WPF/WF/WCF/WCS) being rolled up under the .NET Framework brand, I was quite happy. Ever since it became clear in 2004 that the grand plan to put a complete, covers-all-and-everything managed API on top (and on quite a bit of the bottom) of everything Windows would have to wait until siginificantly after Vista and that therefore the Win16>Win32>WinFX continuity would not tell the true story, that name made only limited sense to stick to. The .NET Framework is the #1 choice for business applications and a well established brand. People refer to themselves as being "dotnet" developers. But even though the .NET Framework covers a lot of ground and "Indigo", "Avalon", "InfoCard", and "Workflow" are overwhelmingly (or exclusively) managed-code based, there are still quite a few things in Windows Vista that still require using P/Invoke or COM/Interop from managed code or unmanaged code outright. That's not a problem. Something has to manage the managed code and there's no urgent need to rewrite entire subsystems to managed code if you only want to add or revise features.

So now all the new stuff is now part of the .NET Framework. That is a good, good, good change. This says what it all is.

Admittedly confusing is the "3.0" bit. What we'll ship is a Framework 3.0 that rides on top of the 2.0 CLR and includes the 2.0 versions of the Base-Class Library, Windows Forms, and ASP.NET. It doesn't include the formerly-announced-as-to-be-part-of-3.0 technologies like VB9 (there you have the version number consistency flying out the window outright), C# 3.0, and LINQ. Personally, I think that it might be a tiny bit less confusing if the Framework had a version-number neutral name such as ".NET Framework 2006" which would allow doing what we do now with less potential for confusion, but only a tiny bit. Certainly not enough to stage a war over "2006" vs. "3.0".

It's a matter of project management reality and also one of platform predictability that the ASP.NET, or Windows Forms teams do not and should not ship a full major-version revision of their bits every year. They shipped Whidbey (2.0) in late 2005 and hence it's healthy for them to have boarded the scheduled-to-arrive-in-2007 boat heading to Orcas. We (the "WinFX" teams) subscribed to the Vista ship docking later this year and we bring great innovation which will be preinstalled on every copy of it. LINQ as well as VB9 and C# incorporating it on a language-level are very obviously Visual Studio bound and hence they are on the Orcas ferry as well. The .NET Framework is a steadily growing development platform that spans technologies from the Developer Division, Connected Systems, Windows Server, Windows Client, SQL Server, and other groups, and my gut feeling is that it will become the norm that it will be extended off-cycle from the Developer Division's Visual Studio and CLR releases. Whenever a big ship docks in the port, may it be Office, SQL, BizTalk, Windows Server, or Windows Client, and as more and more of the still-unmanaged Win32/Win64 surface area gets wrapped, augmented or replaced by managed-code APIs over time and entirely new things are added, there might be bits that fit into and update the Framework.

So one sane way to think about the .NET Framework version number is that it merely labels the overall package and not the individual assemblies and components included within it. Up to 2.0 everything was pretty synchronized, but given the ever-increasing scale of the thing, it's good to think of that being a lucky (even if intended) coindicence of scheduling. This surely isn't the first time that packages were versioned independently of their components. There was and is no reason for the ASP.NET team to gratuitously recompile their existing bits with a new version number just to have the GAC look pretty and to create the illusion that everything is new - and to break Visual Studio compatibility in the process.

Of course, once we cover 100% of the Win32 surface area, we can rename it all into WinFX again ;-) (just kidding)

[All the usual "personal opinion" disclaimers apply to this post]

Update: Removed reference to "Win64".

XML is the assembly language of Web 2.0

clemensv — Sun, 18 Jun 2006 13:24:01 GMT

I've been quoted as to have said so at TechEd and I'll happily repeat it: "XML is the assembly language of Web 2.0", even though some (and likely some more) disagree. James Speer writes "Besides, Assembly Language is hard, XML isn’t." , which I have to disagree with.

True, throwing together some angle brackets isn't the hardest thing in the world, but beating things into the right shape is hard and probably even harder than in assembly. Yes, one can totally, after immersing oneself in the intricacies of Schema, write complex types and ponder for days and months about the right use of attributes and elements. It's absolutely within reach for a WSDL zealot to code up messages, portTypes and operations by hand. But please, if you think that's the right way to do things, I also demand that you write and apply your security policy in angle bracket notation from the top of your head and generate WCF config from that using svcutil instead of just throwing a binding together, because XML is so easy. Oh? Too hard? Well, it turns out that except for our developers and testers who are focusing on getting these mappings right, nobody on our product team would probably ever even want to try writing such a beast by hand for any code that sits above the deep-down guts of our stack. This isn't the fault of the specifications (or people here being ignorant), but it's a function of security being hard and the related metadata being complex. Similar things, even though the complexity isn't quite as extreme there, can be said about the other extensions to the policy framework such as WS-RM Policy or those for WS-AT.

As we're getting to the point where full range of functionality covered by WS-* specifications is due to hit the mainstream by us releasing WCF and our valued competitors releasing their respective implementations, hand-crafted contracts will become increasingly meaningless, because it's beyond the capacity of anyone whose job it is to build solutions for their customers to write complete set of contracts that not only ensures simple data interop but also protocol interop. Just as there were days that all you needed was assembly and INT21h to write a DOS program (yikes) or knowledge of "C" alongside stdio.h and fellows to write anything for everthing, things are changing now in the same way in Web Services land. Command of XSD and WSDL is no longer sufficient, all the other stuff is just as important to make things work.

Our WCF [DataContract] doesn't support attributes. That's a deliberate choice because we want to enforce simplicity and enhance interoperability of schemas. We put an abstraction over XSD and limit the control over it, because we want to simplify the stuff that goes across the wire. We certainly allow everyone to use the XmlSerializer with all of it's attribute based fine-grained control over schema, even though there are quite a few Schema constructs that even that doesn't support when building schema from such metadata. If you choose to, you can just ignore all of our serialization magic and fiddle with the XML Infoset outright and supply your own schema. However, XML and Schema are specifications that everyone and their dog wanted to get features into and Schema is hopelessly overengineered. Ever since we all (the industry, not only MS) boarded the SOAP/WS train, we're debating how to constrain the features of that monster to a reasonable subset that makes sense and the debate doesn't want to end.

James writes that he "take[s] a lot of care in terms of elements vs. attributes and mak[es] sure the structure of the XML is business-document-like", which only really makes sense if XML documents used in WS scenarios were meant for immediate human consumption, which they're not.

We want to promote a model that is simple and consistent to serialize to and from on any platform and that things like the differentiation between attributes and elements doesn't stand in the way of allowing a 1:1 mapping into alternate, non-XML serialization formats such as JSON or what-have-you (most of which don't care about that sort of differentiation). James' statement about "business-document-like" structures is also interesting considering EDIFACT, X.12 or SWIFT, all of which only know records, fields and values, and don't care about that sort of subtle element/attribute differentation, either. (Yes, no of those might be "hip" any more, but they are implemented and power a considerable chunk of the world economy's data exchange).

By now, XML is the foundation for everything that happens on the web, and I surely don't want to have it go away. But have arrived at the point where matters have gotten so complicated that a layer of abstraction over pretty much all things XML has become a necessity for everyone who makes their money building customer solutions and not by teaching or writing about XML. In my last session at TechEd, I asked a room of about 200 people "Who of you hand-writes XSLT transforms?" 4 hands. "Who of you used to hand-write XSLT transforms?" 40+ hands. I think it's safe to assume that a bunch of those folks who have sworn off masochism and no longer hand-code XSLT are now using tools like the BizTalk Mapper or Altova's MapForce, which means that XSL/T is alive and kicking, but only downstairs in the basement. However, the abstractions that these tools provide also allow bypassing XSLT altogether and generate the transformation logic straight into compiled C++, Java, or C# code, which is what MapForce offers. WSDL is already walking down that path.

TechEd: Sample Code from CON423

clemensv — Fri, 16 Jun 2006 00:34:43 GMT

Here's the sample code from my CON423 session about selecting bindings here at TechEd.

TechEd: What I am going to talk about on Thursday

clemensv — Tue, 13 Jun 2006 19:09:57 GMT

My first of two sessions this week here at TechEd is on Thursday, at 2:45pm in room 153ABC on "Designing Bindings and Contracts".

I realize that the title sounds a bit abstract and a different way to put this would be "How to choose the correct bindings and what to consider about contracts in a variety of architectual scenarios", but that would have been a bit long as a title. in the talk I'll explain the system-defined bindings that we ship in the product so that we've got stuff to work with and then I'll get out the tablet pen and draw up a bunch of scenarios and how our bindings (read: communication options) make sense in those. What's the best choice for N-Tier inside and outside of the corporate perimeter, what do you do for queueing-style apps, how do you implement volatile or durable 1:1 pub/sub, how do you implement broadcasts and where do they make sense, etc.

TechEd: WCF RSS Toolkit released

clemensv — Tue, 13 Jun 2006 17:23:12 GMT

We've just released the "Windows Communication Foundation RSS Toolkit" on our new community site. This toolkit, which comes with complete source code, illustrates how to expose ATOM and RSS feeds through WCF endpoints. I will discuss the toolkit in my session CON339, Room 107ABC, Friday 10:45am here at TechEd.

TechEd 2006 U.S. Kicks Off

clemensv — Mon, 12 Jun 2006 15:48:51 GMT

This is my first TechEd! - as a Microsoft employee. It's of course not my first tech event in my new job (Egypt, Jordan, UK, France, Switzerland, Holland, Belgium, Denmark, Las Vegas/USA, Slovenia, and Israel are on the year-to-date list - on top of three long-distance commutes to Redmond), but the big TechEds are always special. It'll be fun. Come by the Connected Systems area in the exhibition hall and find me to chat if you are here in Boston.

Frankly, I didn't expect a Sunday night keynote to be nearly as well attended as it was, but it looks that experiment mostly worked. The theme of the keynote were Microsoft's 4 Core Promises for IT Pros and Developers nicely wrapped into a video story based on the TV show "24" and with that show's IT superwoman Chloe O'Brian (actress Mary Lynn Rajskub) up on stage with Bob Muglia (our team's VP far up above in my chain of command), who acted as the MC for the show. Finally we got an apology from a Hollywood character for all the IT idiocy the put up on screen. Thanks, Chloe.

Our team has a lot of very cool stuff to talk about at this show. The first highlight is John Justice's WCF Intro talk (Session CON208, Room 157ABC) today at 5:00pm with a "meet the team" panel Q&A session at the end. Block the time.

A New Home on the Web for the Windows Communication Foundation and the .NET Framework 3.0

clemensv — Mon, 12 Jun 2006 15:03:33 GMT

Late last night, my colleague James Conard, who has worked and worked and worked tirelessly on this for the past few months and has shown great patience with a big group of people pulling into all sorts of directions as we got this together has flipped the switch to turn on the new .NET Framework 3.0 community portal family at netfx3.com

The new Windows Communication Foundation community home is at http://wcf.netfx3.com and it's a great improvement over the small, hastily-thown-together site that we used to have. There'll be a number of news bits and announcements throughout and after TechEd at the new site, so it might be a good idea to subscribe to the feed now.

My official "Welcome!" post over on the new site is here, the James' site-wide welcome message can be found here.

The System-Defined Bindings in WCF: Nicholas Allen explains it all

clemensv — Tue, 06 Jun 2006 23:50:22 GMT

My PM colleague Nicholas Allen is certainly on my list for "best blogging newcomer of 2006". He started in February, got hooked, and I am not sure whether he actually did leave the keyboard since then.

Nicholas just started a blog series that explains the system-defined (formely known as: standard-) bindings that we ship with WCF. He's got three of them explained now and my guess is that there are more to follow:

While you are there, make sure to subscribe to Nicholas' feed and also take a look around and look at earlier posts. His channel category is a gold mine and the same can be said of the transports and ... everything there is fabulous stuff.

Windows Communication Foundation "Documentation CTP"

clemensv — Mon, 17 Apr 2006 13:24:05 GMT

(via http://windowscommunication.net)

The WCF Documentation Team has started to release biweekly (!) documentation updates. The updates are made available as a set of .CHM files.

Mind that these files do not integrate directly into Visual Studio as the WinFX Windows SDK files do. Since VS integration requires quite a bit of setup work, the VS integrated help files can only ship with the regular WinFX Windows SDK CTPs. Nevertheless, the feedback from all customers we asked told us loud and clear that we should ship the documentation in this form irrespective of this minor usability inconvenience and therefore we do.

If you have feedback on the documentation, please use the "Send comments about this topic to Microsoft" email links below each documentation entry to provide feedback. Due to the volume that our team receives, you might not always get an answer, but your input is most definitely read and considered.

You can download the first (April 15) Documentation CTP directly using this link (20MB).