Creating a Silverlight 4 and WPF Application

We are creating a Silverlight 4 LOB application. However, we are concerned that not all of our customers will be able to support Silverlight. For example, most of our customers will be large companies, and perhaps their IT department did not allow Silverlight to be installed on user machines. Perhaps some of our clients have installed 64-bit versions of IE on user machines. Both of these situations will not allow our customers to use our application.

To cope with this opportunity, we would like to create our application in such a way that it can be easily placed as a WPF application if we had to return to this position. Our middle level and backend will be the same regardless of the client used.

We are going to first create our application as a Silverlight application. The WPF version will come a bit later. My question is this. What precautions should be taken when creating our Silverlight (UI) application to ensure that the application easily portes the WPF application (using ClickOnce)?

+4
source share
2 answers

WPF (close enough) is a superset of Silverlight, so it's better to switch from Silverlight to WPF than vice versa. As long as you use the MVVM framework, which abstracts over any platform features, code porting will be simplified (I would recommend Caliburn.Micro ).

Rocky Lhotka (author of the CSLA business object structure) has a nice blog post about some of the differences between Silverlight and WPF, and things to consider when targeting both platforms.

+2
source

One of your problems will be solved by Silverlight 5, as the SL5 plugin will work in 64-bit IE. Porting from silverlight to wpf should not be too complicated. One thing you can do to protect against potential problems is to get a third-party library of ui controls that work with both silverlight and wpf. I would try to start with silverlight and switch to wpf only if you see a real rollback from your clients.

0
source

Source: https://habr.com/ru/post/1344513/


All Articles