There are a lot of .NET developers out there with not a lot of experience doing WPF projects. This article is aimed at providing you with great information for the developer so you can be more effective on both the project and working with the designer.. There is quite a bit of information here, so I will try to break it down into usable sections that you can take advantage of. Some of this is background information but it's really important to understand these things going into the project development cycle.

Getting Started

1) Create your projects for your designers and fellow developers in Visual Studio 2008.

Why do this? because the project files will be more completely set up and all the needed references will be there. This means you can easily target delivery platforms easier. Expression Studio doesn't support all deployment forms like XBAPs in WPF for instance. Also if you are targeting a ONECLICK install, projects only are available in Visual Studio for deployment..

Version Control?

Visual Studio also works with a number of version control systems. There is a special enterprise team version of Visual Studio called  Visual Studio Team Suite, that lets teams work across diverse geography and is great for larger teams. If you are working with a smaller group you might be working with Visual Source Safe.

Another option for version control that I really like is VisualSVN. This brings the Subversion client to Visual Studio as a plug-in. Subversion is a very popular cross platform web-based source code control and management system that works on many platforms including Windows, Mac, and Linux systems. It's free or nearly free for most people's use. VisualSVN works with TortoiseSVN and the Subversion client for Windows rather effectively. Together you can set up your own code repository and server, that works across systems and platforms.

I find this really to be an economic and working solution for most workgroups, and situations where you are working with hardware from different vendors. Because this is web-based and it's actually pretty secure, you will find this really easy to setup and work with. It's quite transparent with both Windows Explorer (when using TortoiseSVN) . If you want to know more about setting up the actual subversion server on Windows (versus some other platform). There is a great article on setup that you can read here.

Version Control of the Project with Designers Files

At the moment Expression Studio doesn't come with built-in version control, but that shouldn't stop you.. You should probably let the developer/project manager be in charge of this and have them issue copies of the Visual Studio Solution Files/Projects to the designers for later check-in by the project manager. He can make sure everything gets updated correctly. For the designer keeping track of project graphical assets, they should check out Expression Media, which is designed to do just this including cataloging and version control of multiple versions of the same graphics files. In the end the designer hands off graphics that have been exported to XAML (an XML based language) to be inserted in your Visual Studio project. These files look like code.

PHOTOSHOP? NO MORE! Illustrator or Expression Design is the way to go!

Lately, I have noticed a number of different folks working on WPF projects and even a few Silverlight projects who worked with an outside design shop, that supplied PSD files as assets. Unfortunately for the project manager, the designers they contracted with provided graphical assets for the UI as Photoshop PSD bitmap files instead of vector graphics. For folks working on WPF projects, using PSD files probably not the best approach. While you can insert bitmaps into projects, well they don't resize well at all and in some situations come out very fuzzy depending on the layout manager you are using on the screen.

Both WPF and Silverlight were designed mainly to work with vector graphics from a structured drawing program. So instead of Adobe Photoshop, the project manager should have specified that the graphical asset deliverables be delivered from a structured drawing tool. Structured drawing scale and don't pixelize into big squares when scaled-up.

If the design house you are working with is using Adobe products only, they should have created the graphics in Adobe Illustrator and used the XAML export plug-in to deliver the final graphical assets in XAML directly. There is also a plug-in for Adobe Fireworks, that is available. Interestingly enough both of these work on the Mac platform to export XAML on that platform natively as well.. So don't let anyone tell you that you can only do XAML on PC or Windows. That's a serious myth. There is even a tool for Silverlight video that works like Expression Media Encoder called Flip4Mac that works from within QuickTime.

While I am dispelling myths, most people have never heard of Expression Design in Expression Studio. I have heard some designers tell me it's not as capable as Adobe Illustrator, or other vector-based drawing programs. Well the reality of this is it's just not the case. Expression Design was originally a product that Microsoft purchased from a company called Creature House. It was originally known as Creature House Expression 3. This version was available for the Mac and PC. Before that the product at one time was known as part of the Fractal Design Painter package.. It was and is still well known as the first program to bring "Photoshop-Style" filters and painterly effects to vector graphics. So, next time you see Expression Design being talked about or used, give it the "respect" it deserves.

2) Decide ahead of time where you are going to locate your Styling information will reside in the project...

Will you be just using the default styles?  Do you want to style inline? On every control? Or one or more "global styles".  Do you want to style things at the "application level" ? It's very important to decide this at the start of your project. Most people who are working on an application that requires branding and identity will want to style at the "application level". This has several advantages for both designers and developers. This will allow you to "re-skin" your interface and develop more than one theme..

Something to know as you begin to style your application, and this is about events and button states. Every version of Windows has a built in theme. If you are used to web development most other vendors products out there give you for instance four states that a button can have which shows a different graphic when you "Mouse Over", "MouseDown", or "Mouse Out". The Windows events model for WPF gives you way more any states and properties to interact with. It's a big advantage to developers versus other products that just do the web model because you have much more interactivity options with your users to reveal different things. If you get to know this model you will begin to appreciate it and love it for it's flexibility and mature approach.

Anyway, because of Windows expanded events model,  you can have more than one event firing at time or have a multiple properties changed due to the "triggers" that have been set up for the end user.. Each version of Windows has a built-in style that can disable some of these events and properties because each built-in theme doesn't use some of these. It always isn't apparent that this is the case inside of the current version of Blend as you are working. Also, you might want to create your application so it's style looks correct no matter which version of Windows you are using.. To do this you need to set-up a themes directly that supports styling to each of these. Microsoft has already helped you with this by developing theme files that match the different versions of Windows out there (Vista, XP, Windows Classic). You can download these theme files from MSDN and include them directly in your project.

