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.
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.
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.
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.
Given the list of new features announced in Silverlight 4, when is WPF still required?
WPF still has a lot fuller 3D rendering capabilities.
Also even though they announced enhancements to the commanding and binding capabilities, that's no guarantee that it will have the full ability that WPF currently has or will have in the next version
Edit: After playing around with Silverlight 4 beta, it looks like pretty much all of the new features (webcam, file access, full screen keyboard, COM interop, etc) only work when the application is elevated trust, and elevated trust can only be enable when running out of browser. Some of this may change by RTW, but for now, WPF still looks like the only way to do these things inside of a browser window
I've been using mostly XBAPs for browser deployments while waiting for a Silverlight version that includes WPF's full templating and data binding capabilities. Perhaps Silverlight 4 will do it.
Several things that Silverlight 4 definitely won't be able to do are:
Allow you to seamlessly integrate your WinForms and MFC user interface components with your application
Efficiently work with data file structures originally defined in C/C++ (with WPF you can simply copy the code across and easily replicate the original C++ code using unsafe and StructLayoutAttribute)
Include unmanaged C++ code in your application
I have not actually downloaded the Silverlight 4 beta yet, so this list is necessarily incomplete.
The next version of Visual Studio will not be written in Silverlight ;) I can't wait to write an Audio utility in WPF---and Silverlight must be sand-boxed away from the incredible Windows Audio subsystem. However, I can see the day when WPF will be called Silverlight (or perhaps the other way around).
When you don't want to depend on a browser to do your work, when you need full and fast access to the file system without prior confirmation, when doing interop with unsafe bits of code. These are the few I can think of, but they might be other reasons as well, depending on what features Silverlight 4 will really have and how well will they really work.
The applications we (in our company) write today use nothing that is not supported by Silverlight except for local TCP/IP connections without limitations.
This is the only reason we are using WPF.
If we could use Silverlight instead (desktop mode) we'd be able to give our customers
the choice of working on Mac (and linux) systems as well instead of being forced (by us?)
to use a recent version of Windows (you'd be surprised how many companies still use old (partially) unsupported versions).
Even in WPF we try to limit access to the system, we create our own sandbox and
try not to go outside of it. (Never require admin rights, never access stuff you don't have to)
So for what we do, Silverlight + real tcp/ip support would be more than enough...
but there is absolutely still room for WPF and I'm pretty sure it's here to stay.
It all depends on what you're building.
Silverlight will always favor small payloads over functionality. Strategically, Microsoft will attempt to out feature Adobe's offerings using Silverlight, while WPF will be competing against other heavy platforms. If you look at WPF 4 you'll notice a push towards heavier weight features. I try to keep in mind that WPF started out as Avalon which was intended to permanently displace Win32. I won't be surprised if one day Windows XX is "native" WPF and Win32 will be emulated.
If you want to do direct database access through ADO.NET that's not something you'll be able to do in Silverlight 4. Access to devices will still be limited although you will now have some printing support and webcam/microphone. I haven't heard anything about 64 bit support so if you want to offer a 64 bit version of your app you'll need WPF. I also think even if Silverlight 4 makes better use of the GPU, it still won't be to the level that WPF utilizes it.
There are also a ton of other assemblies in the .NET framework that Silverlight doesn't include so if you need any of those you'll need to go WPF.
Just like HTML5 will reduce the need for a plugin like Flash or Silverlight in some cases, Silverlight will reduce the need for WPF but there are still plenty of cases where you'll need it.
WPF is still required if you need to do extensive Rich Text (FlowDocument) editing. Silverlight 4 has the new RichTextBox, but it is limited to very basic content, and doesn't provide the full set of features that are available in FlowDocuments in WPF. A FlowDocument can effectively do what the WinForms RichTextBox can do; but if you only need the basics, a RichTextBox in Silveright may do what you need.
The bottom line is that silver light is limiting. So, if you are going to use a less capable technology you should have a compelling reason for doing so. The only one I can come up with, and it is a big one in some circumstances, is that Silverlight is more platform indifferent. I just can't imagine anyone wanting to bring the browser and all of it's headaches into a solution. There must be a good reason.
Silverlight Out of Browser technology and WPF ClickOnce on the surface have similarities. Easy and simple deployment, the ability to specify the level of trust access to the underlying host, etc.
What are the key issues I need to consider when choosing one over the other?
To put a finer point on it, I'll be deploying LOB apps on a corporate network running only windows computers.
The big one is cross platform compatibility. If you need you app to run on a mac as well as windows (not sure if Silverlight is supported in Linux yet) then use Silverligt. If you want to make an assumption that all your users will be in a windows machine then go WPF.
Obviously WPF has a much richer toolkit than silverlight so it may well be that silverlight just isn't an option. If I was just building for windows though I know my job would be easier in WPF.
Given that you are targetting a private infrastructure running Windows, two points worth thinking about
Wpf has a richer control tree, whereas Silverlight is a reduced set for compact size
Wpf requires .Net framework installed locally, whereas Silverlight has its own platform independent browser-based runtime
While your target platform will likely have the latest .Net framework installed, rendering this last point moot, keep in mind any updates to the framework [ie .Net4.0 and any future updates] may require a restart of the machine - which is a major pain point for businesses that demand constant-on stateful desktops [ie anything in finance, like banks and trading].
As with all problems, your requirements, not the technology, should inform your solution. :)
You mentioned trust access to the host which I think rules out Silverlight unless you want to run SL4 (beta).
We recently went through a lot of discussion about file system access. Silverlight 3 runs in a partial trust sandbox more or less. You can't maintain a pointer to files in the files system outside of your application's isolated storage. This was an issue for us as we wanted the user to be able to use the application to reference odds and ends on your file system. That said you can allow the users to load and save files from anywhere on the system but you just get/or push the file stream and (to the best of my knowledge) don't have access to the folder or file path information.
Silverlight 4 (in beta) has support for your application running in full trust mode. I haven't played with this yet however and can't speak to how well it works.
In talking with a lot of people who work with both Silverlight and WPF, even those who are excited about Silverlight and push for it strongly, I hear a lot of the say fairly emphatically that if you are going to be developing exclusively for a full-trust Windows environment, WPF is hands-down the obvious choice.
That's not to say that Silverlight is an inferior product or that there aren't times will Silverlight will be the clear winner. But when you say "I'll be deploying LOB apps on a corporate network running only windows computers," it sounds like WPF is the clear winnder.
You could decide to go down the Silverlight route in anticipation of all of the great new OOB feature os SL4. I've even heard rumors that SL and WPF will eventually merge, so it may not even really matter, right? Well, I think what you'll find if you go with Silverlight is that some of the advanced features that you thought were there weren't there in the way you expected. For example, SL4 will be able to run in "Elevated Trust" (not full trust) and you might find this limiting at a frustrating point in the project where a lot of your code base is already in Silverlight.
Certainly keep your eyes on Silverlight, but for your current business case, WPF will likely be the best fit.