BAM! This is an exciting day; today we are releasing WCF RIA Services V1.0 SP1 Beta and WCF RIA Services Toolkit October 2010.  These download links are also available from http://silverlight.net/riaservices.

Side-by-side installation with WCF RIA Services V1.0 is not supported.  If you already have RIA Services installed on your machine, you should:

  1. Uninstall WCF RIA Services Toolkit
  2. Uninstall WCF RIA Services V1.0 for Visual Studio 2010
  3. Install WCF RIA Services V1.0 SP1 Beta
  4. Install WCF RIA Services Toolkit October 2010

You’ll notice that our SP1 Beta installer for the product is much faster now.  The Toolkit installer is still slow, but we’ll be fixing that soon too.

This release has a bunch of bug fixes; it is a Service Pack after all.  But showing a list of obscure bugs is not very exciting, so instead, let’s look at the more notable updates we’ve made.  Please keep in mind that this is a Beta release, however it does have a Go-Live license.

Complex Object Support

This feature is also known as “Support for Complex Types” on the WCF RIA Services wish list.  This was the 3rd-most requested feature, and we now have full support for complex types.  If you have an Entity that has complex type properties, we will generate corresponding types on the client and serialize them seamlessly.  The generated types will derive from a new ComplexObject class that we’ve introduced in our framework.  ComplexObject values are fully change-tracked and validated as part of your entities.

Shared Entity Support

Another top request on the wish list was to “Allow multiple DomainServices to share the same Entity.”  We’ve delivered on this one too.  In fact, we marked this item as “completed” awhile back, so it hasn’t been able to accrue any votes recently.  I remember seeing this as the 1st and 2nd most requested item up until the time we completed it.  Now you can logically segment your DomainService classes more freely.

DataForm Add/Remove for EntitySet and EntityCollection

With our initial V1.0 release, many of you found that a DataForm bound to an EntitySet or an EntityCollection did not support the Add or Remove buttons.  This was a difficult cut to make in V1.0, so I’m pleased to announce that with V1.0 SP1, this is now supported.  Silverlight 4 introduced the ICollectionViewFactory interface, with support integrated into DataGrid and DataForm, and both EntitySet and EntityCollection now implement that interface to allow the Add/Remove features to light up.

Be sure to keep an eye on Kyle McClellan’s blog for more information on this feature.  You’ll hear us refer to it as ICollectionViewFactory or ICVF.

Localization

Our initial V1.0 release was an English-only product.  Regardless of your Visual Studio language, our entire product was always English.  With our V1.0 SP1 release, we are now localized into 9 additional languages, matching the same list of languages supported by Visual Studio 2010.  Our product (not the Toolkit) is localized for the following languages: (based on your Visual Studio language)

  • German (de)
  • English (en)
  • Spanish (es)
  • French (fr)
  • Italian (it)
  • Japanese (ja)
  • Korean (ko)
  • Russian (ru)
  • Chinese - Simplified (zh-Hans)
  • Chinese - Traditional (zh-Hant)

The benefits you’ll see from this are:

  1. Domain Service Wizard is localized
  2. Code generated from the Domain Service Wizard is localized
  3. Code generated into your Silverlight project is localized
  4. All of our exception messages and other resource strings are localized
  5. The Business Application Project template is fully localized, including the UI within the application
  6. IntelliSense is localized into Japanese only (using machine translation and human editing for now).  When the SP1 is final, we’ll have full human-translated IntelliSense for all supported languages.

I will be starting a blog post series on localization in the near future, so stay tuned for more information on this topic.

Code Generation Extensibility

Deepesh Mohnani has a little more about this on his blog.

With our V1.0 release, our code generation was based on CodeDom and relatively locked down.  While you could provide a custom CodeProcessor through the [DomainIdentifier] attribute, you were forced to take the CodeDom model that we generated and manipulate it.  We know that many of you wanted to hook into the code generation to change what gets generated, and we want to make this easier.  To address this, we have a two-part solution.

First, within the product, we have abstracted our code generation away from CodeDom and implemented a MEF-based mechanism for you to bring your own code generator.  Our CodeDom-based code generator now implements a simple IDomainServiceClientCodeGenerator interface and returns the generated code as a string.  Other code generators can be registered using the [DomainServiceClientCodeGenerator] attribute.

You now have a means for creating a new code generator from scratch and plugging it into our build-time code generation.  But there’s a catch… you cannot derive from our code generator or otherwise use it in any way when you do that.  That’s where step two comes in.

Second, within the Toolkit, we have introduced a Text Template (T4) based code generator called Microsoft.ServiceModel.DomainServices.Tools.TextTemplate.CSharpGenerators.CSharpClientCodeGenerator.  This class resides in a new Microsoft.ServiceModel.DomainServices.Tools.TextTemplate assembly.  The intent is for you to derive from the CSharpClientCodeGenerator class and override its methods within your own T4 template classes.  You’ll find that we have scores of virtual methods at your disposal so that you can easily tweak tiny portions of the generated code without having to take full control of the template.

Quality Disclaimer: The Text Template code generator is in an experimental state.  In fact, the feature was just checked in about 3 hours before we uploaded the MSI.  There has been very little testing done on this feature, but from what we’ve seen most mainline scenarios work.  We will be soliciting feedback on these early bits, so please let us know if you encounter issues.

Windows Azure Table Storage Support

Also in the Toolkit, we have added a new Microsoft.ServiceModel.DomainServices.WindowsAzure assembly.  This assembly contains a TableDomainService class that allows you to very easily expose your Windows Azure Table Storage entities using a DomainService.  This allows your client application to be completely ignorant of your Azure use on the server, as we provide the same level of client-side LINQ support over this domain service as we do over Entity Framework, Linq to SQL, or POCO domain services.

Kyle McClellan developed this feature and he’ll be blogging more about it.

Quality Disclaimer: The Windows Azure Table Storage domain service was also a late addition to our Toolkit, so it’s also in preview state with limited testing having been done at this point.

More Details

Several members of the WCF RIA Services team have blogs and/or are on Twitter.  Keep your eyes open for more information about this release, as there is just a ton of stuff packed in.  Here are some links for you.