We are contemplating building an upcoming project in Silverlight. We would be developing this in SL 4, not 3, but another developer in our organization had the experience of upgrading from v2 to v3 in the middle of a project, and losing features and functionality that MS didn't include in v3. This was some headache for him, working around this, and my team are wondering if others have had similar headaches (i.e. lack of backwards compatibility) in upgrades from v3 to v4 -- as a way to possibly predict if we're going to run into serious problems when SL goes from v4 to v5.
The application we will be building doesn't "need" advanced SL features, and could easily be built as a plain vanilla ASP.NET web application. We would like to learn to use SL, however, and this is an opportunity to do so -- but not at the expense of SL munging our future maintenance efforts by making it problematic to upgrade framework versions.
Any experiences out there?
The automatic project conversion wizard in Visual Studio does a great job, and Silverlight 4 is mainly additions of new features (not removing of existing ones).
We have had one Silverlight project (out of a dozen) stop rendering certain controls properly with Silverlight 4, but that was down to a slight runtime engine change to Silverlight itself and likely down to us misusing the controls.
Otherwise it has been plain sailing. SL 4 is definitely the way to go. The improvements to Expression Blend 4 alone were worth the upgrade (Expression 3 tended to crash editing style templates of Telerik Rad controls).
I warn you now, once the Silverlight bug bite you, you will have trouble going back to ASP.Net :)
Hope this helps.
2 to 3 was a bigger leap.
3 to 4 should be painless.
Read this article on Silverlight Compatibility:
http://blogs.msdn.com/b/nickkramer/archive/2010/09/11/how-does-silverlight-compatibility-work.aspx
Your users probably wont have it and would probably need to install SL4 before they can use it
Related
At my job we are developing a GIS application which will be developed using Silverlight + .NET
But, I heard that Silverlight will not be supported by Microsoft as also they are stopping Silverlight, is it true ?
Is it suggestable to use Silverlight if so with which version of silverlight we can use. ?
Thanks.,
Use Silverlight 5. Current version have 10 year support, and it better than Flash, java or damn it html.
In the future you can migrate to another .NET-based framework by easily porting code.
About silver light support, you can find these answers from Microsoft Silverlight Support Lifecycle Policy.
Keeping in mind that MS would support these browsers till 2021, I would recommend using Silverlight5 if you really have to use Silverlight.
However for new developments I would recommend you to evaluate Html5 as well.
YES! Silverlight is still the best technology to use for web based Line of Business applications. Silverlight will be supported for another 10 years and it will be available within Windows 8 desktop. Silverlight +[Arc]GIS are a great combination. It is so easy to create full functioning application and with little effort. Silverlight is not dead. It is still a great technology to use that is available on (almost) every platform.
Ultimately it comes down to:
1) What do you know: Are you an HTML/JavaScript ninja? Then use that, do you know Flex better then your own children? Or are you a skilled .Net assassin?
2) How much time do you have? Do you want to learn something new and have gobs of time? Then go for that new shiny object (HTML5) and get yourself some street cred.
This probably belongs on programmers.stackexchange.com. However:
Silverlight will continue to be supported for some time, but all signs point to it no longer being actively developed.
If you want a technology that's actively developed, I'd recommend HTML 5 for web based applications and WinRT for Windows 8+ native applications.
Ultimately, though, you should go with what works best for your situation. After all, WinForms is still used on many successful greenfield projects.
Silverlight is based on the NPAPI architecture that is no longer supported on Google Chrome (from browser version 42 upward) though you can still run it on IE and Firefox. HTML5 is supported on all browsers.
From a career standpoint, using Silverlight (which uses XAML) gets you an easier entry into developing apps for Metro/Windows Store/Universal Windows Apps (these can be developed using HTML5/JS too but you'll find a larger developer base using C#/XAML).
Finally if you're already a WPF developer, it's fastest if you develop for Silverlight. See Silverlight vs Flash vs HTML5.
I have a Silverlight application developed with version 4.0. I tried running it with Silverlight 5 client and everything seems to be fine up to now.
But I am wondering; if my users installs Silverlight 5 for client, is it sure my application will still work well? Do I have to run all my Test Cases again?
If anyone notices something that has been broke between versions, please list it here! :)
Thanks
There's little evidence around the internet at the moment, other than that published by Microsoft, which can be found here and here, which states, to summarise:
Several changes have been made to the Silverlight runtime and the
Silverlight Tools between Silverlight 4 and Silverlight 5. For these
changes, the following principles apply:
Most Silverlight 4 applications will work with Silverlight 5 without
any changes.
When breaking changes are required, Silverlight will try to maintain
support for the old behavior, as well as the new behavior, by using a
quirks mode.
Nevertheless, some changes made to Silverlight components can
potentially cause your older Silverlight-based applications to fail
(compile time, XAML load time, or possibly design time) or to behave
differently.
And,
There are no known breaking changes between Silverlight 4 and
Silverlight 5 in the Silverlight core runtime. Applications that were originally compiled using Silverlight 4 tools, and that continue to target the Silverlight 4 runtime, should work without issues on a client that has the Silverlight 5 runtime.
If your project references any Silverlight SDK client assemblies [...] make sure that your project
specifically references the Silverlight 5 version of the SDK client
assemblies [...]. A project that targets Silverlight 5 cannot use the Silverlight
4 SDK assemblies.
There's more information in the links I provide, for instance, related to quirks mode, third party references, and behavioural changes.
I have a project with a Silverlight 4 tool used to display a barchart etc. The Project upgrade to VS2013 automatically upgraded to Silverlight 5 and there were no warnings. I worked on other areas of the project and only by chance did I actually run it in debug mode to find that the display was broken somewhere inside the tool. I managed to scamper back to VS2012 and scavenge the changes I had made in the VS2013 version of the project.
I am at the initial stage of designing a client application. However, being new to WPF and having already gained some experience in Win forms development, time pressures on the project means that there is a risk to going down the WPF route. If time were no pressure, then I would say forget forms and design with WPF. However, I am not lucky enough to have this luxury. Having spent a little time investigating the Composite Application Block for Forms, I have decided that I will definitely develop the application within this framework. However, there are 2 versions of the CAB, 1 for WinForms that targets the .Net 2.0 runtime which has now been retired, and then the WPF version which targets .Net 3.5. Not being a fan of 'retired' code libraries, I would prefer to use the WPF version of CAB. This may be a silly question, but is it possible to use the WPF version of CAB for Win forms application developement? I do envisage at some point in the future moving to towards WPF. If I could use the WPF version of CAB I am hoping that this would make it easier to migrate the forms application to WPF.
It looks like somebody had the same idea that you did.
I found it by reading this thread on the CompositeWPF codeplex forum, discussing this very issue.
You should be able to do this without too many issues. We are currently using CAB to enable us to display SQL Reporting Services reports in WPF (along with a couple other items). It's a pretty simple implementation, but our architecture is WPF-based, not WinForms. As far as we've been able to tell, there wouldn't be much of a problem were it the other way around, and displaying both types of forms is done the same way.
Why do Silverlight 4 Assemblys still have the version 2.0.5.0 in Visual Studios Object Browser?
Well I can't claim to know the exact reason for this, you would need someone from the SL team to state the reason categorically and I haven't seen any blogs from them doing that.
However I strongly suspect this is related to the fact that there is still only one Silverlight plugin, that is to say when a user installs the Silverlight 4 plugin it replaces the existing one. The Silverlight 4 plugin will run not only Silverlight 4 apps but also Silverlight 3 and 2 apps. As a consequence Silverlight 2 apps will be looking for 2.0.5.0 libraries and that certain issues are avoided if the later versions simply use the same version number.
Of course I could be way off and hope that if I am an MS geezer come and shoot this down, in the process of which giving us the real answer.
Because it needs to reference the System.Core 2.0.5.0
I'm considering switching from MFC to WPF.
My first concern is that there are too many users who don't have .NET with WPF installed yet. Can anybody point to a source containing the WPF penetration numbers?
My second concern is speed.
Any other considerations?
I've been banging away at WPF for a while now. It is brilliant, but it still has (occasional) holes you've to plug yourself. However all indications are .NET 4.0 will be a significant step forward.
I would say start now. The WPF learning curve is REALLY steep, and it'll be a while before you'll be releasing software to users, believe me. Also do yourself a favour and get the WPF Unleashed book. It's superior.
Speed isn't a consideration. The power WPF gives is well worth any drawbacks with speed, which - coming from Windows Forms - I haven't noticed to be honest.
What kind of application are you developing? If it's a wide-distribution desktop app that you want your grandmother to install, your concern about .NET 3.0/3.5 adoption is valid. So far from what I've seen, performance is less of a concern.
WPF penetration
First of all, Windows Vista and Windows 7 both have WPF preinstalled, which accounts for 35% of the market automatically. Windows XP has had it as it had .NET Framework 3.0 as an option in Windows Update for over three years, and many applications ship with it, so it is likely to also be installed on a high percentage of Windows XP machines. StatOwl indicates that about 80% of NET Framework installations are version 3 or above.
If you're shipping on CD it is no big deal to include the latest .NET Framework on the CD and have it install automatically. If users are downloading your application, it can contact Microsoft's web server to download and install the latest .NET Framework. Online ClickOnce deployment also has this capability if you want people to be able to start their application directly from the web browser without installing it.
So the bottom line is, you probably don't need to worry about whether people will have WPF installed on their machines or not unless your target market consists primarily of dial up customers on Windows XP who don't run much third-party software (i.e., they just run Windows and your application).
Speed
Not an issue. I have a 200 MHz Pentium Pro with 384 MB RAM from 1998 that I test my software on, and my WPF applications have comparable performance with equivalent MFC applications. If your WPF application uses lots of fancy graphics and animation it will run slowly on ancient CPUs and graphics cards, but so would an ordinary MFC application with the same features.
Don't even bother trying to use WPF if you are sticking with Visual Studio 2008 for the next year or two. The experience will be way too painful. I'm talking about "my IDE crashed again" type of pain.
If you are going to use VS 2010 in the near future, then WPF is a blast. Download the beta, a couple of themes off CodePlex, are start playing. Once you get past the (freaking huge) learning curve I think you will find it to be quite enjoyable.
IMHO, you should wait for Visual Studio 2010 and WPF 4.0 to make the actual migration. They will close some very annoying gaps in the product.
Meanwhile, you can try it out. In terms of coding/readability -- it's going to be WAAAY better than with MFC =)
As for the performance and platform -- it shouldn't be a problem unless you have any very special circumstances (like if you can't require users to install .NET).
Also see this related question on switching to WPF from Windows Forms.
If you are thinking about a larger, modular, appliation I recommend checking out Prism. It's a bit of a beast itself, but you should be able to tackle it after coming to grips with C#, Dependency Properties and XAML. Plus, learning Prism gave me a much better understanding of WPF/Silverlight, at least from the development/binding side.
Mike Taulty posted an excellent 10 part video series on Prism. It's a great way to get your head around the platform.
I'd also recommend the pages linked to from the Getting Started page on codeplex. After all that, you're probably ready to tackle the Reference Implementation which comes with the download.
A previous answer of mine might also help clear up any remaining confusion around Controllers/Presenters in the framework that you might have (I did).