Related
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.
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.
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 3.0 beta has just been announced at Microsofts Mix Conference in Las Vegas.
Two features of the new beta are 3D-graphics and the ability to run applications outside of the browser, which to me seemed to be two of the major features that WPF (Windows Presentation Foundation) previously offered over silverlight.
I am currently evaluating WPF and Silverlight for possible use in our companies future development activity, and this announcement has left me confused as to the intended direction of these two UI technologies and why I would choose one over the other.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision? Given the announced changes to silverlight, Would your decision have changed had you made it now, and if not, why?
Any advice would be appreciated.
The biggest difference I find is the asynchronous model you have to adopt
in your Silverlight application.
It does seems like an advantage (and it can be), but it does make
life very difficult sometimes.
There are also some limitations that can be a real challenge like the absence
of print support.
I would recommend Silverlight over WPF when:
- There is no need for best possible performance (graphics included)
- Can get around the absence of print support (it will come, we just don't know when)
- Camera/Microphone support is not needed
- Can tolerate the assync app/development model
- Can tolerate limitations on WCF (no support for WS-Security at this point)
- There is no need to store huge amount of data on the client.
- There is no need to direct integration with client side applications like Office.
- Has a server to host your application
I would say the main difference is that WPF requires the client to have the .Net 3.0+ framework. Silverlight only requires the runtime. Now that being said, WPF is geared more for controlled environments such as an intranet. Silverlight is meant for the public web. Another difference is that Silverlight is cross platform (Windows, Mac, Linux in the future & Cross browser). WPF is meant for Windows only.
The .Net framework can be a huge download for some users. Silverlight is only 4-5MBs. This is a big difference to run your app on the web, but not a big issue if its an internal application at your company.
Silverlight is Sandboxed which is meant for web use. So if your app requires more permissions you will need WPF.
There are also some differences between Silverlight code and WPF. But from what I've heard, the ultimate goal is to get a Silverlight to run inside of WPF with minimal code changes. But they aren't there just yet.
I have just worked on a WPF project that in hindsight we feel we might have chosen SilverLight for. It is probably more important to know the differences and select the one that is most appropriate for what you're doing.
Here's my starter for ten on some of the important differences - there were originally some differences in the available controls, but that has largely been smoothed out now.
Silverlight
Runs entirely on the client with AJAX
calls to the server for data
Can run on any server, including Windows and Linux / Apache
Uses COMPACT .NET framework
WPF
Runs on the client... usually calls services for data
Runs on Windows XP / Vista with .NET 3.5
Utilises the entire .NET framework
Silverlight is basically a stripped down version of WPF in order to make the runtime libary download as small as possible.
As a result, WPF simply has a lot more functionality available in it and tasks that are simple in WPF often become not so simple in Silverlight.
If running as a web app is not a requirement then the decision is a no-brainer - WPF all the way.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision: Well since WPF was desktop only (or browser based using XBAPS - but that was more a deployment system than a real system) that was a good reason to it.
"Would your decision have changed had you made it now, and if not, why?" - No Silverlight, even on the desktop in v3, is still highly sandboxed and so certain functions are going to be hard/impossible to do due to the sandbox. Also the ability to use DirectX parts in WPF will still give another optimisation area which Silverlight and it's 3d won't be able to use.
It's worth noting that Silverlight's 3D is not the full 3D support of WPF, but only projection of 2D into 3D - i.e. take the 2D plane and allow rotation in X, Y & Z directions. WPF has full 3D modelling with materials, view ports, lighting and camera positional support etc.
I'm well along in the development of our first WPF app for release. Silverlight 3 looks great, but for this application I would still have chosen WPF. The application centers around presenting and manipulating very large sets of images hosted on a central server on our clients' networks. Additionally, the software update/change rate will be minimal. Mass import of new images from a local drive, no Internet connectivity requirements, performance concerns, etc. make this a project well suited for WPF.
One of our upcoming projects, however, will require many remote users to access a single data store on our network. The data they work with requires significant validation and error handling, so running that code locally is ideal. They will need the ability to work both on and offline and remain in synch (probably with SQL Data Services). SLOOB (Silverlight Out Of the Browser) will most likely be our choice for that one so they can have all the Silverlight advantages but use it like a regularly installed application, even without an Internet connection.
Both formats have their place: the trick will be to avoid using Silverlight for everything - we have more tools than just 1 hammer. :-)
Another difference is that with SL you only have one 'window', you can't have dialogs (they can be simulated but their size is limited to the main window) and you can't add multi monitor support.
If you have to interact with existing business applications (e.g. open a document in the archive viewer) you need to use WPF.
I recently have built several internal tool using wpf, and I chose it simply because It was easier for me coming from win32 work. I don't really think that the differences are major, and really... everything i have seen/heard indicates that porting between wpf and silverlight is quite easy.
Storage: You only have 25MB of isolated storage out-of-browser. If I remember correctly from some mix09 video, this limit is lower if your app is in-browser.
http://bliny.net/blog/post/Out-of-Browser-with-Silverlight-3.aspx
No FlowDocument: So there are limitations there too.