The XBAP-deployment model in WPF offers you a way to implement rich browser-based applications. Silverlight holds the same promise. So I was wondering: “What’s the difference? Why choose one above the other?”

According to the WPF documentation

“XAML browser applications (XBAPs) combines features of both Web applications and rich-client applications. Like Web applications, XBAPs can be published to a Web server and launched from Internet Explorer. Like rich-client applications, XBAPs can take advantage of the capabilities of WPF. Developing XBAPs is also similar to rich-client development.”

Silverlight is described (by Wikipedia) as

Microsoft Silverlight is a runtime for browser-based Rich Internet Applications, providing a subset of the animation, vector graphics, and video playback capabilities of Windows Presentation Foundation.

Security considerations.
This seems one of the major differences. XBAP-apps normally run as partially trusted apps in the internet zone and thus have very limited access to critical system data and resources. This means you’ll probably have to resort to Isolated Storage for your file IO. Alternatively you can write you app so that it demands full-trust permission from the user.
Silverlight-apps obviously run in the Internet zone and can also demand full-trust, so in terms of security, XBAP and Silverligt seem equivalent.

Cross-platform/cross-browser
XBAP-applications require a Windows-machine to run one; in fact, the user should also have the .NET 3.0 framework (or later) installed to run the apps. If the user has .NET 3.0 XBAPs can only be loaded in Internet Explorer. As of .NET 3.5 (see also yesterday’s post) FireFox can also be used.

Silverlight doesn’t require the .NET framework, but users have to install the Silverlight plugin for their OS and browser before they can run the application. This plugin has been released for Windows, OS/X (Apple) and Linux, and runs in a plethora of browsers. So, in terms of cross-platform/browser capabilities, Silverlight is a clear winner.

I had never realized it, but all the time while I was busy learning WPF I was learning legacy stuff. The 3.0 version of WPF is out-dated! The .NET Framework 3.5 has been released together with Visual Studio 2008 and among the many changes it brings (such as Ling, Suite-B encryption, WCF-WF integration and much more) it also changes some things in WPF.

First off, there is the new namespace:

http://schemas.microsoft.com/netfx/2007/xaml/presentation

If you add this to your XAML, you can use the 3.5 specific additions. Though the 3.5 WPF is 100% compatible with 3.0 , the reverse is, logically not true. Your 3.5 apps won’t run on the 3.0 platform if you use any of the new features.
In line with the improved extensibility model in the 3.5 framework, WPF has been equipped with support for this as well. The System.Addin namespace allows you to build in extensibility into you application, without having to worry about a lot of the nitty-gritty details yourself. The WPF-part of this model allows addins and extensions the User Interface part of the application in two distinct ways:

• Either the Add-In returns a UI: such as a dynamically generated interface-element
• Of the Add-In is a UI itself: an example would be an advertisement

Of course, making your application extensible is pretty advanced stuff, so most of us run-of-the-mill type developers will not have any use for it soon, but with additions like this, Microsoft is surely generating a productivity-boost for those heavy developers that create complex business-applications or technical tools, improving the usefulness of the .NET-framework as a whole.

2. Firefox can now run XBAPs. Seems pretty clear to me and will be a nice bonus for FF users.

3. Cookies can be used in all WPF application and share amongst XBAPs, Web servers and what not. Which is great if you want to flexibly persist user settings.

4. I had noticed it already but the IntelliSense for XAML has been improved a lot. Typing XAML in Visual Studio 2008 is a breeze, and you’ll never need Blend anymore (I’m kidding of course).

5. Some crazy languages have been added as part of the Localization namespace; you can now have your application localized to Klingon (KL-kl) as well as French and German :P

6. Caching support for downloaded images is now available. If you have an application that gets a lot of its content from an online source, this can drastically improve your performance. Of course you could have build this yourself, but why bother if the MS-folk have done all the hard work for you?

7. 3D-options have been improved, most notably by the addition of the 3DUIelement class that can receive events, just like its regular 2D Counterpart. This will make hit-detection a breeze! Besides that, some transformations have been added with which you can make transitions from 2D to 3D a lot easier.

