We have a moderately complex silverlight based application written in Silverlight 2. Eventually we will move to Silverlight 4. In terms of porting effort, would it be better to to port our app from SL2 to SL3, and then to SL4. Or, should be port from SL2 to SL4 in one step.
Bear in mind that Silverlight 4 is currently in beta and does not have an end user runtime; so upgrading your app to Silverlight 4 right now is not really an option.
I'd go with the SL2->SL4 port directly. SL4 simply offers more, so it's a good opportunity to start looking at your app and making optimizations using the latest.
You'll find that 3 and 4 are more
similar and therefore take around the
same level of effort in terms of
learning curve.
Assuming porting takes you a while,
expect SL4 to be out sometime in Q2
CY10 with or around the same time as VS2010 is released. That should offer you time to
iron out the issues in beta and then
when RTW happens, you'll be nearly
ready with your port.
After RTW, expect a couple of months
for most people to upgrade their run
time. It should happen relatively
quickly given Windows Update, etc. In a corporate environment, it may happen much quicker if yours is an LOB and certain employee groups rely on your app - you have the upper hand in dealing with IT.
Related
Way back when I built an internal site for a customer using silverlight 2. They've been happy with it and I've barely had to touch it. Is the expectation that this site will always work? What I'm afraid of is suddenly getting a call years from now that the users installed silverlight X and now it's broken and I'm going to have to convert it immediately past Y versions of Silverlight to get the site back up, and I don't even do Silverlight anymore.
I already went through this once when it went from 2 beta to 2 release and and scrambling to fix all the breaking changes and get the site back up. It wasn't as big a deal then as we were in beta anyway.
I could upgrade now but it would be really tough to go back to the customer and ask for money to do an upgrade when they are happy now and will see no noticeable benefit from staying current. Additionally there are some third party controls that would have to be licensed again.
So I guess what I'm asking is there a known end of life? Or do we just play it by ear?
Based on the Silverlight Support Lifecycle Policy, it looks like official support for Silverlight 2 has already ended (as of October 12, 2010). However, some other documents (mostly listed at this SO question) give the impression that Silverlight apps are binary backwards-compatible through a sort of Silverlight "quirks mode," so as long as you're not changing your Silverlight app and the policy doesn't change, the app should work indefinitely.
The folks at MS have so far done a reasonably good job of maintaining backwards compatibility between Silverlight releases. But there have been some significant changes, and depending on what your app does, what features it uses, and what bugs in the runtime that it takes advantage of, it may or may not continue to run cleanly on future versions of the runtime. MS gives some good examples of the breaking changes between Silverlight 3 and Silverlight 4 here.
One example of many: Silverlight 4 introduces a new "Watermark" property on the Textbox class. It's possible that a Silverlight 2 or Silverlight 3 application subclassed the Textbox class, and added their own Watermark property. References in XAML to that Watermark property could thus throw an AmbiguousMatchException when executed on a Silverlight 3 or Silverlight 4 runtime.
Presumably there will be more changes of this sort as MS moves to SL5 and then SL6, and so forth: and their dev team will stop worrying quite so much about breaking SL2 applications. A change that introduces a really cool feature but breaks some reasonable portion of SL2 applications would presumably be unacceptable in SL5, but maybe not in SL6 or SL7.
My recommendation in your specific situation would be to let your customer know about the possibility of future issues now, so that they have a chance to make a decision about it when it's not an emergency.
Take it easy :) It would allways work.. Silverlight have 100% backward compatibility for EVERY major version!
After 9 month developing an enterprise application using MVC + JQuery our Management and stockholders interesting to convert and switch to silverlight! they think it's more powerful than Ajax, make development speed faster than our current solution, It's Windows and Web and less headache.
Unfortunately, our stockholders dos not know anything about web and stateless state of web application and they always compare with window applications.
But nobody in our team know anything about silverlight. I am not sure that is a good decision. I think we develop as fast as possible. we develop a great framework and code generator for fast develop.
Thanks and sorry for bad English.
Dumping what you have and going for a rebuild mid development is almost always a bad idea.
For a personal project, I did exactly this. It was originally built during the betas of asp.net MVC. I got the app to a stage where it was usable (actually I still use it daily), but it was nowhere near ready for the outside world. And this was the problem; it was going to take an enormous amount of work so that other people could use it...
When Silverlight 3 was announced, I literally grabbed the backend of the app - stuck RIA services in between and had a few screens up and running that day without any prior SL knowledge. I probably could have kept going down this path but something clicked when I started to realise the power of silverlight. The goal posts for my app moved, and I began a SL specific rewrite.
Since then, I've started re-writing about 5 times over. I guess I'm still just learning how to best build an app in SL, having spent the last 12 years or so of my career working on stateless web apps, there was a big mental shift involved.
I'm a much better web developer then I am a silverlight developer, but if it was for a real project (rather then a pet side project) - it would have been shipped and out the door by now.
I'm convinced that SL is the ideal platform for most web applications (as long as it being a plugin isn't going to be any issue).
With that said, shipping is still the most important thing. SL is great, but the learning curve is steep. If you guys are anywhere near completing the app, I'd insist you forge on with mvc and maybe get someone to build a SL branch.
Re-platform an application is always costly, although if you've got your MVC right it should theoretically be easier to replace the "VIEW" part of the application with something else.
As to whether Silverlight offers you more than HTML / JavaScript is down to what you're using it for. If what you are doing is media-related or highly graphical, Silverlight might be a good choice. If your application is like most business apps (i.e. some input fields backed by some read / write to database) Silverlight doesn't really offer any tangible time saving for this kind of operation.
If the web application is public and you care about search engine indexing, semantic HTML offers the best possible option.
We are a team of .net winform and asp.net developers building custom enterprise applications for organisations mainly in the public sector. Is it time to retrain/retool the team in WPF/Silverlight? How to make management, in first place and clients second buy the idea?
Clients shouldn't care, necessarily. You'll convince clients by showing them how you can be more productive and succeed in their goals, not by explaining tech. to them.
Management, on the other hand, is trickier. You need to convince them of the arguments for using WPF or Silverlight vs. Windows Forms. This can include:
Easier maintainability, especially when designed properly
More flexibility
More options to gain a competitive edge, via using new techniques such as better graphics/etc
Better support/lifecycle, since the newer technologies are actively developed and improved by Microsoft
Better deployment options (particularly with Silverlight), allowing for more flexible deployment strategies
Personally, I think that with VS 2010, WPF is finally mature enough to be the only option. Previously it was held back by performance issues, poor text rendering and a lack of out-of-the-box controls.
Here's what Rocky has to say, and I completely agree with him:
Silverlight and WPF both compete with
Windows Forms. Poor Windows Forms is
getting no love, no meaningful
enhancements or new features. It is
just there. At the same time,
Silverlight gets a new release in less
than 12 month cycles, and WPF gets all
sorts of amazingly cool new features
for Windows 7. You tell me whether
Windows Forms is legacy. But whatever
you decide, I’m surely spending zero
cycles of my time on it
http://www.lhotka.net/weblog/ItIsOnly8HowCanItBeLegacy.aspx
Before you go down that path, have a careful read of the Silverlight 4 news that is coming out of PDC. You will end up doing a mix of both Silverlight and WPF, it is unlikely that you will end up doing only one, and they are sufficiently alike that skills from one can be used in the other. However you don't want to be wasting money and time on Silverlight training that is out of date, as Silverlight 4 will be no more than 6 or 9 months away from being released (possibly sooner). Therefore you may want to do the WPF training first.
To add to what #Reed said:
faster development cycle (once the developers are familiar with the technology)
very easy to do automated testing, including automated UI testing
Is it possible for you to step towards WPF by embedding a WPF app into one of your existing WinForm applications?
It can be a lot harder to sell a complete retooling without an example of some of the benefits (in particular, maintainability and flexibility, especially in the UI). Try starting with a well used portion of your current application and giving a demo with it in WPF.
Now with Silverlight 3 (offline, out of browser stuff), what are the main differences between the two technologies?
There are some significant differences right now in the Beta, no idea if these will still be differences in the release version.
There is no way to hide the window chrome in Silverlight OOB.
No ability to create a notification tray icon.
Air apps can be multi-window, Silverlight OOB cannot.
Air apps have more access to the system, Silverlight apps are sandboxed.
There are differences in the install and update procedures, not sure of al of the details.
AIR gives you access to the file system and a SQLite db. SL3 only lets you write to the file system with user interaction (a Save As dialog) and doesn't have any support for a DB in Isolated storage or on disk.
SLOOB runs in a sandbox still, so you're limited to the same cross-domain issues as a Silverlight app running in the browser.
It's a three way war: Adobe AIR, MS Silverlight and Mozilla Prism.
Read this blog-post and this article. A quote from the second article:
Silverlight is the clear winner in terms of power, but as one of my colleagues pointed out the other day does it matter? His point was that Flash has an incredible penetration rate. According to Adobe it’s in the 99% range. When considering rolling out a new product that requires a plug-in why introduce another barrier to adoption?
and another one from the second:
We then asked of those who answered yes which formats they use. Unsurprisingly, given how long it has been available, Flash leads with 61% of respondents. More surprising was Silverlight’s very small market share of a little over 2%, essentially the same as that of the Real format. Quicktime did surprisingly well, at just under 20%.
As for VOIP support in SL read this.
Read up on Prism here.
In addition to what Dave said, Silverlight seems to be missing device support (microphone and web cam).
One thing I'd like to point out, that nobody else has mentioned is (and I'm not picking favorites when I say this, as we use Air/Flex for a project at my job):
Adobe doesn't have the talent needed to create quality run times and IDEs for developers. Their ideas are fine, it's the execution of those ideas that I doubt. I think we can all agree that Visual Studio is light years ahead of any IDE out there. Quality wise I'd even go as far as to say that VS2005 is better made than anything on the market (it's now 2011) 6yrs later.
If you feel Flex/Air meets your needs better, my all means, go with it. But if feel either platform will give you what you want, I'd say Silverlight wins every time. It's more mature, it's substantially more stable.
Our biggest headache for our commercial app is that Air does not managed garbage collection well, for the past year and a half, our app has suffered from slowdown, the only resolution is to do a nightly reboot on a kiosk because we nest objects inside objects, once you hit the 3rd nesting, it seems Air cannot flush those objects correctly, Adobe is will aware of it, and considering how much time has passed and all the newer versions, Adobe has no resolution. That is the sign of poor run times and Adobe developers who just aren't very good. Despite the fact people love to bash MS, these days their platforms are pretty reliable is reliable overall, especially their .NET runtimes. Adobe feels like Microsoft circa 1997, they're years away from offering reliable solutions.
PS: I'm sure a couple koolaid drinking Adobe devs will be down voting this answer.
Assuming only minor changes are necessary to run a Silverlight app on the desktop, the differences are in implementation details. Silverlight is a .NET-space framework based on WPF. Flash/Flex/AIR are proprietary Adobe products based on ActionScript.
In terms of capability, they seem to be roughly equal with complementary strenghts and weaknesses. Example: SL3 will have GPU and pixel shader support. The latest Flash as Inverse Kinematics. Different strokes, etc.
From the users standpoint I like the Silverlight installation process a lot more... Specially on the Mac - Air app installation is unnatural (to many clicks and processbars) but oneclick Silverlight install is nice :)
My company is just starting to look at using WPF for migrating all of our 10 year old business applications. These applications will most of the time be running on computers that have limited/old hardware. We are now a little worried that the hardware might be too limited for using WPF.
We have installed Family.Show (http://www.vertigo.com/familyshow.aspx) on an basic older computer and that seems to run ok. But we would like know what your experiences with WPF on older hardware is? Anyone out there willing to share some experiences with us?
I would add several things:
The first is, as Stu said, it really depends on what you are doing. In particular, we have found a noticeable difference between WPF 2D and WPF 3D. If you are doing any WPF 3D stuff at all, your performance is highly dependent on the quality of the video card (see the Graphic Rendering Tiers link already mentioned). In particular, we released a WPF 3D feature in April of this year, and it really only worked smoothly on Tier 2 hardware.
Second, I would point you to Jossef Goldberg's blog. It has a wealth of information on WPF performance related items.
Third, I would grab and utilize the WPFPerf tools. They were recently updated actually. Jossef's blog post will point you in the right direction there as well.
Fourth, take advantage of virtualization wherever you can.
Finally, I would recommend monitoring performance all the way through the development life cycle. I think the story goes that originally the Blend team did not evaluate performance (for their first release) till closer to the end, and it made solving the problem much more difficult.
Update: There is another StackOverflow post on this subject. Just wanted to point others to it.
WPF apps will generally run no slower than their equivalents using other technologies. In other words, performance depends on what you're doing. If you have a basic app with some simple data entry controls and a grid or two then it'll be a lot less demanding than an app that has animated custom controls with overlaid video, etc.
You should also bear in mind that you must have at least XP SP2 to install WPF, which sets a reasonable hardware baseline anyway.
In summary you should have no problems running a WPF app on older hardware as long as you are sensible with the frills. Given WPF's templated controls it's also fairly trivial to test for a basic level of client performance at runtime (see Graphics Rendering Tiers) and only enable more advanced features on suitable hardware.