I want to create a desktop like app, but I'm kind of confused as to which technology to use. It seems Silverlight functions like a desktop app. Which technology is better suited and has is more future proof?
WPF is the framework to go with if you are building a desktop application. Silverlight is more of a web application framework. It all depends on where and how the application is being used.
This Question compares the two.
Desktop apps should be built with WPF. Silverlight has a lot of security restrictions which doesn't make life easier.
Which technology is better suited and has is more future proof?
This depends a LOT on the purpose and goals of your desktop application.
If your application needs to interop with the system in a "non-standard" way, or provide other types of 3rd party interop, WPF will be a superior solution (at least until SL 5's P/Invoke support).
However, if your application is a LOB application, Silverlight (running OOB) has many advantages - especially if you want to take advantage of things like RIA Services (which hasn't been ported to WPF).
WPF has at its disposal the entire .NET framework while Silverlight in an attempt to be lightweight has a part of the framework (plus some really cool things). So, it really depends on the scope and deployment methods. To me it makes more sense to make a Silverlight application a desktop application than to make a WPF application deploy through the web. But again, let the scope dictate. If you're wondering which to learn, the answer is simple - either one as they are similar enough that when you're good at one you'll be okay in the other.
If you're used to WPF, you'll find that Silverlight lacks a bunch of major and minor features like data triggers, FindAncestor, synchronous WebClient requests, and so on. Probably not deal breakers but definitely annoyances.
Related
Should I start my new browser based C# program in Silverlight or WPF? It will be browser based but it will be used within our organization only, my program will need to talk to Windows file shares if this makes any difference.
I've only done Windows Form Apps and basic ASP.NET apps so far. I don't want to rewrite this in the near future if Silverlight gets dropped.
What would you recommend for ease of learning and future proofing for a Windows form programmer.
Thanks
Steve
No such thing as future proofing. Certainly not in technology.
I don't think either will get 'dropped' in the near future. Both WPF and Silverlight have a steep learning curve (the XAML, the MVVM design pattern, and moving from Procedural to Declarative patterns). If you learn one, you're basically learning the other too.
That said, it depends on your need. My thoughts are usually:
If it's a website, use ASP .NET/HTML
If it's a simple web application, use ASP .NET/HTML
If it's a LOB (line of business) application that doesn't need elevated system privileges, use Silverlight
If it's a LOB application that requires full system access and elevated permissions, use WPF
There are a lot of Silverlight headaches (functional limitations) you can run into that WPF doesn't have...so unless you need cross platform and lightweight is very important to you, I usually lean toward WPF. That said, each version of Silverlight comes closer to WPF functionally.
I should add the caveat - I hate web based LOB applications. I've never seen one that isn't hacky or doesn't suffer from usability problems stemming from the technology. No, HTML5 doesn't solve these technological limitations and problems. If I'm working on a LOB application, I'd rather devote my time to making it the most business friendly application possible with a competitive feature set, than focus on making it display right in different browsers, troublshooting cross domain security problems, and maintaining a javascript code base.
If you write the application in Silverlight, then it will have to be run inside a browser, unless you make it an Out-of-Browser application. If you write it in WPF, it can be run like a desktop application, but you will have to deploy it on everyone's computer who needs to run it.
If you are not sure of Silverlight, try using Flash instead.
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?
I am a 6-years .Net Developer, and want to know which is better to start learning first, Silverlight or WPF.
I know this question seems a little-bit argumentative but since Silverlight is a mini-version of WPF. I think this takes away the argumentation.
So in the light of that, if I considered start learning:
Silverlight First: Because it would be easier to learn than its big brother.
WPF First: Because it would be easier to know the basic concepts and event-model of WPF before moving to SL.
Learn Silverlight first so you won't be annoyed that you cannot use useful things like RelativeSource and x:Static in Silverlight :P
Silverlight will be fused with WPF in a couple of years.
Study Silverlight first, i recommend the book Pro Silverlight 4 in C# from Apress, the unique that have color pages.
If in future you'll need some extra Windows functions, go to the much complete WPF.
With Silverlight you can also develop Windows phone 7 applications, and Xbox 360 (rumored). In windows 8 will be a Silverlight Marketplace (valid rumor), and you can create very rich applications / part of website / full websites instead of using the slow, crappy and "browser inconstistent" JQuery+Canvas that have no tools at all for design (and when it will have, Silvelight 5 will have real 3D and better tools).
Also the fact to use the same language for client and server is priceless.
Well Silverlight and WPF is "pretty much" the same actually. As you said Silverlight has only a subset of the .NET framework but it doesn't make it "simpler" than WPF.
The biggest leap you will have to make in order to learn those languages is learning XAML, which is the same in both.
It all depends on what you need to do. Do you want to publish your project to the web, then go with silverlight (you can do a XBAP project in WPF to publish it to the web, but clients will need Full .NET Framework). If you need advanced .NET functionnality, then use WPF.
Silverlight first. It is easier to add the extra WPF features than to unlearn things when doing WPF first.
Having said that, it doesn't matter that much. There is more on Silverlight on the web these days.
What kind of applications do you want to write ? Desktop applications that need local access or web based applications ?
If it is a matter of learning, I would learn both in parallel. Keeping your application consistent to run in both run times will force you to learn all of the little differences. Once you get past the main SilverLight features, shift into the features only provided by WPF (though I would start with the libraries likely to be included with SL5, first, such as 3D).
Go with Silverlight first, although it is not as feature rich as WPF it is simpler. Also Microsoft are actively evolving the platform. Silverlight is not a true subset of WPF as it had things like a DataGrid control first.
Good learning resource: http://www.silverlight.net/learn/ together with the Pro Silverlight book which you already have.
The further advantage of starting with Silverlight is that it will be easier to develop for the new Windows phone (broadly it uses an older version of Silverlight).
Learn both at the same time! Not one or the other, but both. There's plenty of overlap between the two technologies which should make it more practical to focus on both at once.
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.
I deal mostly with XBAP,
Q1.XBAP normally uses the PresentationHost.exe to get the work done,What does SilverLight use?
Q2.Are there considerable differences in moving from XBAP to SilverLight ? (Experience Based or fact based answers?)
Can somebody give me a rundown?
XBAP is the regular .NET framework exposed (as WPF/XAML) in the browser; Silverlight is a much reduced framework, focusing on things like UI/media/etc. But with the advantage of cross-patform support, and (with the next version) allowing the client to take it out-of-browser.
The XAML is similar, but is not a strict subset/superset; so you can't always translate "as is" in either direction; it will also be easier to go Silverlight-to-WPF/XBAP
With Silverlight 3 on the horizon, I'm not sure I'd bother looking too hard at XBAP myself... if I wanted the full .NET, I'd go WPF/ClickOnce.
And I'm pretty sure Silverlight doesn't use presentation host...