I see a lot of XBAP related questions posted here without answer.
I know that Silverlight and WPF (desktop) applications exists, but don't remember seen one XBAP product.
Can anyone tell if XBAP is dead (no applications being developed/supported)?
It would be nice if any XBAP developers could give their opinion.
Xbap is ideal for developing line of business apps for large companies. I used to work in that environment, and ensuring everyone had the correct version of an app was a nightmare.
Unfortunately xbap is late to the party. Most companies have solved this problem with existing technologies (SMS Installers, click once etc), also these companies aren't IT based and don't change/upgrade technologies unless they have to (the IT department I used to work in still use VS2003 and have no plans to upgrade).
So, given the glacial pace these departments adopt "new" technologies, and given their reluctance to change development practises, it could be another 5 or 10 years before they write and deploy an xbap application.
So rather than being dead, I think xbap has a limited audience of late adopters.
Related
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?
We were beginning to start on an enterprise application using silverlight.
However after reading this post we doubt whether it is the right choice going forward.
The post says that, according to
Microsoft's declaration in PDC 2010,
Microsoft has changed their strategy
regarding silverlight and they no
longer view it as their technology to
deliver cross platform applications.
Instead they are targeting silverlight
as their development platform for
Windows phone 7.
Is this correct? Should we still continue with silverlight or go back to ASP.NET WebForms\MVC?
The Scope of the application is basically intranet with Windows 2008 servers and Windows XP and Windows 7 clients. However a subset of functionality needs to be available to the external users over the internet. There we cannot have any restrictions on what OS users can use.
based on the info you gave, I can't conclude whether silverlight is the way to go. But what I do know is that a number of Microsofties wrote some blogposts about the things said about Silverlight on the pdc. For example John Papa, Bob Muglia and Scott Guthrie.
Update about the scope
I think you already gave the answer when you described the scope of the application. A part of the application will be available to external users and you cannot have any restriction about the OS they are running. With that requirement I think Silverlight is not the best way to go. Not because the rumours about its future but because of its platform indepency. What are the reasons not to go for a ASP.NET/web solution? Silverlight doesn't work on each OS whereas plain HTML will work everywhere. (ok you need a descent browser)
Although for a good advice I'd need more information about the application.
Basically the question you have to ask yourself is this: do you need your application to be used on every platform, i.e. Windows, Mac, Linux, misc. flavors of Unix, IPhone and other mobile platforms?
If that's the case, then a web based solution is the way to go.
If Windows, Mac and partially Linux is enough, then save yourself and your team a lot of pain and use Silverlight.
In my opinion support for mobile clients is the key factor in your decision.
For sure the right platform for Intranet, Enterprice applications Is Silverlight. It is
stable, performs extreamly well, the environment and the development time is huuge less than web application development, the end User Experience is much better and so on and so forth... Once you want to show part of the system out the the intranet - just create some specific target modules that will address the needed audince. You won't have the universal "Reachfull" solution, that will target everyhing, you'll always need mobile versions or other devices and so on. But once you've built your project the right way with Services (same services that the Silverlight app will consume), it'll be easy job to consume them with new UI.
Hope you will choose Silverlihgt.
Silverlight is a great technology, but the Microsoft does not develop it anymore. So as a technology is a great decision. But if you want to make a Silverlight app usable on a NOT supported platform (e.g. Android or iPhone) you have to use 3rd party services. For example http://sl2html.com
Is Silverlight RIA worth learning or should I stick to normal Silverlight?
Background:
I have done a couple small applications in WPF
I have 12 years expereince with business apps in the VB6/WinForms model
I expect to continue building business applications
My applications will be used internally
While ClickOnce does work for us, we want to get away from locally installed software.
To start with I'm wondering if there might be some confusion going on here.
There's actually no such thing as "Silverlight RIA", so lets clarify some concepts, RIA is commonly defined Rich Internet Applications, Silverlight is one of a number of technologies that can be used to build such applications.
However there's also the Microsoft technology WCF RIA Services, which is what I'm guessing you're referring to. WCF RIA Services were until recently known as .Net RIA Services.
WCF RIA Services (currently in Beta 2) has so far largely been targeted at Silverlight and is even hosted under the silverlight.net domain, which is probably where a lot of the confusion comes from.
However in theory it's not tied to Silverlight at all and is just a technology on top WCF to provide easy data access for RIA type of applications, for a more technical overview have a look at this blogpost by Nikhil Kothari it was written back in March 2009 about .Net RIA Services, so it might be a little out of date but it will give you a good idea on what it's about.
After defining these terms, it's a bit tricky to answer your question "Is Silverlight RIA worth learning or should I stick to normal Silverlight?"
Silverlight is definitely worth learning, by the looks of things Microsoft is going to stick with it. The latest recommendation I heard from someone close to Microsoft, was to go with Silverlight if you can for new LOB (Line Of Business) Apps, if there's something Silverlight can't do, then look to WPF.
Coming from a VB6/Winforms background there will be a bit of a learning curve, but if you've already done a couple WPF apps then you're on good way already.
Silverlight for LOB? Silverlight 3 started bringing in more features related to development of LOB, like for example support for WCF RIA Services. It looks like this is set to continue in Silverlight 4 (due out first half of 2010), with things like support for printing and COM for working with MS Office applications. There's also coming more and more pre-made controls from various 3rd party vendors for many of the standard LOB type of functionality.
So what about WCF RIA Services? It's definitely worth having a look at, it seems to be the preferred way of data access by Microsoft. It provides things like easy access to authentication and data validation. However saying that it's still in beta and there has been some voices raised against it, around the internet so it's probably worth doing some research, before going all in.
Finally, you say that you're applications will be accessed internally but that you don't want the hassle of locally installed software, Silverlight fits that perfectly, just roll out the small Silverlight plugin to your users machines and you're good to go. Any changes needed, just recompile your project and deploy your .xap file to the webserver and it will automatically get pushed out to the users next time they use the app.
Sorry for the somewhat long and rambling answer, I hope it's helped answer your questions :)
Cheers,
Ola
If you are doing business apps then RIA is definitely worth learning. I would recommend you take out an hour and watch this video: .NET RIA Services Intro. In fact you should take 2 hours and work along side this video building the example as you go.
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.