We Keep Coding

What would be the best chioce, Windows Forms or WPF development in C#?

When learning the C# language. With all the applications being developed these days. Would I be better off focusing on windows forms development or WPF development. I want to develop software that uses ADO.net for SQL Server database access. Also stand alone applications to integrate with Microsoft Office to create charts and graphs etc...

Although for the purposes of Windows UI that both can achieve similar results, their function is independent of one another as is their purpose.
WinForms is tried and true, non-evolving due to strong roots. It does not mean WinForms is deprecated. It just means that the foundation classes for WinForms are well established and flexible. Keep in mind the flexibility in extending WinForms via the Control class and deep-engineering UI messaging (via handles exposed by the WinForms classes).
WPF however is an abstraction layer to design user interfaces, not necessarily or exclusively Windows user interfaces. The most difficult hurdle to leap is transitioning from the thought of coordinate based user interfaces (pixel/bitmap/index) to vector based user interfaces where WPF can adapt to virtually any size control or plane of rendering.
The benefit of WPF is that you're learning three different targets for your applications - Windows UI, SilverLight, and now Windows Phone. WinForms targets Windows UI and Windows Mobile (CE). A clean UI based on common widgets has an appropriate foundation in WinForms. If a customized, dynamic UI is your target, take WPF for a spin.

I'd be using WPF as it also allows you to do Silverlight applications using the same XAML markup.
Having said that, there are horses for courses so you need to choose the appropriate tool for the job. That does mean you need to know both to make an informed decision. :)

The learning curve with WPF is definitely much steeper - at the same time you can easily whip up some simple UI in Windows Forms to fill your needs in regards to ADO.net or SQL Server database access. Once you add charts/graphs to the mix, you are going to want to learn WPF hands down though.
Also you might want to look at Lightswitch, which takes care of some of the complexity with Silverlight/WPF.

Though WPF is the future and it gives you so much flexibility, I don't recommend switching completely to WPF. Also, you will be able to make the most out of WPF if you have a designer that will be able to work on the design part. I'm not saying you need to have a designer but based on my experience with WPF, if you want to develop a killer looking application, you definitely need to have some one that knows the bits and bytes of WPF. Just as BrokenGlass said, the learning curve with WPF is too steep. So, just make a gradual switch. If you already have some Windows Form applications, try to rewrite some of those in WPF.

