Programming WPF

There is a very steep learning curve to WPF, and I recommend you get the obvious books first (Adam Nathan, Sells/Griffiths, and Chris Anderson) and blogs (Josh Smith, etc.). Just be prepared for it, and make sure your project allows you the time to learn WPF.

In addition to learning the technology, spend some time learning the patterns used to construct WPF applications. Model View ViewModel (MVVM) seems to be the one that has gained a great deal of acceptance.

Personally, I think WPF is worth it but be forewarned. Also note that you effectively restrict your users to Windows XP SP2+ and Windows Vista. We've made that decision, but you may have some different requirements.

If you really want to learn WPF "code-first", there's really just one primary resource out there that I'm aware of:

Sells' & Griffiths' Programming WPF book

They approach WPF from a code-first perspective. I don't think xaml is even introduced until the second half of the (rather large) book.

Note that you'll also be learning to do some things the "old" way, where the newer versions of WPF have learned lessons from Silverlight, etc. (E.g., Triggers vs VisualStateManager)

App.xaml is the declarative portion of your code (usually generated by Visual Studio) extending System.Windows.Application. For example, Expression Blend can use App.xaml to share a Resource Dictionary or a design-time data set with your entire application. And, because we are using Microsoft products, whatever Expression Blend can do auto-magically, we can do by hand in Visual Studio.

Now the tangent: To me, to ask about the purpose of App.xaml is to ask about the purpose for System.Windows.Application. Feel free to accuse me of changing the original question (let the digital brutally ensue).

You can’t just open a System.Windows.Controls.Window in any Assembly you like… Chris Sells is likely telling me this in his book. I began to understand the purpose of System.Windows.Application while using MEF and MVVM Light to display WPF windows in DLLs (not EXEs). I got errors like this:

The type 'System.Windows.Markup.IComponentConnector' is defined in an assembly that is not referenced.

or

The type 'System.Windows.Markup.IQueryAmbient' is defined in an assembly that is not referenced.

The above error is simply saying that I’m trying to open a WPF Window inside of a DLL and not an EXE. Then, there’s this error:

The component 'Songhay.Wpf.WordWalkingStick.Views.ClientView' does not have a resource identified by the URI '/Songhay.Wpf.WordWalkingStick;component/views/clientview.xaml'.

This boils down to the absence of a facility that associates WPF Window XAML with the WPF “code” (an instance). This facility is associated with WPF EXEs and not WPF DLLs. Visual Studio auto-generates a WPF EXE class called App.g.cs (in your \obj\Debug folder) with this call in it: System.Windows.Application.LoadComponent(this, resourceLocater) where resourceLocater is a badly named variable containing a System.Uri pointing to the XAML like ClientView.xaml mentioned above.

I’m sure Chris Sells has a whole chapter written on how WPF depends on System.Windows.Application for its very life. It is my loss (quite literally of time) for not having read about it.

I have shown myself a little something with this unit test:

[STAThread]
[TestMethod]
public void ShouldOpenWindow()
{
    Application app = new Application();
    app.Run(new Window());
}

Failing to wrap a new Window in the System.Windows.Application.Run() method will throw an error from the land of COM talking about, “Why did you pull the rug from underneath me?”