WCF February CTP: Tids and Bits. Post 1 --

So, much has happened. For those who care about what's up in WCFland, there is a ton of new information to ingest. Let's start with the Feb CTP itself, here. Knock yourself out. Once you install it, of course, a bunch of stuff that used to work now does not. :-)

So you'll need some help. First of all, make sure you keep and eye on the new WCF Web site here. From there, you'll note that there's a breaking change list posted by Ed Pinto here. This document is rewarding and will return many fold the investment energy taken to mine it for infonuggets.

Let me give an example. I write a lot of programs used as samples in the documentation, sent internally to people at Microsoft, and for our customers. One of the straightforward changes was that in the <service> element in the configuration files the "type" attribute is now the "name" attribute. Great. But there's also something quite different going on underneath the hood: The name value, because it is explicitly not the type, can be anything at all. It is merely a lookup value for the configuration file. By default, this is the name of the service type, but it could be anything at all.

But even after I began porting sample applications to the new configuration schema, when I ran them they blew up all over me. Why? Because although you could (prior to the Feb CTP) use an assembly-qualified type name as a value here (that is, "WCF.ServiceType,WCFCustomAssembly") you cannot now do this and have your <service> section found by default without specifying a string when creating the ServiceHost. If you're porting applications to the Feb CTP, remove any assembly strings from this value and that of <endpoint contract=""> .

This is an interesting behavior change, but there it is, lurking down in the changelist:

We have reworked the SerivceHost and ServiceHostBase types so that the WCF programming model and configuration model can be reused or replaced. ServiceHostBase now supports building a runtime from a ServiceDescription and provides overloads for constructing a ServiceDescription using the WCF programming model and configuration model. The WCF configuration model is no longer strongly tied to the WCF programming model. Names in config are now strictly treated as configuration strings and not necessarily as types. When using the WCF programming model the configuration names should be the full type names. Assembly qualified type names are no longer supported.

Unless, that is, you specify that exact string in the ServiceHost constructor. :-)

Comments

• Anonymous
  February 26, 2006
  Маджаяр расказывает об изменениях в модели расширений, Ральф Сквилэйс — о конфиг