The kind of stuff you're trying to do can be done with both WinForms and WPF. WinForms is a more familiar paradigm but (big but) XAML in general, WPF in particular, is not the future but the current way of doing Windows UI's in .NET, WinForms being the past it is basically in maintenance mode (good for existing apps, dare I say obsolete for new apps). Yes, XAML posses a somewhat steep learning curve, but the abilities you get are worth the effort, besides there are more and more resources (books, libraries) on XAML/WPF/Silverlight while for WinForms there are plenty but stagnant (I haven't seen any new edition of a WinForms book in a couple of years). One thing worth noting is the databinding capacities of XAML which render unnecesary many of the code moving data from/to objects/datasets to/from visual controls.

WPF and XAML is a learning curve but my experience is can build more powerful, concise, and supportable applications in in less time. Can copy and paste XAML from one page to another. On Windows Forms I gave up on copy and past of UI elements from one page (form) to another as too many times it locked the whole app. Two way data binding is a dream. WPF UI has a more commercial grade look. Portability to Silverlight. For me it is 98% of what I would get from C++ in a fraction of the effort.

As your prime objective is to learn C# you should concentrate more on language features rather then your UI. You should try to learn and use various features of C# and what all it supports and how. Learning(C#) will be much more in developing Business layer and Data layer of your application rather then your UI; so you should concentrate on building these layers first(with any presentation framework).
I am not sure whether you have any prior experience in any of console applications, WinForms, WPF or ASP.net but for learning purpose you should pick one you are most comfortable with. In case you are starting a fresh then I would suggest you to first start with WinForms as you will be writing a lot of C# code in WinForms then in WPF, and later pick up WPF.
My answer is totally focused on fact that your prime goal is to learn C# and not on which UI framework is better etc.

What are the first steps in C#/.NET development?

Okay, I'm biting the bullet and deciding to get into the whole Microsoft/C#/.NET culture and I'm going to do this by putting together a simple (hah!) application.
It will basically be an application in which I want to store images and associate with them other optional things.
It must be able to import images from the filesystem (and hopefully camera/scanner) then allow the user to add text, audio and other information.
I plan to store the images and auxillary information into a database. What the application will do with said data isn't important (yet).
Keep in mind I know absolutely nothing about C# or .NET although, as an old codger, I know a great deal about many other things and will regale/bore you with stories and anecdotes until you quietly slip away :-)
What are the first steps to take in developing such an application? I've already set out UI layouts and likely process flows although it may be that the development environment dictates changes.
Development environment is currently XP SP3 + VS2008 (though I can upgrade if absolutely necessary).
What should I be looking at as the first step? Are there any gotchas I should be looking out for?

Have you decided for win forms or WPF? I've been doing win forms for the past 4 years and WPF was a great discovery for me, with the flexibility it affords. It might be fitted for your application and the different types of content you'll want to add and give you a flexibility that win forms can't give.
As for actually developing, I think loading images from the disk would be the first step, showing them in the UI and getting user input for them - you would get to work with the different objects and see how the framework handles things.
A tutorial about the field validation I mentioned in my comment is here - haven't done it, but something similar. You can also see the xaml code paired with the C# code there.
After looking for the differences between win forms and WPF I found that there are a few win forms controls that are missing from WPF. More on that on MSDN (compariosn chart) and a post from March with a more detailed chart.
It's also worth mentioning that you can include win forms controls in WPF applications and vice versa, but there are some limitations.

Just a couple of pointers, it would be easy to overwhelm you as you are just starting with this tech stack. First step, use SQLServer 2008 Express, it has better ability to deal with image data (images can be saved directly to the filesystem, but they are still in a table).
Apart from that, you can design your screen with the GUI, and then hook the bits up one by one to your retreived data. Create a new Windows Forms app, or a WPF one, and start from there (i'm assuming that you know about the toolbox window and just dragging components on to the designer and setting their properties in the Properties window).

If you're looking win forms you're going to have drag-and-drop UI pretty easily.
If you want to use a database than you're probably going to find MS-SQL the easiest to cooperate with. Look up LINQ-2-SQL, it lets you access your database through an object layer by simply dragging your tables onto a pane.
Fun things to use: extension methods, partial classes, LINQ (query any collection with inline lambdas) and even class/method attributes.

My $0,02:
a) Get to know the platform a bit, types, collections, events/delegates(/lambdas), etc etc
b) Dive into WPF
c) Learn about database connectivity (LINQ2SQL or NHibernate (or ....)
d) Learn about the MVVM pattern to get to deliver solid wpf applications, doing so forces you to dive deeper into the workings of WPF (routed commands, tunneling/bubbleing etc)
e) Learn more about patterns to get a more solid grasp of OO (this: http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1276066663&sr=8-1 is an absolute pearl for that)
f) etc

If you aren't too desperate to get your hands dirty straight away I'd suggest this book: CLR via C#.
It is written for those with programming experience on platforms other than .Net and provides a clear and comprehensive explanation of C# and how it runs on the .NET CLR.
By reading this initially you might avoid writing some of the poorly constructed applications that many of us wrote before properly understanding the technology.

Buy a book on C# & .NET FW fundamentals!
Read! :-)

Read good books about .NET for example CLR via C#.
Read this:
Hidden Features of C#? https://stackoverflow.com/questions/380819/common-programming-mistakes-for-net-developers-to-avoid

What is WPF and how does it compare to WinForms?

I've been looking at WPF, but I've never really worked in it (except for 15 minutes, which prompted this question). I looked at this post but its really about the "Flash" of a WPF. So what is the difference between a Windows Forms application and a WPF application?

WPF is a vector graphics based UI presentation layer where WinForms is not. Why is that important/interesting? By being vector based, it allows the presentation layer to smoothly scale UI elements to any size without distortion.
WPF is also a composable presentation system, which means that pretty much any UI element can be made up of any other UI element. This allows you to easily build up complex UI elements from simpler ones.
WPF is also fully databinding aware, which means that you can bind any property of a UI element to a .NET object (or a property/method of an object), a property of another UI element, or data. Yes, WinForms supports databinding but in a much more limited way.
Finally, WPF is "skinable" or "themeable", which means that as a developer you can use a list box because those are the behaviors you need but someone can "skin" it to look like something completely different.
Think of a list box of images. You want the content to actually be the image but you still want list box behaviors. This is completely trivial to do in WPF by simply using a listbox and changing the content presentation to contain an image rather than text.

