We're building a Silverlight 4 LOB application. However, we're concerned that not all our clients will be able to support Silverlight. For example, most of our clients will be large companies and it's possible their IT department hasn't authorized Silverlight to be installed on user machines. And it's possible that some of our clients will have installed 64 bit versions of IE on user machines. Both of these situations would prevent our clients from using our app.
To deal with this possibility, we'd like to build our app in such a way that it could easily be hosted as a WPF application, if we had to drop back to that position. Our middle-tier and backend would be the same, regardless of the client used.
We're going to initially build our app to be a Silverlight app. A WPF version would come a bit later. My question is this. What precautions should we take, when building our Silverlight app (UI), to make sure the app easily ports to a WPF app (using ClickOnce)?
WPF is (near enough) a superset of Silverlight, so it should be easier going from Silverlight to WPF than it is going the other way. As long as you are using an MVVM framework which abstracts over any platform specific features, then porting the code will be simplified (I would recommend Caliburn.Micro).
Rocky Lhotka (the author of the CSLA business object framework) has a nice blog post on some of the differences between Silverlight and WPF, and things to consider when targeting both platforms.
One of your problems will be solved by Silverlight 5, since SL5 plugin will work in the 64 bit IE.
Porting from silverlight to wpf shouldn't be too hard. One thing you can do to guard against possible issues is to get 3rd party library of ui controls that work on both silverlight and wpf. I'd sugest to start with silverlight and move to wpf only if you see real push back from your clients.
Related
Our client has a Desktop application (VBA and Access) that they are using for the past 10 years and it is buggy and they want to upgrade it. I want to use the latest MS technologies and plan to make this a web application using .NET 4.0, C#, SQL server and MVC running on the Intranet.
Since the application has many visual components (about 10 different tabs on top and each tab has atleast 10 different controls on it), I was wondering what is the best way to implement the UI layer a .NET web application. The 2 candidates are Silverlight and Telerik controls (we have license for this).
Some issues to consider :
Silverlight Plug-in : Since this new application will only be used internally on the intranet, I dont think installing a Silverlight plug-in will be an issue. Also, since its on the intranet, hopefully download speed should not be an issue for SL apps.
Telerik-MVC : It is really rich in functionality, however, I played around with it (.NET version not MVC) using some of the controls and if there is anything out of the recommended way to use a control, its a pain to get it working.
Skill-set : Do I want to learn how to use a tool (Telerik) or would I be better off learing a technology (Silverlight) in terms of future projects.
I would like to hear any feedback/ issues to help me decide which way to go.
If you are replacing a desktop application then going with Silverlight may be the best approach.
With Silverlight you are writing an application that happens to be delivered across the internet (well intranet in this case). This can be as stateful as you need to be. You have good access (no pun intended) to the database via the WCF RIA Services.
There's also the Prism MVVM model you can develop on top of.
However, I'd double check with the client as to what they are expecting.
Telerik also do a set of Silverlight controls.
If the project time permits, go for Silverlight. Also, if needed, it's possible to create a desktop version (WPF) out of the Silverlight project.
Issues with Telerik control set(or any control set), if you need a control that doesn't exist in the current set, you'll have to either buy from Telerik, or create your own. In the latter case, the whole UI aesthetics might break because it's not easy to create a control matches the tool set.
I have been using WPF for a while, and I keep on realizing again and again that Microsoft invests its efforst in Silverlight, not in WPF (RIA Services, default theme, controls and more).
I thought it might be a good idea to migrate to Silverlight (i.e. creating standalone desktop apps with Silverlight 4.0), the question is whether this is possible or not.
BTW, I think LightSwitch applications are generated with Silverlight as standalone desktop apps.
From MSDN:
Silverlight 3 applications are no longer restricted to running in a browser. They can be run in a browser or it they can be detached from the browser and run from the desktop. These out-of-browser applications allow you to bring the richness of Silverlight 3 applications directly to the desktop without the restriction of running within a browser.
Link: Building An Out-of-Browser Client With Silverlight 3
It is possible to create standalone desktop apps(Out of browser apps) with silverlight version 3.0 or higher and it works great. Now it is also possible to install the out of browser app even without opening a browser as shown at this blog post .Silverlight is awesome and silverlight apps even run on MACs and Linux(limited support)
However, it is not true that Microsoft is only investing in silverlight. Microsoft is investing in WPF too. Though it is possible to create out of browser applications with silverlight, they have lot of limitations when compared to a full blown WPF applications.Dont forget that silverlight is just a subset of WPF, for example, silverlight doesnt have ADO.NET, Hardware device access etc. So if your application is merely a business application and you dont have to access hardware devices or database directly then silverlight might be an option, however if your application accessing client machines hardware resources directly then you are better off with WPF.
My suggestion is, If you know before hand that it is going to be a desktop application then go with WPF(or may be even XBAP). In my experience, useful applications grow with time, new features are always requested time to time. If in future,a feature is requested that cannot be accomplished with silverlight and can only be accomplished with WPF, then you will be in a big trouble because you need to rewrite your app in WPF and it will be hard for you to convince your CFO to allocate more fund just to implement one feature. Silverlight is not designed to develop desktop applications, its main goal is multi-platform support.
Silverlight 3 supports Out-of-Browser functionality.
Quote from Wikipedia silverlight page :
Silverlight 3 supports Out-of-Browser experiences, i.e., Silverlight applications can be installed to the system for offline access (provided the application manifest is designed to allow local installation) where they run outside the browser.
Also here is a quick howto
Out of browser applications have the same security restrictions as in browser applications.
With Silverlight 4 you can create full trust applications which have full access to the computer.
More on Network Security Access Restrictions in Silverlight
If you mean Out of Browser apps, certainly. The Seesmic Desktop 2 app is an excellent example of one of these apps, with it's own updating mechanism. Seems a no brainer to use the XAP/MEF plug-in Model and Silverlight in this manner.
Seesmic Desktop 2
We're developing an OOB app along the same lines, one internet download and you're done. You're not going to get exactly the same APIs as you get in WPF, though.
As others have pointed out, Silverlight apps can be installed to run 'out-of-browser', but even with elevated trust they still have significant restrictions on what they can do and certainly don't have "full access to the computer".
Creating an app from scratch, you may want to consider parallel Silverlight & WPF builds. The code can more-or-less be shared by adding the .cs files from one project (e.g. WPF) to the other (Silverlight) using "Add As Link". The XAML files cannot be linked this way and need to be duplicated, but that may not involve much more than copying & pasting, depending on your structure. There're good examples of this on the web.
Developing both types in parallel would likely involve a lot less effort than having to abruptly switch types at some point and discovering incompatibilities/limitations too late.
For the experienced WPFers out there, how re-usable are WPF, Silverlight and Silverlight OOB applications and components? How much overlap is there?
For example, could I write one application and easily deploy it in the three aforementioned ways?
Ideally, I want to write as little code as possible and have the flexibility of deploying it in a range of scenarios, maybe enabling certain functionality depending on deployment. The WPF family of technologies seems like a good starting point to the casual observer.. but is it really?
The simplified version of the answer is:
1. Silverlight is roughly a subset of WPF.
2. Silverlight in browser apps and Silverlight OOB apps are running on exactly the same framework. It is just a deployment difference.
3. Some OOB apps can be installed as "trusted" apps, and have looser security restraints than in browser apps.
Porting a WPF app to Silverlight is likely going to be very difficult, as a WPF app is likely to use many features of the .net framework that are not available in the smaller subset of the framework available to Silverlight apps. This is something you probably want to avoid.
Porting a Silverlight app to WPF is likely to be significantly easier. It would still be a challenge as there are features in Silverlight not in WPF (though not nearly as many as the converse). In addition to the feature delta, the actual framework that runs the Silverlight/WPF apps are different, so during the porting you would likely run into a certain amount of behavioral differences between the two.
Silverlight and Silverlight OOB apps are running on the same framework. It is possible to have the exact same app binary run in both places. For the most part, they will be behave identically. Some differences: in-browser apps can rely on browser features such as accessing the html dom, invoking javascript, etc. An OOB app doesn't run in the browser so obviously this doesn't apply. Also, if we are dealing with a "trusted" OOB app, it can do things that are prevented for security reasons in the browser (e.g. COM interop).
If you want to create an app that runs in all three places, my advice is to start building the app as an in-browser Silverlight app that is self-contained, i.e. it does not rely on the web page that is hosting it, and includes all the necessary resources inside the xap package (rather than relying on them being next to the package on the web server). Porting such an app to a Silverlight OOB app would be a cinch - pretty much just check a box in Visual Studio and you are done. Porting it to WPF would be a significant amount of work, but it would be much better than going the other way.
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.
Is it possible to convert an existing WPF Application to SilverLight automatically/with minimal effort?
I would argue that you CAN port Silverlight to WPF with minimal effort. I spent 2 hours porting and application I spent 3 weeks writing. I would argue that those 2 hours spent would categorize as minimal effort.
Sure, you need to create a new project, add the files to the new project and tweak them.
Since Silverlight is a subset of WPF its allot easier to go from Silverlight to WPF than the other way around.
For business logic and non-UI code your code should port almost straight across. I had some minor issues around authentication, as Silverlight 2 will pick up any authentication information in the browser, while in WPF you have to role your own login screen and manage cookies etc.
For the XAML it will port straight across if you don't style your controls. If you style your controls the use of the Visual State Manager, currently missing in WPF, will make things a little trickier. You can either re-style your controls in WPF using Triggers, or you can use the VSM implementation for WPF done by John Gossman. Microsoft have announced that they will add the VSM to WPF to make the two frameworks more compatible.
The perhaps most important reuse tough, is skills and experience. Since the two platforms are so similar you will be able to reuse all your skills in WPF.
I recently did a blog post about the Dive Log sample application and how I ported it from Silverlight 2 to WPF. Might give you some idea of the process.
Not really. I have found some articles regarding the multi-targeting option for WPF and Silverlight at the same time. At this moment, if you are not using PRISM, it is quite a challenge to target both of them, fortunately achievable.
What do you need to have in mind is that Silverlight uses a smaller (thus more limited) library than WPF.
In response to the comments:
Actually, there is already support for silverlight in PRISM (v2). The idea of PRISM is to provide guidance to developing applications not only using WPF but using Silverlight also - Prism V2 formally was known as Composite Application Guidance for WPF and Silverlight.
By using PRISM for silverlight capabilities, it would give you the warranty that your code would work on both platforms with minimal changes, if none (except maybe the different project types for visual studio).
But of course, if you already started developing your application, you would need to change your code to use PRISM.
Will and Bogdan's answers are correct. The keyword here is "minimal".
Rob Eisenberg has a list of differences here (though this was pre-RTW).
List of Differences in WPF & Silverlight
No. Silverlight runs in its own cut-down version of the CLR. It also is WPF-like, not WPF. You'll have to do a fair amount of work to convert it.
Times have changed. Check out Portable Class Libraries, now supported in .NET 4.0. You can build assemblies that can be used on different supported platforms: WP7, Silverlight WPF and even XBOX applications.
Here is a thread about this:
http://silverlight.net/forums/t/3898.aspx