Related
It is time to write the GUI for my project, and I am wondering what technology to use. I did most of my .NET GUI development in .NET 1 & 2, so I know Windows Forms reasonably well. I am vaguely aware of WPF, but not yet attempted to "get into it".
Are Windows Forms dead or dying? Is WPF a good technology to learn? Is it the future, just a phase, or a technology that can walk hand-in-hand alongside Windows Forms?
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Are WinForms dead or dying?
No. It is not significantly developed further (i.e. no new major additions), but it is fully supported in .NET 4, for example.
Is WPF a good technology to learn?
Yes.
Is it the future, just a phase, or a technology that can walk hand-in-hand alongside WinForms?
It is intended that you eventually move over to WPF, but it is also understood that there are large existing codebases written in WinForms, and there's no business case for rewriting them in WPF. Hence WinForms remains supported.
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Broadly speaking, WPF is much more expressive. If you look at frameworks as set of Lego bricks that can be put together in various ways, WinForms bricks are much larger - each one does a lot - and therefore there are fewer ways to put them all together. Quite often, when you need something-but-not-quite like what an existing brick does, you have to write your own from scratch. In WPF, the bricks are significantly smaller, and can be combined in many interesting and even surprising ways.
For a concrete example, consider how WPF Button is a container that can host arbitrary content - not just image+text as in WinForms, but absolutely any other WPF control or set of controls.
WPF is also much easier to write dynamic layouts in compared to WinForms. The latter has layouts, too, but the problem is that they're a royal PITA to work with in visual designer, and writing WinForms component initialization by code is very tedious. With WPF, you just write XAML markup by hand, and layouts (and control trees in general) are very naturally represented in XML.
Partially stemming from the above, I find that WPF is easier to localize. For one thing, it's because you really do need dynamic layouts for localizability (since you don't know in advance the length of the strings in all locales). WinForms solution to this is to consider not only text labels, but also control position and size, as "localizable property" - so the translator is supposed to rearrange controls on the form himself if he finds that strings don't fit. In WPF, dynamic layouts are the default approach, so localizer just deals with strings.
WPF binding framework is rather powerful (even if verbose, thanks to lack of inline converters), and heavily promotes MVP, and, in general, model/view separation. This is possible to achieve with WinForms in 2.0+, and I try to do that there as well, but it's more tedious, especially with respect to null handling, and sometimes can be rather buggy.
One particular pain point is the way WinForms designer interacts with source control. There are two similar problems here. First of all, designer serializes edited form as code, and sometimes very minor changes in layout can make the designer generate completely different code (this is particularly noticeable if you edit toolbars) because it shuffles the code lines around - i.e. in reality it changed a single property value on one line, but it also reordered everything. This leads to very much noise in history (it's nigh impossible to tell what exactly was changed when looking at diffs), but more importantly, it means that merging such files is a major headache. This usually happens when two people work with the same form at the same time, and then one commits his changes, and the other one tries to commit, finds out that the file was changed in the meantime, tries to merge, sees the diffs, and jumps out of the nearest window.
A very similar problem happens when you use WinForms localizable forms, which pushes some properties to a resource file. Again, the designer very much likes to reorder property values in resource file for any trivial change, with all the same problems as described earlier.
Now as to deficiencies in WPF. A major one is that it's quite a bit more complicated, and may feel unfamiliar to someone with experience only with WinForms, VCL, VB, or other similar "traditional" frameworks. Another problem is that documentation, in my opinion, is not perfect - it usually gives a decent overview, but rarely covers corner cases, some of which can be pretty important. This is the case for WinForms, too, but there are fewer possible combinations there, so fewer corner cases as well.
There's also the issue of third-party components. WinForms had been around for a long time now, and there are plenty of those available for it, and a lot of them are very mature. WPF is comparatively young and still going through growth pains, and so do most third-party solutions for it.
One particular pet peeve of mine in WPF is the way it antialiases text - which is perceived as being of much worse quality compared to plain Windows ClearType by most people, especially on small font sizes; see this bug report for more info. This is fixed in WPF 4, but that isn't released yet, and even when it will be, chances are that you'll want to stick with the tried and true 3.5 SP1 for some time; and the fix isn't backported.
WinForms aren't dead or dying...they just can't provide the same User Experience that WPF can (without A LOT of work). They're just older technology.
WPF is a good technology to learn. It provides the ability to provide a much richer User Experience with less work.
The model for working with WPF is definitely different than WinForms. I've used both (WinForms more heavily than WPF/Silverlight) and the most difficult transitions for me were:
XAML, which isn't as bad if you have experience with another markup language like MXML.
DataBinding
Interface Event Handling (MouseOver effects, Timelines, etc.)
WinForms is far from dead/dying. WPF is simply a newer way to tackling the UI as it promotes things that were more difficult in WinForms. Things like separating the model behind the UI from the actual UI so it can easily be tested is a big factor.
It's definitely worth learning, but make sure to learn "the WPF way" of creating the screens rather than just fitting your WinForms-way into it. It's a different way of coding.
Perspective from 2016:
I don't often advocate chiming in on a question this old, but thought an epilogue may be appropriate on this one. Why? Because even now (2016), I hear developers in corporate environments still asking this question.
Yes, seven years later, WinForms is still alive in corporate environments, and still supported by Microsoft. Google Trends shows a slow, steady decline in interest since mid-2005, with current interest about one-third of 2005's.
WPF made a splash about 2009, but never fully took over as the de facto standard for new UI development. Google Trends shows WPF interest peaking from 2009-2011, then declining faster than WinForms. Current search interest is about half of 2011's, but still nearly double WinForms' current search interest.
So what ARE developers using now? Web-based UIs have exploded in popularity, largely due to the rise of mobile browsing. You could argue over the best way to go about writing a web UI (AngularJS + WebAPI? ASP.NET MVC? React? All are trending upward on Google Trends). Whichever technology you use, it's hard to deny the appeal of writing a (responsive) UI once and having it work on just about all devices and platforms. Cloud hosting services furthered the push to the web by offering virtually instant/infinite scaling with low up-front infrastructure investment.
So today, I'd heartily recommend moving toward a web UI, as it may improve the shelf-life of your app--which often need to last very long in corporate environments. Alternately, if you're a Microsoft-based developer doing mobile development, Xamarin is worth a look.
WinForms will probably be around for a long time to come in corporate environments. They work well enough for many purposes. Many projects are based on WinForms, and many companies will stick with that technology for the duration of projects rather than mix and match.
Having said that, WPF is the future. It is a much more efficient, much more capable UI technology and well worth learning.
WinForms and WPF can coexist in a single application. That will probably be the most common way for them to be introduced to a company (that, and small proof-of-concept projects).
Certainly not.
Winforms are easier to use (Considering you don't know WPF yet) and WPF is quite a departure from the Winforms model.
If you want a simple GUI (standard form stuff) go with Winforms. If you want something a bit more flashy and have the time, go for WPF.
I'm sure there will come a point in the future where WPF is the defacto standard. But for now, I stick with Winforms if I want something quick and clean.
It's worth mentioning that a lot of applications are already using Winforms - meaning maintenance work will often crop up involving WinForms, so don't rite it off just yet.
WinForms is not dead. Google "winforms C# jobs" and you'll find plenty. WPF is the hot stuff but it's still relatively new. It won't be mainstream for another two to three years IMHO.
Here is a good blog post about WinForms and WPF. The overall idea is to choose wisely, meaning that there isn't one winning over the other. Each have a different subset of features.
Making the decision between WPF and WinForms however is a different story. Sure, WPF is the new hotness and WinForms is old and busted but is it the right choice? Obviously "it depends" on the situation and Microsoft is continuing to deliver and support WinForms so it won't be going away anytime soon. So what are the compelling factors to choose WPF over WinForms? Karl hints at choices of WPF over WinForms in his WPF Business Application series, but the reasons might be subtle for some.
I personally prefer WPF because I started as a Web Developer and find the markup XAML to be more natural.
I think it's definitely worth learning WPF before it becomes more mainstream, it's always good to improve your skillset and to have experience and knowledge of newer technologies is always a plus, especially if WPF is to be more widely used in future.
Also, whilst writing xaml mark-up is very different to creating forms, it's not a million miles away from writing html and will probably not be too much of a departure for you if you've done any web development.
Whilst WinForms is an older technology that doesn't mean it will ever disappear though, we still have applications where I work that are written in VB6. Only half of our development department work with .NET - we're split into 3 teams, one team is still using .NET 1.1, another team is using .NET 2 and the team I'm on is using .NET 3.5 (you could say we're the lucky ones!)
We started using WPF for a new project and frankly, it's hard to go back to WinForms. Lots of neat stuff that I can't go withouh anymore.
One word of advice though. Even though you can do much more complex layout with WPF (like it's mentionned, a button, or almost anything really, can host other stuff like image, textbox and even more), some other 'basics' stuff found within WinForm are hard to reproduce.
Example : Before the WPF toolkit came out, WPF didn't have datagrids and datetime picker, so you had to do it yourself. Also, it still doesn't have MaskTextBox, you have to do it yourself or download it from third parties. Last one I ran into which I actually find annoting is with Treeview : the lines between leaves and parents doesn't show.
That being said, still much better than WinForm on most aspects.
we start using wpf in a new project we have
the new application includes a lot of legacy code in winforms.
whenever we want to use old dialog of winforms it is possible.
when you getr use to WPF you don't realy want to go back to winforms. it is just much more easy to do GUI stuff that woul take you lot of time in winforms.
any way it take some time to learn the stuff and be able to use all it's abilities (not just UI but also data binding and commands pattens).
having somone experienced that can help with first architecture can be very helpful.
We are a team of .net winform and asp.net developers building custom enterprise applications for organisations mainly in the public sector. Is it time to retrain/retool the team in WPF/Silverlight? How to make management, in first place and clients second buy the idea?
Clients shouldn't care, necessarily. You'll convince clients by showing them how you can be more productive and succeed in their goals, not by explaining tech. to them.
Management, on the other hand, is trickier. You need to convince them of the arguments for using WPF or Silverlight vs. Windows Forms. This can include:
Easier maintainability, especially when designed properly
More flexibility
More options to gain a competitive edge, via using new techniques such as better graphics/etc
Better support/lifecycle, since the newer technologies are actively developed and improved by Microsoft
Better deployment options (particularly with Silverlight), allowing for more flexible deployment strategies
Personally, I think that with VS 2010, WPF is finally mature enough to be the only option. Previously it was held back by performance issues, poor text rendering and a lack of out-of-the-box controls.
Here's what Rocky has to say, and I completely agree with him:
Silverlight and WPF both compete with
Windows Forms. Poor Windows Forms is
getting no love, no meaningful
enhancements or new features. It is
just there. At the same time,
Silverlight gets a new release in less
than 12 month cycles, and WPF gets all
sorts of amazingly cool new features
for Windows 7. You tell me whether
Windows Forms is legacy. But whatever
you decide, I’m surely spending zero
cycles of my time on it
http://www.lhotka.net/weblog/ItIsOnly8HowCanItBeLegacy.aspx
Before you go down that path, have a careful read of the Silverlight 4 news that is coming out of PDC. You will end up doing a mix of both Silverlight and WPF, it is unlikely that you will end up doing only one, and they are sufficiently alike that skills from one can be used in the other. However you don't want to be wasting money and time on Silverlight training that is out of date, as Silverlight 4 will be no more than 6 or 9 months away from being released (possibly sooner). Therefore you may want to do the WPF training first.
To add to what #Reed said:
faster development cycle (once the developers are familiar with the technology)
very easy to do automated testing, including automated UI testing
Is it possible for you to step towards WPF by embedding a WPF app into one of your existing WinForm applications?
It can be a lot harder to sell a complete retooling without an example of some of the benefits (in particular, maintainability and flexibility, especially in the UI). Try starting with a well used portion of your current application and giving a demo with it in WPF.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Most restrictions and tricks with windows forms are common to most programmers. But since .NET 3.0 there is also WPF available, the Windows Presentation Foundation. It is said that you can make "sexy applications" more easy with it and with .NET 3.5 SP1 it got a good speed boost on execution.
But on the other side a lot of things are working different with WPF. I will not say it is more difficult but you have to learn "everything" from scratch.
My question: Is it worth to spend this extra time when you have to create a new GUI and there is no time pressure for the project?
After three months of trying to hammer out a line-of-business (LOB) application on WPF, I reached a point of considering turning back to Windows Forms for my project, and in researching other people's opinions, came across this thread...
Yes, WPF is a brilliant technology and it has benefits that span far beyond mere eye-candy... the templating and binding capabilities are great examples. The whole object model offers more flexibility and broader possibilities. That doesn't, however, make it the defacto platform for future LOB applications.
The "problems" which WPF solves in terms of separating GUI from business logic aren't problems which can't be readily solved in Windows Forms by simply starting with the right architecture and mind-set. Even the object-path binding capabilities of WPF can be reproduced in Windows Forms with some very simple helper classes. The data template capabilities of WPF are very nice, but again they're nothing that you can't simulate in Windows Forms on those rare occasions when you absolutely don't know exactly what objects you're going to represent on any given part of the screen.
Where Windows Forms races ahead is in terms of maturity. You can't swing a dead cat on Google without hitting some blog where someone has solved a Windows Forms problem for you. WPF, on the other hand, has comparatively less learning resources available, fewer custom controls available, and hasn't had as many of its teething problems solved.
At the peak of making a WPF vs Windows Forms decision has got to be the maturity of the development environment. Windows Forms editors are slick, responsive and intuitive. Feedback about errors gets to you instantly, the solutions are usually obvious, and the compile->debug->edit cycle in Windows Forms is very quick.
WPF applications, on the other hand, have comparatively pathetic design time support, with the design view all-too ready to chicken out at the first encounter of an error, often requiring a project build after the fix before the designer is willing to kick in again. Drag'n'drop of components from the toolbox might as well not be supported, given the vast range of circumstances under which it either doesn't work at all, or yields completely unintuitive results. Despite the promise of the WpfToolkit, there still isn't a usable DataGrid for WPF that yields any kind of resonable performance or design time friendliness.
Debugging WPF applications is a bit like the old ASP.NET debugging paradigm... hit F5 -> wait -> launch -> error -> stop -> fix -> hit F5 -> wait -> launch -> error -> groan -> stop -> fix -> hit F5.... All XAML which your program is running is locked, and tracking down XAML specific problems is often tedious.
The bottom line, simply put, is that the development tools for Windows Forms are going to have you banging out front-ends in a fraction of the time of a WPF application... especially if you're creating master-detail grids or spreadsheet like interfaces, which most LOB have. With Windows Forms, you start with 90% of the work already done for you.
I'm a huge fan of the WPF architecture. I just wish the design-time tool-set didn't feel like a pre-alpha debug-build.
Edit: This answer was posted about .NET 3.5 + Visual Studio 2008, but .NET 4.0 with Visual Studio 2010 ships with a WPF data grid. While many improvements have been made to the new WPF development experience, my answer here remains unchanged, and I'd like to add the following suggestion:
If you're in a rush to do RAD development, go with Windows Forms. If you're looking to produce a well architected, maintainable, scalable, resource firendly, multi-user Line-Of-Business application, consider ASP.NET MVC + HTML 5 + jQuery... My projects with these technologies have resulted in better outcomes, sooner, for my customers. MVC offers all of the same templating that WPF does, and jQuery enables animations and complex interactions. More importantly, an ASP.NET MVC + jQuery solution doesn't require your end users to have modern desktops with decent graphics hardware.
I'm seven months into using WPF on what has now become a core system for my customer, and I'd like to share some more thoughts with you about the experience of learning and using WPF as a line of business presentation platform.
In general, the comments I made above still hold... The design time support for WPF isn't here yet. If you're in a big rush to get a rich-client application out of the door, go with Windows Forms. Period. Microsoft aren't in any hurry to discontinue the GDI / Windows Forms platform, so you can count on good support for a fair time into the future.
WPF is not easy to master, but that shouldn't be where you leave your descision about whether or not to invest your time and energy into learning WPF. Despite its present lack of maturity, WPF is built around some useful, modern concepts.
In WPF, for example, your investment in well-written business objects with sound validating logic is a solid investment. Unlike Windows Forms, WPF's data binding is briming with features that allow interface controls to react to invalid user input without writing GUI code to detect those errors. This is valuable.
The styling and templating capabilities in WPF have proven to be valuable too. Despite the common misconception that the only use for styling and templating is to create on-screen eye-candy, the truth is that these features significantly simplify the coding of a user interface which gives rich feedback - like buttons that disable/enable themselves base on the state of the underlying business logic layer, or tooltips which intelligently find their text based on the state of the object under the cursor, etc.
These all add up to incredibly valuable features for "nothing fancy" business applications, simply because they make it easy to keep the interface congruent with the underlying data.
In a nutshell:
In Windows Forms you design your user
interface, then write code to drive
that user interface, which generally
also includes code to drive your
data objects.
In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.
It's a seemingly subtle difference, but it makes a huge difference in your ability to re-use code... which begs the question: "Is the Windows Forms vs WPF question actually an investment decision?"
(This seems to have become my favourite thread.)
Are there any compelling reasons to use WPF
Absolutely! WPF is absolutely incredible! It will be a major benefit for practically any project because it has so many features and abilities that Windows Forms lacks.
For business applications the biggest wins will be:
The fantastic data binding and templating make the biggest difference. Once a decent data model is in place, it only takes a few clicks to create a data template and use Expression Blend to configure exactly how your object will look using drag-and-drop. And binding to things like color or shape is trivial.
Screen layout is incredibly flexible. Not only can everything in WPF smoothly adjust to container size and shape changes, but items can trivially be enlarged and rotated, and even extend outside their containing frame.
Ordinary objects can be presented any way you like, can easily have different presentations in different screens, can share presentation, and can adapt their presentation to changes in data values.
If you need to print, rendering to the printer is trivial. Properly configured, WPF makes Crystal Reports or SQL Server Reporting Services (SSRS) look like a child's toy.
Your user interface will look and feel much more dynamic, including nice features such as buttons that animate when you pass the mouse over them.
For utilities and games, other advantages come to the forefront:
You can easily add shapes, lines, and arbitrary drawings to your application without using an external editor. Every component of these can be data-bound and animated, or controlled by code. In Windows Forms you ususally just have to import a bitmap and use it as-is unless you want to go to a lot of work.,
Animations are cool! Users will be really impressed, as long as you don't overdo it. They can also help people see what is going on and reduce the need for hilighting. For example, when dragging an object you can animate the target to show what will happen if you drop it.
Colors, gradient fills, brushes, fancy fonts, rotation of any objects, tile brushes, etc. Anything you want graphically is yours for the asking.
Incredibly customizable. I needed to draw railroad tracks for one application, so I could drop a train on them. A couple of hours later I had railroad tracks I could draw anywhere on the screen using Bézier curves, and they would join and switch automatically.
The bottom line is that any significant-size GUI you could build in Windows Forms can be built in WPF in a third of the effort (or less) and look way, way better.
Does WPF require more resources (RAM in particular)
You do pay a price compared to Windows Forms, but it is a small one.
RAM can go up or down depending on your implementation. WPF stores its data more efficiently so individual objects are smaller, but there tend to be more objects in WPF than in Windows Forms so this balances out, and either one can come out ahead.
CPU will go up compared to Windows Forms. In my experience, the actual update of WPF objects onscreen takes about twice as much CPU as normal Windows Forms rendering. If your application spends most of its time updating the screen, WPF may not be for you. But in that case you're probably not using Windows Forms either: Most serious games are written directly to DirectX.
Disk usage will be slightly less for WPF because it takes so much less code than Windows Forms. The data will be the same size, of course.
One more note about CPU use: Animations and transforms (motion, translation, etc.) is actually more efficient on WPF than in Windows Forms because of its retained mode storage. It is the initial getting of the objects up there that is slower.
Maintenance overhead
WPF is a huge win over Windows Forms when it comes to maintenance. Since everything is done in 1/5 as much code as before, there is 1/5 as much to maintain. Plus all the boilerplate stuff is gone so you can focus on the code that actually does the work.
Benefits of XAML
XAML is the core of WPF. Although WPF can be used without XAML, XAML makes it incredibly easy to use. XAML has HTML's ability to easily specify a user interface, but its built-in tags are much more powerful, and you can easily define your own. (In fact, it is normal to do so).
Some specific advantages of XAML:
Your entire UI is defined in a text file that is easy to read and manipulate, both for users and tools
MarkupExtensions allow Bindings to be specified in a clear and simple way
Type converters allow properties with complex types to be easily specified. For example, you can say Brush="Green" or you can specify a radial gradient brush with three stops.
You can create your own elements
You can easily leverage WPF's powerful "attached properties"
Other insights
I dreamed of something like WPF for many years. Many people have implemented portions of this functionality, but to get it all in one place and at such a price ($0) is amazing.
WPF is a huge paradigm shift from Windows Forms and will take some getting used to, but the time spend learning it will pay itself back many-fold.
WPF still has a few warts even five years later, but its power will totally blow you away once you experience it. If someone tries to drag you back to Windows Forms, you'll only go kicking and screaming.
Tips:
- Do get a copy of Expression Blend for development
- Do edit XAML by hand occasionally
- Don't give up when it seems strange at first
WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.
Are your developers willing (preferrably, EAGER) to spend the time it takes to learn to use WPF effectively? I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!
Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?
Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether? Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early '90s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.
Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interop with Win Forms is NOT seamless)?
Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months?
This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice. Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache. Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.
You can find more in-depth WPF-related information in an entry on my blog:
http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx
WPF requires either Windows Vista or Windows XP SP2, which is not an onerous requirement, but it is a relevant one. If you want to run on Windows 2000 (which some people still do), then WPF won't work for you.
WPF is also a newer technology and not as proven as Windows Forms so you might choose Windows Forms as a less risky option, particularly for larger applications.
That being said, yes WPF is the future. Visual Studio 2010 is being rewritten in WPF, which will probably be the largest WPF application to date and it will also be a real test for the technology.
Obviously, legacy Windows Forms applications would be another situation where it is the correct choice.
As others have said, there are advantages and disadvantages either way you go here. The advantages of WPF, as others have said, include:
The ability to make very rich UIs relatively easily.
Easier animation and special effects
Inherent scalability (use the Windows Vista magnifier tool on a WPF application, and on a Windows Forms application: Note that in the WPF application, all the vector art scales beautifully)
(OPINION ALERT) I feel it's "easier" to do document-oriented systems in WPF
However, there are drawbacks to WPF, where Windows Forms comes out on top:
WPF's in-box control suite is far more limited than that of Windows Forms.
There's greater support in the third-party control space for Windows Forms. (That's changing, of course, but think about it: Windows Forms has been around since 2001; WPF just a few years. By advantage of time, Windows Forms has greater support in the community.)
Most developers already know Windows Forms; WPF provides a new learning curve
Finally, bear in mind that you can create great, attractive and engaging UIs in either tool, if you do the work (or use the right third-party tools). At the end of the day, neither is necessarily better in all circumstances. Use what feels right for the project.
The programming model for WPF is more open and flexible than Windows Forms is, but like ASP.NET MVC, it requires a little more discipline in terms of correctly implementing Model-View-ViewModel patterns.
My first LOB application with WPF ended up as an utter failuire, because it was a resource hog which brought my end-user's very-low-end laptops grinding to a halt... and this was ultimately because I just lept in with WPF + LINQ to SQL and expected a good result... and this is where WPF diverges so strongly from Windows Forms... In Windows Forms, you can get away with that sort of thing. WPF is much heavier on resources than Windows Forms, and if you don't architect your application to be lean, you end up with a 800-pound gorilla.
Don't shy away from WPF... explore it. But be aware that the acceptable sins of Windows Forms coding won't produce good results in WPF. They're fundamentally different engines, which lend themselves to fundamentally different coding patterns.
Last Word: If you do go ahead with WPF, get well acquianted with data virtualization for use with lists and grids. What is a simple data-bound ListItem or GridCell ends up being a hefty logical + visual object-graph in WPF, and if you don't learn how to virtualize, you application won't perform well on large data sets.
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.
Both of technologies have their pros and cons. In a large application with a "classic" UI I'd use Windows Forms. In an application which require a rich user interface (skinning, animations, changing user interface) I'd choose WPF. Please check the article WPF vs. Windows Forms comparing WPF and Windows Forms.
Aside from the flexibility in UI design, there are some technical advantages to WPF:
1.) WPF doesn't rely on GDI objects. Well, I think it uses 2 GDI objects for the instance of the window itself, but that's practically nothing. I've been involved to a certain extent in a very large internal Windows Forms application. The people in our office sometimes run 3 or 4 instances of it simultaneously. The problem is that they frequently run into the 10,000 GDI object limit inherent to Windows 2000, XP and Vista. When that happens the entire OS becomes unresponsive and you'll start to see visual artifacts. The only way to clear it up is to close applications down.
2.) WPF utilizes the GPU. The ability for WPF to off-load some of the UI processing to the GPU is brilliant. I only expect this aspect of it to get better with time. As a former OpenGL programming hobbyist I can appreciate the power that comes from the GPU. I mean, my $100 video card has 112 cores running at 1.5 GHz each (and that's not top of the line by any means). That kind of parallel processing power can put any quad-core CPU to shame.
However, WPF is still pretty new. It won't run on Windows 2000. And in fact, a WPF application can be slow to start up after a fresh reboot. I talk about all of this on my blog:
http://blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html
I think it is worth learning WPF. Once you are up to speed, design work on your forms is much easier IMHO. I wouldn't worry as much about the 'sexy' stuff. Most of this is just a fad. You can make 'normal' Winforms-style applications very quickly and easy in WPF.
The whole concept lends itself to easier design IMO.
I don't agree with some of the answers here. WPF is really well suited for line of business (LOB) applications. (The frog design LOB client is the best example). And besides all the possibilities to have your UI be eye candy (which is not necessary in business applications), WPF offers a lot more for you.
The data binding and templating features are just superior to Windows Forms. It also offers a far better way for separating code and presentation.
We've successfully used WPF for 2 LOB applications in teams with no more than 2-3 developers.
The biggest problem you will face is probably the steep learning curve of WPF (compared to Windows Forms) which will decrease development speed with developers not used to WPF.
We are currently rewriting our application in WPF from Windows Forms. Yes, there is a steep learning curve and you have to "re-learn" some things, but it is so worth it. And combined with WCF, we are finding we are writing less code, faster, and more robust than ever before.
Stick with it for a while, read Adam Nathan's book, and check out the ever growing library of third-party controls like those from Telerik and ComponentOne. One negative, in my view, is that the design tool, Expression Blend, is very awkward to use. The latest version is still in beta, but it just doesn't feel right to those of us who have used Visual Studio for years. Yes, it's mainly for designers, but some things you just can't do in Visual Studio.
Consider WPF if interface design is important to you, because WPF can deliver better UI experience. But Windows Forms has on its side the years of evolution, so it's proven to work and you can find many versed programmers for that platform.
Also portability may be an issue, WPF only works with Windows XP SP2 and up.
Also, WPF has a steep learning curve, meaning it's not easy to deliver a quality product without having specific WPF experience.
Well, one answer is "when you have to support 1.1 or 2.0", since WPF is part of .NET 3.0. There are known OS limitations for WPF, and there is an obvious skills issue: if you have a team of developers that know winforms, then it may be easier to turn out robust code with winforms. However, if you are writing a lot of UI code it is probably worth beginning to pick up WPF at some point.
WPF also shares a lot in common with Silverlight, so it has transferable benefits.
WPF comes with many advantages such as superb data binding features,
separation of concerns, separation of design and logic etc...
As a developer I enjoy the ability to define my UI using XAML as opposed to
being tied to the Windows Forms designer and I feel good knowing I can count
on another designer to make my app look good.
Personally I don't care older versions of Windows are not supported,
but one of the big problems with WPF is that is is not (currently/ever) supported
by Mono (http://www.mono-project.com) so WPF apps will not run on Mac OS or Linux.
(Altough Silverlight applications will).
If you have the time and resources to invest in learning WPF, do it!
Even if you're going to be writing Silverlight applications to support multiple OS's.
If you need desktop applications to run on multiple OS's stick with SWF.
There are many differences. We loved WPF for:
The declarative style of programming.
Animations and state transitions
Expression Blend is a great tool
Good style support.
However, we stuck with Windows Forms because:
The extra time it takes for a
developer to learn WPF when they
already know Windows Forms.
WPF will not run on Windows 2000 or
lower.
The biggest consideration when deciding which one to use is to consider what .NET Framework your target audience have installed. I find that more people have the lower .NET Framework versions that only support Windows Forms, but that's just my personal experience.
The advantages of WPF is that it is much easier to create nice looking GUI's with custom controls and animations. WPF also helps further serparate the presentation and logic layers. If you have designers, it allows you to farm of 95% of this work to non-coders and allows the coders to work on logic. The disadvantages are the software costs for Expressions Blend, and the lack of any of the Visual Studio code profiling tools working well as they tend to get caught up in the frameworks calls in trying to render XAML. I am sure there are others but these were the only two we really saw.
The main consideration is if you wish to require your customers to have to install .NET 3.0 or even better .NET 3.5 SP1. You will get some niegative feedback
WPF makes it much easier to hand off the forms design work to an actual designer, not a developer in designer's clothing. If that's something you'd like to do, WPF is your answer. If the classic Windows styled buttons are fine, then Windows Forms is probably the way to go.
(Multiple answers make the claim that you should use WPF if interface design is "important to you" but that's pretty vague. Interface design is always "important".)
If you have an MSDN license, check out Expression tools. It's designed explicitly for WPF, exports directly to Visual Studio and it may help ease your transition.
If you only care about supporting Windows and don't mind the time it takes to learn it, go with WPF. It's fast, flexible, easy to reskin, and has great tools to work with it.
As a side bonus, Silverlight is based on WPF and starting with either lets you gain the know how for working with the other. If things continue to go web based, having prior knowledge (and a library of existing code) to transfer easily to the browser (or Windows Live Mesh) might help give your software an extra lease of life.
If you decide to go with WPF, considering pros and cons already explained in the above answers, I highly recommend going through this dnrTV episode with Billy Hollis
In DotNetRocks episode 315, Brian Noyes discusses this extensively.
There is a known issue with text rendering in WPF. Many users report that the heavy use of anti-aliasing and pixel-blending used causes blurry text. This is a big deal breaker in some circumstances and, as far as I know, has been acknowledged by Microsoft at some level.
For the last 3 1/2 years I've been doing Windows Forms development (at two companies). Both applications were used extensively and ended up having GDI problems. Large Windows Forms applications will eventually run out of GDI resources - causing the end user to have to reboot.
Scott is complaining about Expression Blend and how it doesn't make sense to him as a developer. My first reaction to Expression Blend was like that. However, now I see it as an invaluable tool, but it really depends on what type of developer you are.
I am user interface developer that has had to perform the Integrator role, and I eventually found Expression Blend invaluable to create styles, and control templates in a WYSIWYG manner. I almost always have Expression Blend and Visual Studio up an running on the same project at the same time.
I also think that playing around in Expression Blend and taking a look at the XAML that gets spit out is an excellent way to learn the WPF API ... much like using the designer in Windows Forms and checking the C# code it spits out is helpful in learning how to use whatever you are designing there.
Expression Blend is helpful. Just give it a try, especially if you are working on the visuals for the application.
A quote from an earlier post from Mark:
In Windows Forms you design your user interface, then write code to drive that user interface, which generally also includes code to drive your data objects.
In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.
I would argue that this is more of a design choice, rather than whether or not you are using Windows Forms or WPF. However, I can appreciate that certain technologies might be better suited for a particular approach.
Only if you don't have WPF expertise and you don't want to invest in it :)
My company is just starting to look at using WPF for migrating all of our 10 year old business applications. These applications will most of the time be running on computers that have limited/old hardware. We are now a little worried that the hardware might be too limited for using WPF.
We have installed Family.Show (http://www.vertigo.com/familyshow.aspx) on an basic older computer and that seems to run ok. But we would like know what your experiences with WPF on older hardware is? Anyone out there willing to share some experiences with us?
I would add several things:
The first is, as Stu said, it really depends on what you are doing. In particular, we have found a noticeable difference between WPF 2D and WPF 3D. If you are doing any WPF 3D stuff at all, your performance is highly dependent on the quality of the video card (see the Graphic Rendering Tiers link already mentioned). In particular, we released a WPF 3D feature in April of this year, and it really only worked smoothly on Tier 2 hardware.
Second, I would point you to Jossef Goldberg's blog. It has a wealth of information on WPF performance related items.
Third, I would grab and utilize the WPFPerf tools. They were recently updated actually. Jossef's blog post will point you in the right direction there as well.
Fourth, take advantage of virtualization wherever you can.
Finally, I would recommend monitoring performance all the way through the development life cycle. I think the story goes that originally the Blend team did not evaluate performance (for their first release) till closer to the end, and it made solving the problem much more difficult.
Update: There is another StackOverflow post on this subject. Just wanted to point others to it.
WPF apps will generally run no slower than their equivalents using other technologies. In other words, performance depends on what you're doing. If you have a basic app with some simple data entry controls and a grid or two then it'll be a lot less demanding than an app that has animated custom controls with overlaid video, etc.
You should also bear in mind that you must have at least XP SP2 to install WPF, which sets a reasonable hardware baseline anyway.
In summary you should have no problems running a WPF app on older hardware as long as you are sensible with the frills. Given WPF's templated controls it's also fairly trivial to test for a basic level of client performance at runtime (see Graphics Rendering Tiers) and only enable more advanced features on suitable hardware.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
The rich presentational capabilities of WPF and Silverlight mean developers like me will be working closely with graphic designers more often these days, as is the case in my next project.
Does anyone out there have any tips and experience (from both points of view) on making this go more smoothly?
For example, when I mentioned source control to a designer recently, I was quickly told you can't source control graphics, images etc, so it is a waste of time. So I responded: ok but, what about XAML files in WPF/Silverlight?
Scott Hanselman spoke about this topic in a podcast, but he focused more on the tools, while I'm more interested in the communication issues/aspects.
One of the things I've discovered is that how you as a developer design your code greatly affects what the designer can do with it. Often you download a Silverlight or WPF sample application from the web and open it up in Blend, just to have Blend crash on you because the code doesn't run well inside the designer. If it doesn't crash, it seldom look anything like the running application.
I recently gave a talk at Tech Ed Australia and New Zealand about techniques you can apply to "design for designability". A short bulled list is included:
Write code that can take advantage of data binding. The Model-View-ViewModel or the presentation pattern is a good fit for this.
Supply "design time" stubs for your service dependencies. If the class you are binding against makes web service calls be sure to replace the web service client with a stub class that returns "dummy data" that the designer consumes inside blend. This can easily be done through IoC and Dependency Injection, injecting one implementation if HtmlPage.IsEnabled == false.
By using data binding you can limit the number of "named elements" you have in your XAML file. If you write allot of code behind you end up coupling your C# code against named elements such as txtName or txtAddress, making it easy for the designer to "screw up".
Use a command pattern instead of code behind click event handlers. By loosely couple the invoker of an event from the handler you can have less named elements, and you give the designer the freedom to choose between a Button or a Menu Item to invoke a specific command.
Test your code in Blend! Even if you consider your self a pure developer you should test that your code is consumable by a tool, and strive to get a best possible experience at design time. Some would argue that a tool shouldn't effect your software design, just as some one complains about "design for testability", and making software design decisions just to make the code more testable. I think it's a smart thing to do, and the only way you can get some real designer-developer work flow going.
Other tips would be to start small. If your designer is new to XAML, WPF and Silverlight, start by introducing them to the project team, and have them do some basic designs in the tools they know. Let them do some buttons and illustrations in Adobe Illustrator, and export it to XAML, and show them how you can leverage their design assets directly. Continue by introducing more and more, and hopefully they get interested and want to make the switch to Blend. It's quite a learning curve, but it sure is worth it!
Good luck!
PS: I have written allot about patterns and making designer friendly code on my blog at http://jonas.follesoe.no. You can also find links to a video recording of my Tech Ed talk, as well as lots of links to further reading on the topic.
I have spent 4 months on a project working extremely closely with a designer and he has still not picked up the basic idea of CVS (which is not my choice of source control system). I'm talking template files, JavaScript and CSS here. He's not stupid, it's just one of these things that makes his job harder so he resists fully commiting himself to it.
In my case I had to really hammer home the point that almost all of my JavaScript depended on the mark-up and when he changed his pure CSS, DIV-based layout into a table-based one without telling me then all my JS is going to break.
Often during the course of the project myself and the designer, who I get on with quite well and play soccer with outside of work, had very heated exchanges about our respective responsibilities. If I didn't know him well enough to just get past these exchanges then I think it would have created an unbearable working environment. So I think it's important you establish between you both and with some sort of manager or project supervisor exactly what is expected of both parties during the project.
In my case there have been very few problems lately, because the situation with CVS has been sorted out as well as the idea that he can't just go and change the mark-up whenever he feels like it. Rather than try and create template files and work on them directly, the designer only works on static files and its my responsibility to plug them into my template files.
It's all about communication and a little bit of compromise on both sides.
This may be a bit off topic (I'm replying specifically to your question about source control and graphics), but you can put binary data (images etc.) into source control (and in my opinion in a lot of cases should) -- they just take up more disk space and you can't use a diff view to analyze what has changed in any meaningful way, but what you do gain is a history of commit messages documenting each revision, rollback ability and the ability to easily archive (tagging a revision in SVN terms) all files (be they visual assets, documentation, source code, whatever) belonging to a specific release/version together. It's also easier for your build system to just fetch everything required for building a specific version of your software from the source control.
Involve the graphic designer in early design and architecture sessions.
You want to involve them to reveal misaligned assumptions and to establish a pattern of working together rather than throwing things back and forth over the wall.
Originally, it was envisioned that professional designers would work in Expression Blend, and developers would work in Visual Studio, making changes to a single shared set of source files. While it is certainly possible to do that (so long as you are careful to check regularly that you haven't broken something expected by the other dev. or design tool), many members of the developer community, including some inside Microsoft, have discovered benefits in keeping Blend and Visual Studio project activity SEPARATE -- even to the point of manually cutting and pasting carefully-refactored versions of Blend-generated Xaml into the "official" VStudio project source, rather than allowing designers and developers operate directly on a single shared code base. Microsoft's User Experience Team in the UK published a video describing the problems they ran into trying to coordinate designer and developer efforts on actual projects.
Real_World_WPF_DesignersAndDevelopersWorkingTogether
One of the main lessons learned is that you can't staff a project with designers and developers who are completely ignorant of each other's domains. Developers need to be familiar enough with Blend that they can provide designers with useful UI shells for the designer to decorate, and useful data "stubs" the designer can design interactivity against, and the designer needs to have enough understanding of development issues that they don't do things like delete controls and replace them with custom visual elements - not realizing that they broke all the functionality tied to the original control.
Microsoft's vision of the designer/developer workflow marriage definitely seems to break down in real life. I have experience working on a fairly large scale WPF project which involved 2 dedicated design resources for about 4 months. Here are some facts that Microsoft seems to often forget.
Designers often prefer to use Macs (designers at my company are 100% Mac - 0% Windows)
Blend doesn't run on a Mac (as far as VM solutions - designers typically don't like geeky solutions like running weird applications in a foreign OS).
Designers use their tools of the trade - Photoshop and Illustrator. Period.
The aggressiveness of today's schedules usually don't provide ample time for designers to learn a totally new application / design environment (like Blend).
So given the above, what I noticed was that this creates a new job type - either a very techy designer or a graphically enlightened programmer. Basically, someone who can take the design assets in raw form - usually .psd or illustrator format and apply these as needed to the application process.
I turned out to be that guy (graphically enlightened programmer). I spent a lot of time exporting XAML from Illustrator files, cleaning them up by hand when necessary, and making these assets easily usable display objects in Blend or VS. There were also times where I would take a a design element and re-draw it using blend ( usually when the original asset was bitmap based and it made more sense to convert it to vector).
My application may not have been typical - as it was extremely graphically rich and resolution independence was one of the main objectives as it needed to look good on multiple resolutions and aspect ratios (think of the difficulties in designing for TV in todays landscape - things have to look good in both low-res SD and scale well up to hi-res HD).
In summary, I think WPF is an awesome technology and absolutely a step in the right direction for Microsoft. It however is not the end-all be-all solution for integrating the designer in the development process - unless you redefine the role of designer.
I'm Felix Corke, the designer from the hanselman podcast you mentioned, so here are a couple of points from a genuine creative as opposed to a developer.
It took a long time to become used to developer tools - I'd never heard of Visual Studio, C# or any type of source control when I first started doing xaml work a few years ago. They were as alien to me as maybe Illustrator or 3DsMax would be to you.
My biggest single point is that the designer can't be expected to know developer practices - please be prepared to do a great deal of hand-holding. You won't have to learn anything new whereas the designer will be launched into a whole new scary side of app development. I made a right mess of a few solutions and checkins (and still do).
Happily, I've learned to become more of an design focussed integrator than a straight creative, and maybe this is a role you need to include in your project. This is the illustration I made for our beauty and the geek - designer/developer session at Mix - if either of you is at too far at either end of the spectrum it can be difficult understand how the other works and what their role should be.
Happy to answer any specific questions!
ps you do NOT want 100Mb+ .psd files in source control ;)
The extent to which designers have come to feel entitled to be distant from the whole of the work involved in building a software product is a much bigger problem that needs to be solved. Don't pander to any designer's expressed right to not have to know how their work gets integrated into the whole.
The kind of stark specialization that has grown up in the designer community is one of the biggest industrial maturity problems that faces the software development industry. It's an extent of specialization that predictably creates more rework and longer cycle times.
This is also true of developers' sense of entitlement to go blissfully unaware of interaction design and implementation.
Extreme specialization is always an exponential multiplier in productivity problems. Solve it organizationally by adopting processes that promote learning cultures. This is the level of maturity that most other production industries have already realized, and that software drags woefully behind.
At every place in a development workflow where handoffs occur between over-specialization, work queues and buffers form. Software remains one of the few industries that doesn't recognize this as one of the biggest problems we face. This is even more exacerbated in the Microsoft community as over-specialization seems ever-more normal due to Microsoft's perpetuation of over-specialization through its tools and guidance. Unless you can afford to waste as much money as Microsoft does in development efforts, you should look to methodologies that are much better informed on questions of flow and productivity.
Consequently, the developer who cannot test and the tester who cannot code is a symptom of the same industrial immaturity.
You won't learn any of this from the Scrum template for TFS. Microsoft was years behind the curve in getting agile thinking in-play even in its most rudimentary forms, and now that we're progressing into Lean thinking, Microsoft will be another three to five years away from trying to incorporate Lean thinking into its product lines. Don't wait for Microsoft to tell you how to shape a team and a workflow. You can learn right now from the people that Microsoft will ultimately pay attention to in a few years.
I'm a big believer in the Integrator approach which is really the role I have had to perform to make our WPF efforts successful.
Laurent Bugnion has a post on this that describes what I'm talking about. Robby Ingebretsen is also a big believer in this approach.
But basically, someone has to cover the 'gap' that exists between the developer world and designer world. What usually happens is that this person comes from either the developer world or the designer world. If they come from the developer world, then they are probably a developer with designer tendencies (they're responsible for look and feel, the visuals in the application, the layout of the screens, etc.). If they come from the designer world, then they aren't afraid of code and the enjoy diving down every now and then to code to get that animation or whatever sparkling.
However, regardless of what world they come from, they usually have to build skills that they never have had before. In my case, I am developer that loves the user interface layer and therefore I would say that I am a developer with designer tendencies. In order to cover that gap and have productive conversations with our graphics designer, I have had to pick up a whole bunch of designer type skills like: learning to use Expression Design, XAM 3D, etc.
Shannon Braun recently gave a presentation at a local developer conference about the developer/designer relationship and the workflows that the community is discovering works for them. I didn't attend the conference, but I thought his slides were a great discussion on the matter.
In my experience, the integrator or "devsigner" role really needs to be involved in this process unless everyone on the (small) team are able to perform this role. This is a very rare circumstance. Usually you will find that developers are very good at developing but aren't so great with design/usability and designers are great with aesthetics/usability but don't want to or are not educated enough to code. Having someone that can crossover into both worlds and "speak the language" is very important.
The integrator needs to coordinate the controls that are being developed with the design assets that are being created by the designers. In our current project, we have 6 active developers and 2 designers from an outside shop. I am the integrator for this project and I spend most of my day in Expression Blend. The developers work primarily in VS creating controls that meet our product spec and the design shop is designing what the end product will look like. The designers are working in Illustrator. My job is to take the Illustrator files and create control styles from them and then apply them to the controls developed by our development team. As we move towards Blend 3 with native support for PSD and AI files, this task becomes much easier.
It is very helpful to create the "look" for your application in a separate solution from the main trunk of the application and then merge your ResourceDictionaries into the main app later. You can get the look and feel correct without getting too caught up in what could still be incomplete controls.
I am going to assume that you refer to RIA projects since your mention of SL.
I have worked one quite a few RIA projects with Adobe designing and developing applications and services.
The best advice I can give you based on based on my 14 years experience as an UX and Visual designer with some programming experience although pathetic compared to you guys.
Accept that you wont understand each other.
The programmer thinks in what functionality should be done, the designer think in how the functionality should behave.
For the developer a button is mostly generic, for the designer it's not the case. Designers think in composition, developers think in frameworks.
So learn to understand that your responsibility is different.
You the developer DO need to think about how generic your code is and can't afford to treat everything as being unique and a hardcoded composition. That is unless you can automate that uniqueness somehow.
The designer DO need to think about the application or service as somehow unique. It might mean that a button is not a button. There might be different sizes or colors or other annoyances.
So make sure you develop a good relationship with the designer by acknowledging that you understand the designers responsibility and make sure he understands yours.
It's not that you are not interested in making the best application in the world. It's just that some of these design decisions takes quite a lot of time.
Make sure that you get very clear on how the designer should deliver to you so you don't waste his or your own time. What format, assets? Naming?
All things that are involved in delivery from one paradigme to another.
And most importantly communicate and respect that they don't know how to do JavaScript or how understand the basic ideas of CVS.
Most developers you wouldn't know how to kern to save their life, what a widow is, how to best layer FireWorks or create a photo-realistic icon, come up with a good tagline or make something understandable to average Joe in 4 words. You don't know what a grid or alignment is and you tend to make things green and purple on black.
And the designer should understand that just because you deal with programming does not mean you are a robot, that you can't have creative ideas and solutions. He should also try to learn how to program at least pseudo program so that he understands what's involved in making your project.
And most importantly. Don't start to debate Mac vs. PC :) Projects have been canceled because of this.
Quite frankly you should tell the designer that images can, should and "will be put in source control mister!" :)
It may be slightly non-conventional and you wont be able to do a merge or anything of that nature, but there will be revisions and a history, etc .. Images can also be embedded in a resource file which goes into source control as well.
XAML can (and should) be put in source control and as its a markup file it will benefit from all of the features.
As far as tips from working with a designer, the one you are working with scares the heck outta me just by that comment alone, so it may all boil down to WHO you are working with. I would explain basic best practices in a nice manner and proceed from there.