A good way of looking at this might start with asking what exactly Winforms is.
Both Winforms and WPF are frameworks designed to make the UI layer of an application easier to code. The really old folks around here might be able to speak about how writing the windows version of "Hello, World" could take 4 pages or so of code. Also, rocks were a good deal softer then and we had to fight of giant lizards while we coded. The Winforms library and designer takes a lot of the common tasks and makes them easier to write.
WPF does the same thing, but with the awareness that those common tasks might now include much more visually interesting things, in addition to including a lot of things that Winforms did not necessarily consider to be part of the UI layer. The way WPF supports commanding, triggers, and databinding are all great parts of the framework, but the core reason for it is the same core reason Winforms had for existing in the first place.
WPFs improvement here is that, instead of giving you the option of either writing a completely custom control from scratch or forcing you to use a single set of controls with limited customization capabilities, you may now separate the function of a control from its appearance. The ability to describe how our controls look in XAML and keep that separate from how the controls work in code is very similar to the HTML/Code model that web programmers are used to working with.
A good WPF application follows the same model that a good Winforms application would; keeping as much stuff as possible out of the UI layer. The core logic of the application and the data layer should be the same, but there are now easier ways of making the visuals more impressive, which is likely why most of the information you've seen on it involves the flashier visual stuff. If you're looking to learn WPF, you can actually start by using it almost exactly as you would Winforms and then refactoring the other features in as you grasp them. For an excellent example of this, I highly recommend Scott Hanselman's series of blog posts on the development of BabySmash, which start here. It's a great walkthrough of the process, both in code and in thought.

To answer your question, a WPF application is a Windows application. WPF is Microsoft's new framework (actually, it is a subsystem of the .NET framework 3.0) for writing rich Windows applications. It is meant as an eventual replacement for WinForms (although admittedly the adoption rate is much slower than MS hoped for).

WPF stands for Windows Presentation Foundation. While WinForms technology depends on GDI/GDI+, WPF is built directly on top of DirectX. That means you can do much more than you can with WinForms, while getting still using the .NET Framework Class library. You can build rich user interfaces, 2D/3D games, presentations and much more. WPF is much like a Flash (swf) movie, without the element "Movie". WPF is based on .NET and can be used to build rich client side web enabled applications.

