What's your opinion?
Should I invest time learning UWP+C# or WPF+C#?
To me they both look very similar, except the fact that UWP was built to run in Windows 10 devices... In the other hand I'm also reading that UWP is not going so well....
The your question is related to Entity Framework. Some time ago I read that EF 7 was going to replace EF 6, now I was searching for EF 7, and appears that EF 7 is still in RC1 and never passed that... Microsoft gave up on that one?
What is the best option (for now and future) to DB access that I could use with WPF or UWP (preference for support with SQL, SQLite, and other formats)?
Certainly in my area, there is far more WPF development than UWP. I think that is likely to be the case for some time because there's way more functionality in WPF.
Entity Framework is very popular and a good choice to learn for commercial employment.
All in all WPF and EF are a good choice if you're talking desktop development.
It has to be said that there are more employment opportunities for web developers nowadays though.
There are probably some cold hard stats could back this up but you just need to look at job ads if in doubt.
Opinion based questions are typically discouraged. Regarding EF Core, it's released (supported by Microsoft) and it's under active development.
Related
I have asked this question several time form many developers about the future of WPF in 2015 and in coming years. Someone told me that Microsoft is interested to take this technology in the future also.
Actually i like to develop enterprise and LOB business application in Winforms and now want to move to WPF. Time is short and i need a concrete answer that should i invest my time in WPF or not? If the answer is not then what is the new Microsoft tool to develop business application like Point of sales applications and other large database business applications. I have a keen of new technologies so i don't want to invest my time and money in old technologies. If Microsoft is also not interested in these technologies then i am not also.
So please anyone can tell me that what is the best and new suitable technologies to create business application now a days from Microsoft?
Thanks.
I'll chime in.
This is a tricky conversation because we are on the verge of Windows 10. Let’s start out talking about Windows 8. WinRT XAML for Windows 8 is certainly not ready for you to use it out-of-the-box for to create a full-featured, LOB application. There are too many things missing like validation, windowing, and advanced binding. The Ent. app was not it's primary mission.
On the other hand, WinRT XAML for Windows 8 is perfectly suited for creating a companion, touch-first app that delivers value to tablet-based or phone-based users who would interact with your app in a more limited way – like reporting or workflow. I talk about this more here:
http://blog.jerrynixon.com/2012/08/windows-8-apps-whats-enterprise-to-do.html
WPF is a different story. WPF is proven, right? It totally is. There’s nothing you can dream up that WPF can’t do great. No line-of-business requirement holds it down. It's awesome. What’s more, is that WPF runs on Windows XP, Windows 7, Windows 8, and soon Windows 10. That’s a lot of operating system options.
The future of WPF is quite bright, too. The team is reinvigorated and the improvements slated this year and the new tooling for XAML developers makes it an even better experience. I talk about that more with the WPF team here:
http://blog.jerrynixon.com/2014/11/hey-future-of-wpf.html
WinRT XAML for Windows 10 is different. For one, it’s not going to be an operating system-based system. That means, more like .Net, you just target the framework you require installed and go from there. It is also more fully tooled to compete with the fidelity of WPF XAML to build LOB apps.
But with WinRT XAML for Windows 10 you have to ask yourself how many people will be running Windows 10 because it will not work on previous versions of Windows. Since Windows 10 will offer itself as a free upgrade for the first year, you could argue that many will be running Windows 10, but since the Enterprise version of Windows 10 is not part of that deal, you can only determine that by knowing your IT roadmap. Nobody can do that for you.
All things being equal, if you are simply trying to choose between WinRT XAML for Windows 10 and WPF today, you will choose WPF. Once you have an adequate install base of Windows 10, I think most LOB developers are going to be surprised how tempting an option Windows 10 is. The future of WPF is solid. But the most significant investment into UI technologies at Microsoft is, hands down, WinRT XAML for Windows 10. Does that mean WPF is not future-proof? Of course not. I would choose WPF without any hesitation, as I have done for years.
Best of luck!
Anything can be a gamble, especially with Ms. They (and Intel) tend to throw darts at a wall and when one sticks, it marks the current direction for the week.
According to Microsoft WPF never went away. They forget to tell many employees that. For a while XAML was so very WPF like it was almost the same thing, and for a point of sale system, it seems like if you are going a Microsoft direction, XAML would be the better choice. But again, it is almost the same thing; Windows store app with XAML as opposed to desktop app with WPF. But the direction of the week is yes WPF will go forward and even possibly be Ms strategy for cross platform.
But I would also really ask is Microsoft the right choice for your target? I would think heavily about Android. Not so much just Java, last I looked their roadmap had wpf like functionality targeted for 2024. Or iOS as I don't expect to see Apple sell a cash register anytime soon, so I doubt if they will ever be in the Point of Sale business.
I did a fairly big Point of Sale system a long long time ago. Actually 2 of them. With what I know I would target XAML/Store apps today. But it is about a 51/49 split with Android in my mind. If the customer wanted Android, I would not argue very much.
Today, while I'm running a Silverlight project in the Internet Explorer by pressing F5 in Visual Studio 2012 in my Windows 8 machine, I found that McAfee started to block Silverlight XAPs (Which is loaded by Prism).
This leads me to think again about the future of Silverlight. I'm at the beginning of my LOB Application. Should I stop what I like to work in Silverlight and return back to WPF. I which that I can continue to develop in Silverlight until Windows 8 becomes rich like Silverlight. That is why I limit the Model and MVVM to PCL to be easier to be ported to WinRT in the future. Using await async and so...
Please advise me which is better for a LOB application that will run in three countries throw the Internet. Should I continue in Silverlight for zero deployment, or work in WPF or even Windows Forms and use clickonce?
The fact that McAffee blocked something has NOTHING to do with it's long term future. McAfee is nobody, they don't determine whether or not a specific technology can be used or not, or will be used in the future.
Silverlight seems to have reached a dead end, due to Microsoft realizing that if they create a multi-platform application environment, people might just stop using Windows.
WPF also seems to have been abandoned in favor or WinRT XAML, but of course WinRT XAML is not an option for us developers at the moment, simply because it is Windows 8-only, and our customers don't have Windows 8 or greater.
Besides, technically, WinRT-XAML seems to be really inferior to WPF XAML, and lacks many important features.
Of course winforms is completely useless and is not an option, unless you need to run your applications in my grandma's 80386 computer with an Hercules monochrome monitor
(exaggeration).
Seriously, that dead technology is not the answer to any of today's challenges. Things that you can do easily in any of the XAML-based technologies are either impossible or require a bunch of horrible hacks in winforms.
I suppose the definitive answer depends a lot on the usage scenario, for example:
Silverlight makes more sense if you have to publish your application in a web site and have anyone download it and use it.
WinRT XAML makes sense only if you target Windows 8, or want to create 'metro style' apps.
WPF makes sense if you want to create Windows Desktop applications, and have them deployed via ClickOnce or Windows Installer to a more limited and controlled set of users (because it needs installation of the .Net Framework, which Click-Once can deal with anyways).
winforms makes no sense whatsoever because it's a completely useless dinosaur technology that doesn't support anything.
Thank you very much for your answer and sharing your experience with me. I always try keeping WinRT as a strategy planning for each line of code I write. As I wish to migrate my code easily to WinRT in the future. The future is translated to me as may be within two years I may find myself in a situation that we will be targeted to migrate to something like Windows 9.
The best successful migration scenario - as I wish, it could be by increasing the usage of PCL at the client side as much as possible and test in a small piece of WinRT module.
We hope that Microsoft succeed in Windows 9.
I am sadly decided to shift to WPF instead of Silverlight in case that Silverlight depends on browsers that may not be supported in the future. As we here that Chrome, Safari and others are stopping supporting Silverlight. Why should I insist in relaying with such great technology that is dead before it finishes.
The main difficulties I could face in the future migration could be tied to two patterns:
- Prism.Regions: Windows Store has better than that.
- Prism.Modularity: Windows Store has no migration strategy to that.
At least at the moment I'm writing my thoughts Prism for Windows Store are far from implementing Regions and Modularity.
This is not a final answer but a clue of my what I should and should not to do.
FIXED:
I'm not working with any of technologies specified above, and I was not able to find current information about the the relation between the technologies in the title, so I would be glad if anyone can explain me roughly all this subject..
Based on facts and official Microsoft information, is WPF still relevant? I remember a lot of titles about WPF being dead, about a year ago. What made people say that? Has anything changed during the last year?
Beside, what knowledge is needed for metro/WinRT/build? Is knowing WPF is helpful for any of these? How much?
I have found similar questions, but they are from about a year ago, and I think some stuff have been changed.
That could be a long conversation... :) I'll keep it short as possible...
WPF -> Preferred XAML-based technology for building desktop applications on Windows.
WinRT apps -> next generation platform for building applications that can be delivered through the Windows Store. Your choice of HTML/js stack, XAML/C#/VB, or XAML/C++. The choice of stack is based on your skill set and application needs.
--- HTML/js -> leverage web dev skills and exisiting assets to create WinRT apps
--- XAML/C#/VB -> leverage your .NET and/or XAML skills and assets to create WinRT apps
--- XAML/C++ -> same as above but for C++ and also provides access to things like DirectX
In general, the stacks are relatively equal (outside of DirectX that is C++ only), though some make some things easier than others. It is more a skill/asset choice than anything. Again, this is a broad brush and depending on what your requirements you may find one stack better than another.
WinRT and the desktop both continue on the Intel platform. The ARM platform has WinRT but you cannot deploy desktop apps.
WPF was enhanced in .NET 4.5, the .NET Framework version that comes with Win8. So not dead in Windows 8, enhanced.... Made better faster, stronger than it was before. Writing apps that don't target WinRT, aka are desktop, you've still got tons of options, as you've noted.
Just as an FYI, some pretty cool enhancements to WPF in 4.5. Stuff like Ribbon Control, performance enhancements, binding enhancements and a variety of other goodies. See the MSDN doc for a full list at http://msdn.microsoft.com/en-us/library/bb613588(v=VS.110).aspx .
In PDC sessions i see only Framework 4.0, Azure and WPF.
My all applications is in windows forms and asp.net (codebehind) and framework 2.0 or 3.5. I see i'am obsolete, ok. But my questions is Windows Forms is dead, i need start migrate to WPF or Silverlight? or my Windows forms with Devexpress can leave more than 3 years?
It's not really dead or alive -- more like undead.
I don't think I'd say WinForms is dead... is DOS dead? Do you ever write a console app? There's way to many programs out there on Windows (really the majority of them) that use WinForms for it to just die. Remember Y2K and all those systems needing to be updated from Cobol (or was it Fortran?). Personally, I'm migrating to WPF, but there's still a time and place for WinForms I believe... C++ is still being used even though we all have C# now, kind of the same concept I think.
I've just installed VS2010 C# Express edition and there's still the option to create a WinForms project. I expect that the options still there in the full version too (I'm currently without an MSDN subscription so I can't get it at the moment).
So I think that there's still life in the technology.
By all means move to WPF or Silverlight, but do it because they offer you something you can't get from WinForms.
Windows Forms is no more dead than VBScript is dead. And I'm currently working with some fairly atrocious classic ASP VBSCript code, so I can assure you, it's not dead either (alas).
Win Forms will be around pretty much until Microsoft drops Win32 entirely, and even then it'll still be around in legacy systems for several more years.
Well, there are many differences between these two and probably it would be a good idea to establish some roadmap in order to migrate your application. There are many hundreds of websites for their comparison, but in order to answer your question, I suggest to start a new branch and start migrating while supporting your current models. With your current one you wouldn't have that much of problems either.
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.
We're starting a new project and are trying to decide to use either Windows Forms or WPF.
I've read some of the other Stack Overflow posts, and realize that WPF has some advantages in the data-binding and appearance areas, but also has a steep learning curve and fairly immature tools and controls.
We would like to better understand if Microsoft is planning on stopping new development of the Windows Forms technology and forcing all new development to eventually go to WPF, or if both technologies will be maintained and improved. (Or are they just going to wait and see how it goes before making up their mind?)
Currently, it seems like WPF is not necessarily the best way to go for line of business applications that don't need extra bells and whistles in the UI. However, it would be good to know if WPF is something we'll need to embrace sooner or later.
This is partially a reasoned argument, and partially a heart-felt rant....
WinForms is based on the user32/GDI technology that has existed since the dawn of modern Windows. It is not going to go anywhere, in all senses of the phrase: it won't get new features; it won't get support dropped.
Or maybe it yet will. The charting API in .NET 4.0 is new and written for GDI, not WPF.
In general, Microsoft has a history with new technologies that looks like the following:
Invent new API.
Innovate with that API for 2 or 3 product cycles.
Realize that continuing to innovate means making unreasonable concessions to backwards compatibility or having realizations that the technology didn't originally address.
Invent new API by wrapping or leaving the existing API around. The existing API doesn't disappear, but new stuff doesn't use it, either.
RDO -> DAO -> ADO -> ADO.NET -> LINQ to SQL -> Entity Framework, toss in some ODBC ... there is a treasure trove of "dead" and wrapped technologies that are still usable and still exist today. These are data access technologies, but the same idea applies; UI frameworks last a little longer because they are the most visible areas of applications.
If I put my Nostradomus hat on, I can safely say that when .NET, oh, 6.0 is out in 2015--which sounds far away but is as close as we are to 2003--WPF will be as "dead" as Windows Forms because some other nifty managed interface will have been created that smoothes over all of the as-yet-undiscovered mistakes and inconveniences of WPF. Who cares? Everything we are yabbering about today will be deprecated by then. (Something is going to have to give in .NET 5.0 anyway because the framework is getting comically large.)
If anything, the thing that Windows Forms has going for it is that it's based on the technology that has existed for well over a decade, and that inertia is not dying anytime soon: the browser you are typing in is using GDI, the taskbar is using GDI, your instant messaging application is using GDI, the new Ribbon control in Windows 7 is using GDI, the $60 printer sitting your desk is using a GDI printer driver, the Windows CE applications running on your phone run a port of Windows Forms and GDI, the new Event Viewer in Windows Vista is using Windows Forms, and there is a large third-party component community behind the Windows Forms platform--WPF is a very small, niche product that only exists in the managed world, which is itself smaller than its unmanaged counterpart.
To this end, I feel that all of these "WinForms vs. WPF" discussions are blowing things out of proportion; the technologies are not mutually exclusive or inferior/superior, as much as Microsoft marketing might have us believe, and Microsoft's developers are smart enough to realize this. They are simply different and one of them happens to be older. If we didn't consider this periodically, we would have all listened to Gartner in 2005 and stopped building Windows applications entirely and moved everything to AJAX on the Web ... with our SOA interfaces ... that expose an alternative REST interface ... that use a TDD DDD model on that backend ... abstracted from the database by an ORM.
Being so eager to abandon a technology for fear of its deprecation only assures our clients that we will maintain a constant level of inexperience and incompetence at programming software solutions.
WPF is part of the future, to be sure, but it's not THE future. Personally, I'm on the fence to see if WPF "makes it" in the UI technology sense that previous data access technologies haven't, although Visual Studio adopting it in 2010 is a pretty comforting sign that Microsoft is actually serious about it by dogfooding it in a flagship product.
To sum up: if you are building a LOB application, I wouldn't feel guilty about using WinForms. If you need an advanced layout scenario, WPF interop is always available to you, just as one enhances a regular Web site occasionally with a Flash object. But for anything else, you owe it to your client to come up with a Good Reason for transitioning the whole team and shell to WPF; Windows Forms has its problems, but half the battle with any platform is knowing what the problems and limitations are, and most of the world (including Microsoft) is still learning WPF.
WinForms won't be deprecated until Win32 is ... which could be quite sometime!
(Remembering that WinForms is basically an abstraction over Win32)
WPF on the other hand has few direct dependencies on Win32 so could potentially form the basis of a "fresh start" UI layer on a future version of windows. At which point I would imagine Win32 (and thus WinForms) will be completely ditched and only available through virtualization. As I said this could be along way off :)
Microsoft's support policy for the .NET Framework and all classes within it is 5+5: 5 years of mainstream support after a release, and then 5 years of extended support is available, or a fee.
With the .NET 4.0 update, including all the WinForms stuff, being released in 2009, you will get 5 years of mainstream support, to 2014 for any WinForms app built on .NET 4.0.
It's likely whatever comes after .NET 4.0 will include WinForms, too, in which case the clock resets.
This 5+5 policy applies to all business-related infrastructure software: Windows, Windows Server, SQL Server, Visual Studio, .NET, and so on.
The point is, you won't have to worry about lack of support for WinForms.
But, the prior posters are correct - the advancements are going into WPF.
I wouldn't worry too much about long term support. WPF may be getting all the love lately, but there's too much WinForms code out there to abandon support. After all, even MFC is still getting updates with each Visual Studio release.
I think Windows Forms will continue to be maintained by Microsoft, but improved upon only in small ways. All of the hot new innovations will go to WPF. Windows Forms is in a similar position as LINQ to SQL. LINQ to SQL is a tight, compact, fast ORM that is awesome, but Microsoft is throwing its weight behind the Entity Framework.
Windows Forms is great for what it is, and what it is used for, which is small, tightly-wrapped applications. It still has many years of life left in it.
If you want an application that will (more) easily port between a web interface, a WPF interface, or a Silverlight (or even a Flex) interface, Windows Forms is probably not for you. These other interfaces use standards-based markup, and an architecture that lends itself better to enterprise development.
I certainly wouldn't call WinForms dead... but I also wouldn't write a new project in it. I would write all new projects using WPF for a myriad of reasons. The biggest is that if you use WPF/XAML, your porting efforts to Silverlight will be much easier.
I went to a WPF preview camp in Redmond a couple of years ago, and I asked this same question to one of the folks working on Crossbow (WPF/Windows Forms interop). His response was that Windows Forms will be supported for the foreseeable future, but could make no guarantees.
Given that, I think you'll be OK basing your application on Windows Forms knowing that you'll have some level of support for the next version or two of .NET (for example, 3-5 years).
I would personally bet closer to 10 years considering Microsoft's continued support for Win32. You may not get boatloads of new features with each release, but you won't be dropped, either.
In any case, I would actually be more concerned with Microsoft's shift from rich-client technologies to web-based technologies, but not enough to ignore opportunities to create compelling applications in either case.