Styling information can reside in three places in your project and depending on how you decide to theme your projects this can be very important. It's almost a priority to decide these things before anyone sits down to code or design anything because it really will affect all aspects of your work and your ability to later go back and change things. All styling and each level (inline, application, etc.) contains a " <STYLE> </STYLE> tag and is usually stored in a resource dictionary in WPF. At the moment there aren't resource dictionaries in Silverlight, but you can still encode the styles directly via inline methods. As time goes on Silverlight and WPF is getting similar in code and structure, so I expect at some point resource tracking and storage to get very similar, even though right now Silverlight doesn't support the full WPF methodologies. One of the cool things about Expression Blend is that most styles are editable graphically without going into the XAML code for the resource dictionary. They also provide a second set of already styled user controls called "simple styles" which you can take and use or modify for your own use. They provide this in Expression Blend along with the original controls which are called "lookless" because they have no default styling at all in WPF. Silverlight, for purposes of browser consistency provides controls that are styled to fit with the web browsers default styles that they are running from. 

It is possible to style individual controls and link them in individually into the application's main resource dictionary. I don't recommend this method however because it's inefficient, and because they are all not in one place, the application has to "touch" a lot of files while loading. However, if you are making user controls individually which is sometimes easier than creating a controls library .DLL, this method works something like this..

create your user control

<UserControl x:Class="sampleControl"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    Height="Auto" Width="Auto">

...

add your resources section for the user control. Add the MergedDictionaries Tag and source it to whatever file contains your styles

<UserControl.Resources>

       <ResourceDictionary>
           <ResourceDictionary.MergedDictionaries>
               <ResourceDictionary Source="Simple Styles.xaml"/>
                </ResourceDictionary.MergedDictionaries>
          </ResourceDictionary>
</UserControl.Resources>

this method works for individual controls, the best solution is probably to develop a control library (as a .DLL that can just be included in your project). There is a special project in Expression Blend to create a control library. Just remember once you are done with creation, if you include this in your project as a .DLL if you go back later to change or edit this as long as the controls aren't part of the new project and are being called from that .DLL library they can't be changed or restyled.

Most WPF designers and developers really use a lot of created USER CONTROLS, so it's better to keep all of the individual user controls in the main project instead of a library. You should do this until you are completely done with coding the project so styles can be changed and things can be modified directly on the fly during development. If you don't do this you are isolating the designer and developer and changing the workflow and tying the designer's hands. Blend can't see these or change them, if they are all not in the same project files.  You should probably only make a controls library if you aren't restyling anything or at the end of the project after you have final approvals on everything at the stage of optimization and end-user deployment.

This is a big mistake that some integrators and project managers do that ties hands and makes folks have to spend hours reworking their projects. This leads us to our next big suggestion..

3) Consider your folder structure as part of the planning and take into account the potential for changes.

Be flexible with your folder structure and hierarchy. If you don't it will come back to haunt you. account for "application level" changes, and changes you might have to do inline on individual components. Above all observe the coding style that Microsoft recommends for WPF.. Too many developers are used to trying to make their code hard to follow, so that they are in demand and no one can fix their code but their own. This works great if you are the only one developer in the entire project. At that point who would you be hiding your code from anyway?  The relationship has changed, between the designer, integrator, and developer. Both have to make things extremely readable and useable by others involved in the project.. You can't just toss things over the wall right now.

Here's a for instance, lately I have seen several projects where the developer thought that he was being rather "crafty" by coding XAML in his C# code. For instance consider this XAML snippet:

   <Grid>
       <TextBlock x:Name="myBlock"/>
   </Grid>

You could access this textblock in code and it would look something like this (follow the named element "myBlock") :

           myBlock.Text = "Hello";
      myBlock.Background = Brushes.Beige;

While yes you can do this, it can be problematic. Especially if Blend can't recognize this code even on a build. You can have unexpected things happen and no way of telling during your debugging and unit testing why and where things are happening, and if the designer has to go in and make changes later, look out.  Make sure all of the behaviors and changes made in code is noted and can be observed or at least accounted for in the project specification.  Also Blend can't always see stuff you have done in code even after a build if you have in code made things "private". So document these situations thoroughly, if you HAVE to do it..

4) Make sure you observe the WPF threading model so your code works expeditiously and efficiently for your end users.

Windows Presentation Foundation (WPF) is designed to save developers from the difficulties of threading. As a result, the majority of WPF developers won't have to write an interface that uses more than one thread. Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist.

WPF application use typically two threads: one for handling rendering and another for managing the UI. The UI thread queues work items inside an object called a Dispatcher. The Dispatcher selects work items on a priority basis and runs each one to completion.  Every UI thread must have at least one Dispatcher, and each Dispatcher can execute work items in exactly one thread. To build a responsive, user-friendly application. you must maximize the Dispatcher throughput by keeping the work items small. This way items never get stale sitting in the Dispatcher queue waiting for processing. Any perceivable delay between input and response can frustrate a user.

A very important reason for using a single-threaded model is to support interop with Win32, which also has thread affinity requirements.  By adopting a strict thread affinity model, WPF allows you to mix WPF, Windows Forms, and Win32 user interface elements freely within a single application. If you wish to further explore this and exploit use of the dispatcher, I recommend the following article, for further reading from Eran Kampf..

Developing a Robust Data Driven UI Using WPF - The DataModel

5) Above all never severe the lines of communication between you designers, developers, and integrators.

The approach has to be a unified one and since the process is more interactive than before and requires good communications with everyone on the team. You should also all attempt to standardize on the same open coding style that will make your application maintainable by others and sustain it's functionality for a good long product lifecycle. This is the answer to making your life easier. Keep each other informed. Don't write code to insulate yourself from others, instead of writing something that no one else can modify or doing something that no one else knows how it works, you'll be even in more demand the more readable it is and if it maintains the coding style integrity of your team. -->