Start here, there's dozens and dozens of videos: http://www.windowsclient.net/learn
In this case, the marketing schpiel is pretty good:
**"Windows Forms is a set of classes in the .NET Framework that enables rapid development of rich Windows client applications, with powerful, extensible libraries for user-interface controls and graphics. You can incorporate WPF in your Windows Forms applications through WPF-Windows Forms interoperability in the .NET 3.5 Framework."*
*"WPF, a component of Microsoft .NET Framework 3.5, empowers you to build the next-generation of Windows user experiences. WPF supports UI, media, documents, hardware acceleration, vector graphics, scalability to different form factors, interactive data visualization, and superior content readability."**
With WPF you get WAY better graphics support, way more powerful and flexible databinding (if you're working with Data, use WPF.)

WPF is essentially a new API for creating a Graphical User Interfaces for the Windows Platform.
WPF is more than just a next-generation presentation system for building Windows Client application along with visually stunning user interfaces.
WPF is builds on top of the DirectX (Direct3D), instead of relying on the older GDI/GDI+ subsystem.
WPF is a vector graphics based UI presentation layer and being vector based it allows the presentation layer to smoothly scale UI elements to any size without distortion.
WPF is “skin-able” and “theme-able”. It means WPF allows changing the look and feel of any UI control.

From an implementation perspective, one of the main differences is that WPF uses a strictly enforced model-view-viewmodel M-V-VM architecture, with the view being defined in a custom markup language, XAML, the viewmodel being a class with accessible properties, and the model effectively being the data access layer. WinForms, by comparison, has no such explicit separation - although by convention the different aspects may be grouped in different C# files, its all still code. In practice this makes WPF development more like web DOM development, with the WPF framework running in the background and mediating.

Silverlight, Wpf Web App (xbap) or Click Once? Pros and Cons

We are starting a new project and I'm trying to decide which of the Wpf-esque develop/deploy strategies we should go with. In our case we are looking at quite a complex business app that will be used by 100s (not 1000s) of people, So I'm leaning towards a click-once app. My boss likes the idea of a Silverlight app as it means easier deployment. So which way should we jump?
The answer is, of course, "it depends".
So what are the pros and cons of each?
I'll start the ball rolling (Edit Added in some answers from artur carvalho):
Silverlight
Pros
Cross browser
Doesn't require full framework.
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
Cons
Can't interact with client's file system etc
Has less functionality compared with full Wpf (anyone got a good resource that documents differences?)
Single window
Single version
Wpf Web App (xbap)
Pros
Full Wpf.
Cons
Single browser
Requires full framework
Can't interact with client's file system etc
Single window
Single version
Wpf Click once
Pros
Full Wpf
Can work offline
Multiple windows
Multiple versions (con?)
Better access to low level parts of the computer
No downtime for maintenance
Cons
Single browser
Requires full framework
Slightly(?) harder to install.

First, I would evaluate whether a web client (ideally MVC+jQuery) can't do the job...
Assuming a full client is warranted:
If it is a business app that demands a client, I would tend to go with the full framework and ClickOnce; the main difference here (re deployment) is that the client must have the framework installed - but past that, ClickOnce deployment is very pain free. Actually, building a ClickOnce manifest is much easier than Silverlight etc, since the IDE will do almost all of it for you; you just have to host the files somewhere (could be a web URL; could be a network UNC).
This gives you much more control (and power) at the client, as well as a far greater range of existing resources to use (for example, if you need, you can use some legacy winform code on the WPF surface). The "requires full framework" is also one of the largest benefits: "has full framework".
You should also perhaps consider the 3.5 "client profile" setup; not sure how wide-spread this is in reality... but worth knowing about.

You didn't say if this is a company only application or a public facing one. That alone will decide it for you.
If company only, I would go with full WPF click once. This will give you everything.
Full framework should not be an issue. It's a one time install running in the background so it's not something that your decision should depend on. Cons: it runs in Windows only but if your company is Windows only, this should not be an issue.
However WPF apps could be resource hungry so you need to know if all your client machines are capable of running WPF apps smoothly.
If it's an Internet app, go for Silverlight: it runs under different operating systems.

PROs vs. ASP.NET Web Forms
No ViewState or "surprise crap"
o This applies to Silverlight as well. Silverlight brings the "desktop" experience to the end user and there is no ViewState that is used in Silverlight.
Faster server-side & client-side
o Silverlight is faster on the client/server side depending on how you look at it. Silverlight is compiled in a .NET subsystem of Silverlight. You have access to multithreading, LINQ, complex data structures, etc. The performance vs. an ASP.NET or AJAX/JavaScript application is it magnitudes times better because of the client execution and some of the items that normally are handled in a server BLL can be brought down to the client
Simplified model for multiple related views
o Silverlight supports the complete seperation of the data and the UI. Taking this further by just creating seperate views for say another consumer of Silverlight is pretty powerful. You can apply the same MVC/MVP pattern inside Silverlight and attain this level of abstraction. Jason mentions an example of being able to create a seperate view for an iPhone and only the View component has to change. This applies to Silverlight as well for different things. For example, I have large sized Silverlight app I want to port to SharePoint. I can create a "Smaller View" for SharePoint so it fits nicer into the UI. Furthermore, Silverlight Mobile is being private tested now. I would assume that same very powerful level of abstraction applies as well to create a "Mobile view" for your Silverlight application.
Unit Testable
o Silverlight includes a Unit Test framework as well. It can be downloaded here: http://code.msdn.microsoft.com/silverlightut/
Challenges if you are not running IIS 7
o Silverlight does NOT care if you are not running on IIS 6 or IIS 7 or Apache for that matter. This is one feature where Silverlight has an advantage over ASP.NET MVC.
Client Caching
o In ASP.NET Web Forms or MVC, you are caching on the server. Silverlight allows you to cache on the client via Isolated Storage (which can be increased to hundreds of megs if necessary). This allows applications to perform ultra fast without bogging down the hosting server.
CONs vs. ASP.NET Web Forms
Difficult to convert existing code
o Silverlight is a completely different programming platform than either ASP.NET WebForms or MVC. Not only will a lot of the code not convert, you also have to think about the client layer and in most cases a complete re-architecture is needed if you are replacing large modules inside your existing ASP.NET site.
NOT the best SEO out of the box
o Google several months ago started spidering SWF files and adding them to the search engine. I think Silverlight is probably still a ways away here. What you can do for Silverlight SEO is the basic tricks to describe the meta data tags really well around the plug in.
Data access
o Data access in Silverlight is limited to Web Services/WCF/ADO.NET Data Services. You cannot make direct calls via ADO.NET or stored procedures to a database.
Security
o Silverlight runs on the client. A lot of your bits are then roaming in the wild on the internet. Furthermore, some of the data access techniques do not support full WS* standard security. Therefore, beyond certificate based transport security, you are either writing a lot of your own plumbing code or waiting for the next rev. The XAML code is pretty much insecure; not many applications have their Intellectual Property in their UI. In Silverlight, that can be very easily reverse engineered using Silverlight Spy for example. Silverlight, just by nature, is a little less secure than an ASP.NET MVC application. Obviously, you would want to encrypt/obfuscate your Silverlight assemblies before letting them off in the wild.

1. Silverlight can access the DOM from the hosting page and
2. the hosting page can access the Silverlight part.
That's a big + for Silverlight
But all other limitations cry for WPF/Windows-Forms with Clickonce
file access, right mouse click, ease of db access

The pros
The Silverlight plug-in means developers can target a single, consistent runtime for browser-based applications, rather than dealing with the complexity of multiple browsers in different versions. You also get video and multimedia effects that are hard or impossible with pure HTML and JavaScript, though Adobe Systems' Flash has the same advantages.
Execute .NET code without deploying the .NET runtime. The Silverlight plug-in does include a cut-down .NET runtime, but instead of dealing with a large download and the complexities of the Windows installer, the user has a small download of about 4MB, all handled within the browser. In my experience so far, installation is smooth and easy.
Performance is promising. Silverlight comes out well in this prime number calculator, thanks no doubt to JIT compilation to native code, though it may not compare so well for rendering graphics.
Support for Moonlight means there will be an official open source implementation of Silverlight, mitigating the proprietary aspect.
Silverlight interprets XAML directly, whereas Adobe’s XML GUI language, MXML, gets converted to SWF at compiling time. In fact, XAML pages are included as resources in the compiled .XAP binary used for deploying Silverlight applications. A .XAP file is just a ZIP with a different extension. This also means that search engines can potentially index text within a Silverlight application, just as they can with Flash.
Third-party component vendors are already well on with Silverlight add-ons. For example, Infragistics, ComponentOne and DevExpress.
Take your .NET code cross-platform. With Macs popping up everywhere, the ability to migrate Visual Basic or C# code to a cross-platform, browser-based Silverlight client will be increasingly useful. Clearly this only applies to existing .NET developers - I guess this is the main market for Silverlight, but it is a large one. The same applies to the next point:
Uses Visual Studio. Microsoft’s IDE is a mature and well-liked development environment, and since it is also the tool for ASP.NET you can use it for server-side code, as well as for the Silverlight client. For those who don’t get on with Visual Studio, the Silverlight SDK also supports command-line compilation.
Choose your language. Support for multiple languages has been part of .NET since its beginning, and having the .NET runtime in Silverlight 2.0 means you can code your client-side logic in C#, Visual Basic, or thanks to the Dynamic Language Runtime (DLR) Iron Ruby or Iron Python.
Isolated storage gives Silverlight applications local file access, but only in a protected location specific to the application, providing a relatively secure way to get this benefit.
The cons
If Apple won’t even allow Flash on the iPhone, what chance is there for Silverlight?
Silverlight is late to the game. Flash is mature, well trusted and ubiquitous. Silverlight 2 only comes out of beta in the Autumn (we hope). It is the version we care about - the one that includes the .NET runtime - and will still lack support on mobile devices, even Windows Mobile, though this is promised at some unspecified later date.
The design tools are Expression Blend and Expression Design - but who uses them? The design world uses Adobe PhotoShop.
While having solution compatibility between Expression Blend and Visual Studio sounds good, it’s actually a hassle having to use two separate tools, especially when there are niggling incompatibilities, as in the current beta.
No support for the popular H.264 video codec. Instead hi-def video for Silverlight must be in VC-1, which is less common.
It’s another effort to promote proprietary technology rather than open standards.
Yes Linux will be supported via Moonlight, but when? It seems likely that the Linux implementation will always lag behind the Windows and Mac releases.
Silverlight supports SOAP web services, or REST provided you don’t use PUT or DELETE, but doesn’t have an optimized binary protocol like Adobe’s ActionScript Message Format (AMF), which likely means slower performance in some scenarios.
Silverlight is a browser-only solution, whereas Flash can be deployed for the desktop using Adobe Integrated Runtime (AIR). Having said that, yes I have seen this.
You have to develop on Windows. This is particularly a problem for the Expression design tools, since designers have a disproportionately high number of Macs.

You can add to the pros and cons of the usual stuff of the online vs offline debate. Some items:
Pros
wpf(offline):
better access to low level parts of the computer.
cpu usage is local, so you rarely have cpu load issues.
not dependent of the net.
no downtime for maintenance.
silverlight(online):
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
I simplified it a bit, there are gray areas in the list. I only tinkered with XBAP, so that one I'll leave out. The Cons are not hard to figure out after looking to the pros.
HTH

I would consider WPF ClickOnce with sync framework support (www.msdn.com/sync). This would allow you to support limited functionality when the user is not connected to the corporate network (which will eliminate any browser-based deployment scenarios, such as Silverlight and XBAP).

If you don't need all WPF I would try do it in Silvelight first Then you can switch to WPF more easily if you need it later.
Here I think it applies the “less is more” principle: it’s true that with WPF you have much more options and can access to the user computer, but that can finally be more a problem than a help as the times go. Think for example in how many changes you can need to change from Windows XP to Vista in an application that uses a lot of the “user computer” resources!

Mark, what do you mean when saying 'single browser' for XBAP? XBAP does work with Firefox for example. It indeed requires .NET Framework and it is unlikely that we will have WPF in Mono anywhere soon (if ever) so you are stuck with Windows, that's right.

Isn't click once available on firefox these days, via this addon: https://addons.mozilla.org/en-US/firefox/addon/1608

Learning Windows Forms vs. Windows Presentation Foundation

So I've been thinking of going for Microsoft certification and I have to make a choice (for now) between Windows Forms and WPF for developing Windows applications. I have had good exposure to Windows Forms but never tried WPF before. Furthermore, most of the job postings where I live seem to be WinForms-oriented. That might change in the next few years, so I was wondering if I should get started on learning WPF or stick to the tried and true Forms.
Any insight?

Although most current dev.positions will focus on WinForms (or ASP.NET for that matter), WPF is starting to get accepted as a 'serious' platform. With serious I mean that
people are starting to think about using it for LOB-applications. With the release of Prism it's clear that Microsoft is starting to promote WPF in other ways than just the
'eye-candy' features. This means WPF is going to be presented as a WinForms alternative pretty soon.
Learning WPF will mean you'll also learn Silverlight at the same time. So you have two modern technologies at your disposal.
[Added] -WPF has more to offer than just the eye-candy and you can benefit from it a lot without being a creative genius. The API is intuitive (and fun) and can offer a lot of improved productivity.
In short, I'd say if you want to be 'future-proof' learn WPF.

In "enterprise" programming, I don't see an immediate need for WPF development. The reasons for this:
Companies are not running on the newest hardware, and tend to migrate to remote desktops (RDP/Citrix).
A developer can design a decent interface using Windows.Forms controls. In WPF, you need a designer. In large companies there are designers, in most companies I know, the IT department is staffed with programmers and system-engineers, no designers.
Software for the "home market" is another story.

If you want to go the certification route to learn then WPF is a good choice. It will take a few years before it will really take over from winforms but It's a safe bet it will so it's a good investment to learn.
If you're more of a self learner and just want to get certified to improve your chances on the job market then I'd go with winforms for the certification. You can pick up WPF when you need it. By the time you really need to have a WPF certification it will probably be easier for you because you've already used it.

WPF leverages XAML for the design/visual experience this is the same technology that Silverlight uses and in the future will be leveraged heavily by other aspects of .NET 4.0, specifically, WCF (web services) and WF (workflow).
I would highly recommend learning it if you have the cycles, however for certification purposes it might be easier to just go ahead and do the WinForms exam as WPF is quite different and in my experience had a bit of a learning curve (because of how different it is from WinForms).