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 .
Related
When I create new Windows Phone project I have an option to create a "Windows Phone" or "Windows Phone Silverlight" app. I know that they have different runtimes and different APIs.
I was under the impression that Microsoft wants to unify Windows and Windows Phone platforms so why is there even a Silverlight version? What benefits does it bring?
Also, if I want to create an app just for Windows Phone and never have plans to bring it to Windows, what should I choose, Silverlight or Windows Phone?
I'd suggest you go with "Windows Phone" (non-Silverlight). It's the new API, which works for both Windows and Windows Phone. At some point you may want to port the app or create a new one for Windows and you'll already know the API (and porting will be way easier). Also, the new API will most likely get more updates and features added, and at some point you may even be forced to update to it (either because the old one is no longer supported, or because it does not have some features that you need).
As it was said in the other answers - the Silverlight option is there only for backward compatibility and is likely to be phased out in time. That is - it's good if you already know the API and have many libraries (yours or others) for WP Silverlight, but if you're just starting - you'd better go for the new technology.
Edit
There is one other thing to consider before choosing between the two types of apps. Some features are only available in a Silverlight app, and others (smaller amount) - only in a Xaml app. Here's an article with some info on the differences: Migrating your Windows Phone 8 app to a Windows Runtime XAML app
Windows RT Xaml is quite new and People have to generate some knowledge first.
Silverlight for phone has been around for years and there's a load of tools available: Phone Toolkit, diverse Controls, etc.
Just killing it off would have hurt many developers who built up intellectual property over a long time forcing them to start over.
When starting a project with Silverlight you will have more things around that help you get stuff done.
When starting with WinRT Xaml, you will have better performance, but will have to figure a lot out by yourself.
So the Silverlight option is there to not throw of Silverlight developers.
I recently started a new project on WinRT Xaml and my experience was that I had to recreate a lot of common tools like Caches, etc. But also a lot of things that were in Toolkits previously are now part of the platform itself. Also, when moving over to Windows 8, you get to share a lot of code which is nice.
Unifying the environment(s) would be ideal. In my opinion, it hasn't been very successful. At one point in time, you could only develop under Silverlight, so what you are seeing is just a newer version of the same thing to keep backwards compatibility as well as to keep Silverlight's developers happy. In the future, it will probably be phased out. Plus if you want to support older Phones, Silverlight is basically your only choice (you'll be surprise, how many WP users haven't updated their 8.0 to 8.1)
There really isn't any other real benefit of Silverlight other than maybe the Windows Phone Toolkit which has been tremendously useful (you can see how many SO's answers rely on this simple addon). Once the universal runtime gets fleshed out to the point where the documentation reflects what's actually available -- then I think it would be the default project for developing in Windows going forward.
If you're just starting, I would use Silverlight the knowledge based is much greater. After you get use to the WP environment then switch to runtime.
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.
I am Really confused by reading some articles about Silverlight. Whether I should concentrate on WPF or Silverlight or Both?.
It's like asking Web or Desktop : Which one has upper hand?
Silverlight (Web) and WPF (Desktop) Both are similar. But both have their separate workplaces.
You cannot have a Windows Calculator, Task Manager or MS Word (please don't mention google docs) applications on web like they are on desktop. And same thing applies for web applications.
So, it depends on what platform you want to work on.
I dont think its difference between Web and Desktop. Silverlight is still pretty limited by platform it can run on and still requires some local runing process, even in the sandbox.
I think difference here is features vs availability. WPF can give you features of whole .NET framework, total acess to users's computer and some features that are not available in SL. SL on the other hand allows you to run your app on some different systems (Windows, Mac and there is limited support for Linux-based systems), distribution is much easier thanks to web deployment and whole application can be part of your web ecosystem.
Iam personaly for WPF, but thanks to this whole web and cloud-hype in the last years, SL is getting much more attention from side of MS and developers in general.
Reading these questions and their answers may give you some insight into this:
Definitive source(s) for the difference between Silverlight and WPF
https://stackoverflow.com/questions/1254937/wpf-vs-silverlight
What is the difference between WPF and Silverlight?
I totally agree with decyclone, it depends on which platform you want to work. If you have prior experience Asp.net/We applications Silverlight is the way whereas if you have worked in WinForms/Windows applications then WPF is the way to go.
But yes most of the concepts in both SL and WPF are similar; so once you have good understanding of those concepts, you work in either without much problem.
If we ignore the platform then WPF is having the upper hand as WPF is kind of superset of SL.
Have a look at this SO question too -
Learn Silverlight or WPF first?
It seems like these two technologies, already similar, are on a path to merge into a single technology. There are a lot more WPF-like controls in the Silverlight toolbox, and WPF now has Silverlight's VisaulStateManager. At this point, it's probably fair to say that Silverlight has even surpassed WPF in terms of the number of themes available.
How long until these two technologies become one? How long until the difference between a rich client app and a rich browser app is a simple compile-time setting?
EDIT
Let me clarify my question. I realize that any browser application needs to run in a "sandbox" for security reasons, and I also understand the desire to keep the browser plugin as small as possible, but there are several minor differences between the two technologies that could probably be massaged out without compromising either of these goals. For example, there could be a lot more overlap between UI controls and themes. Today, you can't just use a Silverlight theme in a WPF app, but how much of a leap would it be for Microsoft to make this possible?
I don't think they'll ever merge into one product. Microsoft has intentionally left a lot out of Silverlight to keep its footprint small. And then there's a plethora of security issues Silverlight must abide by when running in a browser. And of course they've designed it so it'll run on a PC or a Mac (unfortunately the same can't be said for the .NET Framework).
I am happy to see resources shared between WPF and Silverlight though. They were supposed to be similar from the beginning. As a result, it's relatively easy to port a Silverlight project into WPF. On the flip side, it's not quite as easy going from WPF to Silverlight simply because WPF has always had more features, but that's just the nature of the beast.
UPDATE:
So your revised question is interesting. It would be cool if Microsoft could make it possible for you to basically flip a switch to change the behavior of your app between Silverlight-like functionality and WPF. They would be facing a great deal of challenges though, not only with security but with the fundamental behaviors of some of the lightweight Silverlight controls vs the feature-rich WPF controls. These differences could potentially complicate things for the developer even further.
For example, in WPF there's a built-in multiple undo & redo system in the textboxes. In Silverlight there is no such thing so I actually had to write my own. In order for the developer to account for things like that they'd have to do build a lot of feature-checks into the application.
With all that said, I suppose a compile-time switch as you described might be feasible. But I still think it's unlikely Microsoft will create this kind of capability any time soon.
XAML and databinding may become closer between the two
but the rest of the framework will probably never be the same.
For once, you can not automate an Office application using Silverlight.
And that may never happen, unless MS decides to open a bridge of some sort
between the plug-in and the .NET Framework.
Security, consistence, and great UI are main driving forces in Silverlight.
If you can do something in Windows that you cannot do in Mac than
consistence is lost.
Silverlight installations has its own libraries built for specific operating systems. We as developers use what microsoft gives us that can run on those systems. WPF is full trust to the windows operating system which uses specific windows api calls.. So i'd say never will they merge.
Yes we will see that WPF and Silverlight becomes more and more alike, if the acutely will be merge? maybe It's not impossible but what we will see is just that what you stated that they will be more alike. So in the future you will not implement WPF OR Silverlight you will just implement XMAL.
Silverlight 3.0 beta has just been announced at Microsofts Mix Conference in Las Vegas.
Two features of the new beta are 3D-graphics and the ability to run applications outside of the browser, which to me seemed to be two of the major features that WPF (Windows Presentation Foundation) previously offered over silverlight.
I am currently evaluating WPF and Silverlight for possible use in our companies future development activity, and this announcement has left me confused as to the intended direction of these two UI technologies and why I would choose one over the other.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision? Given the announced changes to silverlight, Would your decision have changed had you made it now, and if not, why?
Any advice would be appreciated.
The biggest difference I find is the asynchronous model you have to adopt
in your Silverlight application.
It does seems like an advantage (and it can be), but it does make
life very difficult sometimes.
There are also some limitations that can be a real challenge like the absence
of print support.
I would recommend Silverlight over WPF when:
- There is no need for best possible performance (graphics included)
- Can get around the absence of print support (it will come, we just don't know when)
- Camera/Microphone support is not needed
- Can tolerate the assync app/development model
- Can tolerate limitations on WCF (no support for WS-Security at this point)
- There is no need to store huge amount of data on the client.
- There is no need to direct integration with client side applications like Office.
- Has a server to host your application
I would say the main difference is that WPF requires the client to have the .Net 3.0+ framework. Silverlight only requires the runtime. Now that being said, WPF is geared more for controlled environments such as an intranet. Silverlight is meant for the public web. Another difference is that Silverlight is cross platform (Windows, Mac, Linux in the future & Cross browser). WPF is meant for Windows only.
The .Net framework can be a huge download for some users. Silverlight is only 4-5MBs. This is a big difference to run your app on the web, but not a big issue if its an internal application at your company.
Silverlight is Sandboxed which is meant for web use. So if your app requires more permissions you will need WPF.
There are also some differences between Silverlight code and WPF. But from what I've heard, the ultimate goal is to get a Silverlight to run inside of WPF with minimal code changes. But they aren't there just yet.
I have just worked on a WPF project that in hindsight we feel we might have chosen SilverLight for. It is probably more important to know the differences and select the one that is most appropriate for what you're doing.
Here's my starter for ten on some of the important differences - there were originally some differences in the available controls, but that has largely been smoothed out now.
Silverlight
Runs entirely on the client with AJAX
calls to the server for data
Can run on any server, including Windows and Linux / Apache
Uses COMPACT .NET framework
WPF
Runs on the client... usually calls services for data
Runs on Windows XP / Vista with .NET 3.5
Utilises the entire .NET framework
Silverlight is basically a stripped down version of WPF in order to make the runtime libary download as small as possible.
As a result, WPF simply has a lot more functionality available in it and tasks that are simple in WPF often become not so simple in Silverlight.
If running as a web app is not a requirement then the decision is a no-brainer - WPF all the way.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision: Well since WPF was desktop only (or browser based using XBAPS - but that was more a deployment system than a real system) that was a good reason to it.
"Would your decision have changed had you made it now, and if not, why?" - No Silverlight, even on the desktop in v3, is still highly sandboxed and so certain functions are going to be hard/impossible to do due to the sandbox. Also the ability to use DirectX parts in WPF will still give another optimisation area which Silverlight and it's 3d won't be able to use.
It's worth noting that Silverlight's 3D is not the full 3D support of WPF, but only projection of 2D into 3D - i.e. take the 2D plane and allow rotation in X, Y & Z directions. WPF has full 3D modelling with materials, view ports, lighting and camera positional support etc.
I'm well along in the development of our first WPF app for release. Silverlight 3 looks great, but for this application I would still have chosen WPF. The application centers around presenting and manipulating very large sets of images hosted on a central server on our clients' networks. Additionally, the software update/change rate will be minimal. Mass import of new images from a local drive, no Internet connectivity requirements, performance concerns, etc. make this a project well suited for WPF.
One of our upcoming projects, however, will require many remote users to access a single data store on our network. The data they work with requires significant validation and error handling, so running that code locally is ideal. They will need the ability to work both on and offline and remain in synch (probably with SQL Data Services). SLOOB (Silverlight Out Of the Browser) will most likely be our choice for that one so they can have all the Silverlight advantages but use it like a regularly installed application, even without an Internet connection.
Both formats have their place: the trick will be to avoid using Silverlight for everything - we have more tools than just 1 hammer. :-)
Another difference is that with SL you only have one 'window', you can't have dialogs (they can be simulated but their size is limited to the main window) and you can't add multi monitor support.
If you have to interact with existing business applications (e.g. open a document in the archive viewer) you need to use WPF.
I recently have built several internal tool using wpf, and I chose it simply because It was easier for me coming from win32 work. I don't really think that the differences are major, and really... everything i have seen/heard indicates that porting between wpf and silverlight is quite easy.
Storage: You only have 25MB of isolated storage out-of-browser. If I remember correctly from some mix09 video, this limit is lower if your app is in-browser.
http://bliny.net/blog/post/Out-of-Browser-with-Silverlight-3.aspx
No FlowDocument: So there are limitations there too.