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).
Related
As far as I understand, I can use Windows Forms in Windows 8 Pro (non-RT) applications. However I was wondering if I can develop an app which has a nice WinRT interface for the main part as well as a WinForms part for the more complicated parts which benefit from stuff like TreeViews and which are complicated and useless to reimplement. Which development environment would I need for that?
Windows Store Applications are intentionally limited and do not include the entire .NET Framework, including Windows Forms, and WPF/Windows Presentation Foundation. You cannot mix the two components. They are executed and managed in very different ways (see here for details about how Windows Store apps are executed).
However I was wondering if I can develop an app which has a nice WinRT
interface for the main part as well as a WinForms part for the more
complicated parts which benefit from stuff like TreeViews and which
are complicated and useless to reimplement.
Even communicating from a traditional Win32 application to a Windows Store application is prohibited (for applications released via the Store -- see here for a discussion). So, building your application in two pieces really isn't very practical (and the user experience of swapping between the two applications may be unpleasant for many users).
There's an intentional design and usability model for designing a Windows App Store application that must be considered when developing a touch friendly application that does not lend itself to a typical Windows Forms application. Tree views for example might be replaced with a group/detail/detail type navigation.
I'd highly recommend you read through, if you haven't already, the UX guide for developing Windows Store apps. A transition between a modern UI application and a Windows Form application would be jarring to say the least, unless you spent an tremendous amount of effort trying to mimic the general UI principles established for a Windows Store application. While it's possible to do, and there are some 3rd parties that may provide reasonable components, it's never really going to be truly the same (and probably not worth the engineering effort to try to make it identical).
Some might suggest that you consider instead using WPF. Depending on the type of application and the current skill set of the developers, that might be a good fit for your needs. Again, there are 3rd party resources for mimicking the style of a modern Windows Store application that you could apply to your application if desired.
There can be a very steep learning curve for WPF if you have a reasonably complex data-entry/manipulation style application where you may need robust data validation, etc., typical of a line-of-business application. It's also hard to tell where Microsoft is going with technology these days -- WPF, while not deprecated, certainly isn't being enhanced like it once was. As Visual Studio 2012+ depend on it heavily, WPF isn't going away, but expect fewer new features. It's a robust platform generally speaking though, and it may meet your needs as is.
You may want to go through the exercise of modeling your application as a Windows Store application to see if the widgets and functionality you would need are present. Depending on your requirements, you may find that not everything is there yet (Windows 8.1 has some new goodies, so look at those too!).
Also, if you're familiar with JavaScript, you might also want to look at creating your application using WinJS. It's super powerful and can often use many existing JavaScript/HTML solutions, assuming they meet your UI and functional requirements.
WinRT UI components can only be used in windows store apps and Windows Forms only in desktop apps so you will not be able to mixed both.
If you are looking into making a desktop app for windows 8, maybe you should look into using WPF.
If you are looking into making a windows store app, there is plenty of third party control libraries which have a TreeView including the WinRT xaml toolkit .
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.
I'm about to start developing a small Windows application using Microsoft Visual C# 2008 (Express edition). I'm very new to C# and .NET, so this is a newbie question. Should I start with WPF or should I stick with the old WinForms?
My application has several screens, all having several text-boxes, check-boxes, combo-boxes, not anything more. The application will retrieve data from several COM objects, and communicate through standard TCP/IP sockets, both of which are unrelated to the UI.
The UI is not fancy in any way (and I don't need it to be). However, the world seems to be moving to WPF. What are the considerations of choosing WPF over WinForms for my case? What's the recommended approach?
Thanks
I have not used Forms enough to say anything about which is better, but I have found WPF to be easy enough to use for minor applications.
I figure that if it's the standard people are moving towards and it's not difficult, then it's good practice to start using it.
WPF = Future + Fancy stuff
WinForms = WYSIWYG greatness
Choose whichever of the above you find the most atractive :)
It depends. Stick with WinForms if you're comfortable with it.
If you want to be able to have a better look-and-feel with more customized controls, and you're willing to spend the time to learn XAML and the differences between WPF and WinForms, then go for it. But expect it to take some time, there is a learning curve.
Interesting, how all answers target the developer: familiarity with a framework, the learning curve, the technical features of a framework etc.
If it's a simple application, none of the technical aspects really matter. You sound like you have some experience programming, in that case the chosen framework doesnt really matter. Focus on your users instead.
Can you guarantee that your users have the latest .net runtime installed? Are they willing/able to install it if they dont?
Will your users be put off by an "outdated" look and feel?
The way you phrased your question, i think you should use WinForms. You seem to imply ("stick with winforms") that you have experience in WinForms and that you dont have any fancy demands for the UI, so i see no reason to put yourself on a steep learning curve that WPF can be.
I personally like alot of the things that WPF provides. It has easy data binding, validation, and customizing UI things is simple. Plus with the new Expression Blend 3.0 that was released yesterday they have sketchflow WPF apps that you can share with others and get feedback files from. It is a pretty interesting little addition to the WPF world.
The nice thing is that if you find a Winform control or something that needs to be WPF and you picked the other way, they seem to work well with each other now.
It's a trade-off.
You will most likely be more productive starting off in Windows Forms because the programming paradigm is closer to most other UI development libraries you might be familiar with. There are also many libraries of UI control available for WinForms (including ActiveX) that make creation of attractive, functional UI easier. Unfortunately, MS has indicated that WinForms will not see any more advancement in the future because their emphasis is on WPF.
WPF, on the other hand, is more more sophisticated and robust and can help you create very attractive, rich interfaces. WPF sometimes requires the use of more sophisticated back-end programming paradigms like MVVM to create effective applications. Also, as a newer technology, there are fewer mature libraries and tools to help you develop WPF apps. For development tools you have VS2008 and Expression Blend (which is quite nice BTW). Advanced graphics features like gradients, color themes, skinning, control customization are all more powerful in WPF. But this power comes at a price - most developers find WPF to have a more significant learning curve that WinForms.
WPF is something completely new if you are used to WinForms, so it'll take quite a while to get used to it. But i prefer WPF not because of the looks, for me it's more the great layout system (once you got used to it), its databinding infrastructure and in combination with patterns like MVVM, the separation of UI and business logic.
I have to develop a basic "line of business" application with the usual functionality like orders, stock control, sales, reports, etc.
I will use WPF to develop this application to run on Windows but I want to develop it "open" so I can do a Windows Forms application using the same structure (maybe to run over Mono) or even a Silverlight module. Can someone that did something like that (and survived) give me a sugestion on a guideline or something like that where I can find good practices? I'm a Delphi developer with some intermediate knowledge on C# but there are so many "amazing" libraries, frameworks and patterns that I'm a little lost on what would be good for that project.
Something like: Use EF (maybe wait for ef4?) or nHibernate, or ADO.NET, and expose your data using WCF, or webservices, or forget Mono because of the flexibility loss, etc. Can someone give me a tip on how you would do it? If someone has a bad experience in this type of project, it would be nice to hear from you as well. There is a lot of learning in the wrong decisions too :)
Mono doesn't implement WPF, it's not even on the roadmap. I'm not sure about Entity Framework...
You could probably do it in Silverlight (which has an open source implementation), but it's not ideal for creating desktop (although it is possible since Silverlight 3)
Where do I start?
First, from your description, you're in over your head.
Second, you're trying to pick a technology stack when everything is new to you.
In the best situation, I'd recommend a good training class in a few of the technologies you mentioned so you get a better understanding of them. I'd also recommend a mentor, someone who's done this before.
Reality though, may not allow for training or a mentor. In that case I'd recommend writing several real-life throw away programs. Take one piece of business functionality and try to write it in a few of the technologies you mentioned. If one feels better, and gives you what you want DECISION MADE! Don't stop with the first one that seems to work, try some more.
You should also listen to some good podcasts. I recommend Dot Net Rocks for a good grasp of the technology. The earlier podcasts for this site were also a very good source for some design discussions StackOverflow podcast
Best of luck.
I had to do something very similar recently in WPF. I have an ASP.NET background, but I have never worked with WPF (or WinForms for that matter), and it had me stumped for a while, but the longer I have been working on it (about 3 weeks now), the easier it has gotten. I really just searched Stack Overflow and Google for code snippets similar to what I was doing, and worked through them and changed them as needed. My company bought a book that helped me out as well (It was WPF Unleashed published by Sams), and it was pretty good. I do wish you luck on your first WPF app.
If you separate the business model and business logic from the user interface,
using MVC (Model View Controller) or MVVM (Model View View-Model) or a simular design pattern,
then you can have multiple user interfaces connected to the same business model + business logic and even connect the same user interface to other business models + business logic.
Thank you all for your suport... Brad, I'm already following your advices, doing some test cases to see what looks good... my problem is that altough I can develop an application in WPF and have a intermediate understanding in using the wpf databindings, generics, linq, anonymous objects, all the cool stuff, I always hear about this and that as the solution for all the worlds problems (like mvvm, or parallel programming, or functional languages, etc) and makes me feel "wrong" in my decisions and a bad developer if I do not use any of this nice technologies. I know the concepts but do not dominate it, and seems a lot of things to learn, sadly I do not have that much time.
Thomas, exactly because mono do not support WPF i want to make the application as isolated as i can, so I can do a simple winform layer to manipulate the data.
darthnosaj, thank you, I'm doing that too, searching internet and found much information (and this nice site full of hellpful people :) )
And Danny, thats what i think i need... will take a look on some sample applications using mvvm and see if that works for me. For what i heard is almost a crime not to use in that case in wich I want that kind of isolation.
Again, thanks all :)
I would suggest you keep your application N-Tier. Make all the entities, data adapter, and business logic separated from the actual desktop application. This way you can use WPF on the Windows platform and use Mono/GTK# on the Linux/Mac platforms.
You will only need to write duplicate code to support the actual GUI application functionality, while your code from the separate entity/data access/business logic library (e.g. DLL/class library) can be used in both your WPF and Mono/GTK# projects. Just add the DLL as a reference to the WPF and Mono/GTK# projects.
There is a good video from Channel 9 on building N-Tier applications
There is also MSDN documentation and guidelines on building N-Tier applications
I am a long time MFC programmer and know it quite well. Recently we are planning for a large desktop application. In order to beat competition, one requirement is polished UI. We narrow down the choices to three:
WinForms
MFC
QT4
We looked at some big WinForms applications, such as Paint.Net, and feel that it still lacks power of performance. The startup takes a while and some UI parts do not look very nice.
We had great hopes in QT4, but after writing several programs on it, we find that the looks of a QT4 application is not at par with native Windows UI. It still looks differently. Also we worry about about lack of widgets (for example, the color picker and calendar control in the library quite suck).
MFC is a safe bet, especially with components from Codejock.com. The UI interface looks quite polished with codeJock toolkit. And all widgets needed are there. The problem is that its coding style is quite outdated.
What will you choose for your next desktop application?
WinForms is effectively at the end of its life now. You should look at WPF.
See WPF: Any cool UI ideas i can look at? for links to some nice examples.
WinForms is really easy to get into if you know MFC (it's still based on the core Win32 concepts, so you don't need to learn much to get up to speed). Compared to MFC, you can develop much faster, and there is so much more library support for everything in .net that you have to write for yourself or find 3rd party libraries for in MFC. Often I find the .net solution to a big problem is around 3-10 lines of code, whereas the equivalent MFC solution would be hundreds or thousands of lines. I wouldn't even consider MFC a starter now that I've used WinForms in C#.
We're building some very large C# applications and the performance is perfectly fine. If any small part of the program is really performance-critical, it's really easy to plug in a bit of unmanaged C++. I found startup times abysmal in XP in the early days, but with more recent .nets and Vista, startup time is comparable to MFC apps.
So I'd go for WinForms/.net at a minimum.
WPF is also a sensible future-facing approach to consider.
WPF is a good option if you've got design skills or can ask for someone to prettify your UI. I think it's definitely one of the most versatile options.
You could also use components like DevExpress or Telerik, both have an extensive library of WinForms controls and as of recently WPF controls. I've used DevExpress myself and am rather pleased with the looks. Although these library don't come cheap, but they do carry quite a lot of functionality.
I've never worked with QT4 so can't judge that.
For my next desktop app I would use:
on Windows:
Probably the old fashioned Windows API (without MFC) because I am familiar with it.
Maybe Qt, because I'd like to try it out.
on MacOSX: Cocoa
on Linux: Qt
Not that I am very fond of MFC, but if you are comfortable with it, go ahead. It is not going away any time soon, although it surely won't be updated and improved as much as WPF.
Having spent 12+ years developing MFC applications, and now using WPF for less than a year, there is no way I would go back to MFC. At previous employers, we would spend countless hours customizing UI behavior and getting the right graphical look that would take a fraction of the time in WPF. Not to mention the added flexibility of being able to work with the UI as XAML (XML,) as opposed to the rather outdated resource editor.
If your application has to be C++ (as opposed to C#,) then I assume that using WPF would be a little more non-trivial. I haven't done .NET inside of C++, but I remember the overviews presenting it as a fair amount of extra work.
We at my work are currently revamping a GUI app from VB6 to make it look "prettier". We've chosen the .NET winforms platform for our upgrade since most of our coders are familiar with it. .NET has a few libraries dedicated to graphics, and there is a wide range of nice-looking user controls already built into the library. Asside from those, there are many, MANY custom-made controls out there such as the ComponentONE library, and there are a lot of opensource controls for enterprise use that look nice as well (you can search CodeProject.com's articles section for some free, downloadable controls that look very vista/windows 7-esk).
The framework also natively doublebuffers windows, and has bufferedGraphics classes that you can use to manually handle doublebuffering if you so choose.
However, windows forms do still ghost when dealing with high res images as background pictures and the only way to really fix it seems to be to use the DirectX libraries to draw using the graphics hardware on the machine (which is difficult, but atleast its free).
Hopefully that helps your decision on the platform form the windows-forms side.
I would still consider MFC. It's far from dead and especially with the new 2008 feature pack. You get a host of updates and can now create those fancy ribbon UI elements. If you already know MFC then you know the pitfalls (old but some are still there) and can knock out the work quite quickly.
There a ton of UI components you can buy for MFC and it has the benefit of being fairly close to the metal as far as speed goes. There is no need for your end users to install a framework or anything else.
I write C# for my day job, but all my personal projects are MFC/C++ since they don't require my users to have additional frameworks,libraries,etc installed.