8. DataBinding has been improved as well, by the addition of support for LINQ and XLINQ, better debugging possibilities and an alternate syntax for data validation.

All in all, a lot of changes in WPF alone. Most of them are pretty hardcore and might never be used by you (certainly not by me at least), but others, such as the new Validation syntax and 2D-3D transformations will certainly seem worthwhile. I'll have to investigate these a little further to say something. I'll start with the DataBinding item and I'll try and post something about it this year :)

Karsten Januszewski and Jaime Rodriguez wrote a nice whitepaper on how the 'collaboration between developers and designers in the WPF' differs from traditional way.

The biggest change for designers is that their creations will actually be part of the solution and that they can be much closer to the actual software experience. There is no translation process; there is no sitting over the shoulder of the developer explaining the vision and making sure she is re-creating it in the code. This can be incredibly empowering for the designer: The designer’s work is now part of the workflow itself.

It's an intersting read and can certainly be used to convince potential clients of the benefits of WPF and the added value of having a design professional as part of a development team.

Often you’d want to span a certain row or column in your grid across all other columns or rows. Say you have the following 4x4 grid and want to span the first cell over the entire first row:

<Rectangle x:Name="TopRect" Grid.Row="0" Grid.Column="0" Fill="Orange" Grid.ColumnSpan="4"/>

This will result in a nice span across all columns:



But, if you start adding columns, the following will happen because the ColumnSpan has been hardcoded:



Of course you can change the hard-codeed amount of spanning, but that would mean you’d have to change the value of the span each time you add a column or row to your grid.

You could also set the span in code. In order to do this, you have to use the attached properties from the Grid object and set them though the static SetColumnSpan(UIElement element, int value) method:

MyGrid.ColumnDefinitions.Add(new ColumnDefinition());
Grid.SetColumnSpan(TopRect, MyGrid.ColumnDefinitions.Count);

The problem with this is, the columnspan won’t change until runtime, and you won’t see the results in the designer in VS2008, which can be very confusing. The better way to achieve this is to use simple databinding. This requires giving the grid an x:Name and setting the ColumnSpan as follows:

<Rectangle Grid.Row="0" Grid.Column="0" Fill="Orange"
Grid.ColumnSpan="{Binding ElementName=MyGrid, Path=ColumnDefinitions.Count}"/>



Now, no matter how many columns are added or deleted, the top row will always span all columns. The columnspan will also be shown correctly in the designer at designtime, which is a nice bonus (and a good example of the quality of the designer in VS2008).
Another way to tackle this problem is by using a DockPanel. Drop the top (orange) row from the grid and add it to DockPanel.Top instead:


<Rectangle x:Name="TopRect" DockPanel.Dock="Top"
Fill="Orange" Height="50" />



This way, you can alter the grid’s dimension all you want without the orange bar changing size. As you can see, you have to set the height manually and you can’t use the * notation for the height of the orange bar. This can also be solved using databinding (and giving one of the rectangles in the cells a name):

<Rectangle x:Name="TopRect" DockPanel.Dock="Top"
Fill="Orange" Height="{Binding ElementName=UseMySize, Path=ActualHeight}" />



Now the orange row has a height of * (indirectly) and will be resized as the grid is resized.

Mmm... the 'Daily' part of my blogs title seems a bit unjustified. Ah well...

I'm a big fan of the Microsoft Webcasts. They've got tons of these presentations available for download at the Events and Webcasts homepage convering every MS technology and product you can think of. Recently a nice series on WPF was completed. It's an 18-part (each spanning about an hour) introduction to WPF, by Bill Steele ( who also has his own blog), a MS Developer Envangelist. It's nice series, convering most basic and some advanced topics of WPF.

Though the series doesn't really dwell on the technical aspects of the framework, it gives enough information to get you started properly and then some. It looks like Bill took a lot of the content from Adam Nathans' excellent book WPF Unleashed which is good, since it's still one of the best books on WPF out there. I recommend checking out the entire series at www.WPFSoupToNuts.com.