Group 73

All-InclusiveMigration Service

Are you looking for a fast, hassle-free, and cost-effective way to have your Silverlight or WPF application run without plugins on all modern browsers, while preserving 100% of its look and functionality?

You are in the right place! OpenSilver is a modern open-source replacement for Microsoft Silverlight that revives the technology and brings it to the next level. When moving from Silverlight or WPF to OpenSilver, your application code is not modified. The back-end code is untouched, and you can keep maintaining and improving your application like you did before, or modernize it at your own pace by leveraging the latest technologies. More importantly, the resulting application runs on all browsers and is almost pixel-perfect identical to the original one.

Our team of experts at Userware – the company behind OpenSilver – offers fixed-cost, milestone-based, end-to-end professional services to transition your application from Silverlight or WPF to OpenSilver. Instead of changing your application code, we work on improving OpenSilver to make it behaves exactly like Silverlight/WPF.

No effort is required on your side: we take care of all the work. Each milestone gets you a Visual Studio solution that is similar to the original solution, except that the Silverlight/WPF tools have been replaced with the OpenSilver tools. You can compile and run it on your side to see the progress. You can keep changing the original code and we will simply merge your changes.

At Userware we believe that an application that took several years to create shouldn’t be thrown to the trash just because of a technological change or a fashionable trend. Microsoft Silverlight was a great technology and applications created with it worked just fine. Let’s get in touch and work together to bring your application forward. You are in good hands for a successful, effortless, and smooth transition to modern technologies.

Read the FAQ below to learn more about our migration service.

Group 73

FAQ

The process is very simple and effortless. The usual steps are:

1. Contact us to start the conversation.
Your options are:

  • Send us an email to: migrations@opensilver.net
  • or follow this link to submit your “XAP” file (ie. the executable of your Silverlight application) (If it's a WPF app, you may submit your EXE and DLLs). We will use it to estimate the workload. We don’t need your source code. We will then contact you to the email address or phone number (optional) that you have specified. Read the question below for more information.
  • Alternatively, to process things quicker, Schedule a Live Meeting to talk to our team about your requirements

2. We usually schedule a meeting during which we answer your questions and discuss the specific needs of your application. We can also sign an NDA if you need one (note: a standard NDA can be found here).

3. We might ask you for some additional material to allow us to correctly estimate the workload (screenshots, code metrics). We do not need the source code to make the proposal/quote. Please see the “recommended material” question below for details.

4. We will send you a quote (a proposal) that contains all the information about the milestones, the duration, the cost, the deliveries, etc.

5. After you agree to the proposal and we sign the contract, the migration work starts. The first step is for you to send us the source code of your Silverlight or WPF projects to migrate (note: we usually don’t need the source code of the back-end, only the client-side, see the corresponding question for details). Please also provide us with the instructions to run your application on a developer machine or, as an alternative, you can provide us with a virtual machine that contains the development environment.

6. At each milestone, we send you a delivery (see the corresponding question below for details). Each milestone triggers its corresponding fixed-cost payment. If you are interested in testing the deliveries on your machine, we will assist you to do so.

7. Towards the end of the project, usually at the Beta stage, you are encouraged to start testing your application and to provide feedback. We usually maintain a shared list of known issues (on JIRA or Azure DevOps) that our team and your team can update. We are flexible on the timing of the tests and we can adapt to your needs.

8. The last milestone is the Release Candidate. The Acceptance Phase lets you report additional bugs that we will fix promptly.

9. We help you to deploy and bring your application to production.

10. After the project is done, you can subscribe to an optional yearly Priority Support Plan that includes senior developer hours. The Priority Support Plan is recommended for customers who have their application used either by their clients or internally in environments where the resolution efficiency is time sensitive.

11. You are all set. Silverlight (or WPF) has been replaced with OpenSilver. Your application now runs on all modern browsers, both on desktop and mobile, without requiring users to install any plugin. The new application is virtually identical to the original one, in terms of both UI and source code.

12. You can maintain and improve your application like you did before.

The material we need is:

  • Screenshots or a video of your application. As an alternative, you can demo the application to us during a meeting. We can sign an NDA if needed (note: a standard NDA can be found here). Our two priorities for the demo are:
    • To see how big your application is (please make sure that all the screens are shown)
    • To see what the most complex UI controls are (please show the most complex user interactions)
  • Code metrics of the Silverlight / WPF projects. Those can be obtained by following these steps: open Visual Studio 2012, 2013 or 2015, load the Silverlight projects, and click the menu "Analyze" -> "Calculate Code Metrics" -> "For Solution". If you are migrating from WPF, you can use the latest Visual Studio version. Then, please send us a screenshot (image) of the result. We prefer a screenshot rather than an export because it allows us to see the icons of the projects, which help us to understand the project types. Please note that we need Code Metrics for each assembly that gets packaged into the XAP (the application executable), so if a project references another project, please make sure to also include the Code Metrics of that referenced project.
  • The XAP file, which is the executable of the Silverlight application. Note: If you are migrating from WPF, you can send us the EXE and DLLs.

– Where can I find the XAP file? –
You can find it inside the folder named “ClientBin” of the application source code. If that folder contains more than one file (such as multiple files with the .XAP extension or other .DLL files), please send us the whole “ClientBin” folder. Please note that we do not need the source code.
– Why do you need the XAP file? –
We will analyze the XAP file using an internal tool which generates for us an Excel report containing the list of all the Silverlight API’s that are used in your application. Once we have that list, we will determine which features are supported and which are not supported in OpenSilver yet, and we will estimate the workload to support all those features in OpenSilver (note: eventually all the features will be supported, but we prioritize based on our clients’ needs).
– What if I don’t want to share the XAP file? –
If you do not wish to share your XAP file, no worries, we can also run the analyzer tool on your own computer, and then you can just send us the generated Excel report. We can also sign an NDA if you need additional confidentiality guarantees (note: a standard NDA can be found here).

Userware will do all the work and will take care of everything. No effort is required on your side.

We contact you only in the following situations:

  • Before the start of the migration, we need you to send us the source code of the Silverlight or WPF application to migrate (note: we usually don’t need the source code of the back-end, only the client-side, see the corresponding question below for details). We also need your help to get your Silverlight or WPF application to run on a developer machine. As an alternative, if you prefer, you can provide us with a virtual machine that contains the development environment.
  • Towards the end of the project, usually at the Beta stage, you are encouraged to start testing the migrated application and provide feedback. We usually maintain a shared list of known issues (on JIRA or Azure DevOps) that our team and your team can update. We are flexible on the timing of the tests and we can adapt to your needs.

If you make changes to your application code while the migration is taking place, you may want to synchronize with us so that the changes are merged into our branch on a regular basis, such as after each milestone delivery, or at the end of the migration, whichever works best for you.

We usually propose to have regular status meetings during which we will update you on the progress and we will show you the status of the application. If you are interested in testing the milestone deliveries on your machine, we will assist you to do so. If you do not want to have status meetings, no worries, we can also just send you regular updates via email.

The price and timeline depend on both the workload and the number of resources that we can allocate.

The workload can vary by order of magnitude depending on the number of Silverlight or WPF features that your application uses which are not supported in OpenSilver yet. It also depends on the third-party libraries that your application uses.

Please contact migrations@opensilver.net to help you with the price estimation of the migration as per your requirement.

– How does the timeline impact the price? –

The choice of the timeline has an impact on the price because a shorter timeline requires us to take valuable resources from other OpenSilver developments, and it makes it more difficult for the project team to leverage the work done by the rest of the OpenSilver team. A longer timeline, on the other hand, can significantly decrease the price because it makes it easier for us to find the right resources at the right time, and it also allows us to leverage the work done by the rest of the OpenSilver team as part of the product roadmap.

No, OpenSilver is not a “migration tool”.

OpenSilver is an open-source replacement for Silverlight. You can see it as a sort of "successor" to Silverlight, written from the ground up but aiming at functioning exactly the same as Silverlight.
The main difference with Silverlight is that OpenSilver does not require end-users to install a plugin, because it uses the WebAssembly technology, which is built into all modern browsers.

Note about WPF: Silverlight was a subset of WPF, so OpenSilver will also support a wide range of WPF features, allowing to run WPF apps on the Web.

OpenSilver is not a "conversion tool", meaning a tool that would convert the application source code from something into something else. Instead, OpenSilver is a development framework (aka SDK), just like Silvelight was a development framework too (note: Silverlight was also a browser plugin, but that part of the technology is no longer relevant with OpenSilver).

When we say "migrate your application", we mean migrate from Silverlight/WPF to OpenSilver, which is something that we do manually by replacing the Silverlight/WPF development tool with the OpenSilver development tool. Some work might be needed because some features of Silverlight/WPF are not yet supported in OpenSilver: we work to improve OpenSilver until all the features of Silverlight or WPF that are used by your application are supported. Eventually all the features of Silverlight and WPF will be supported in OpenSilver. We prioritize the developments based on the needs of your application.

An application usually comprises two parts: the front-end and the back-end.
We only need to migrate the front-end. We do not need to migrate the back-end. The front-end is the one that uses the Silverlight or WPF technology, which we replace with OpenSilver. The overall architecture remains the same.

Your codebase is not modified because most of our work consists in improving OpenSilver until it supports all the features of Silverlight or WPF that are used in your application. The deliverable of each milestone is a Visual Studio solution that is similar to the original solution, except that the Silverlight/WPF technology is replaced with OpenSilver. You can compile and run the delivered solution in the browser to see the progress. You can keep changing the original code and we will simply merge your changes.

Deliverables can be sent to you via .ZIP files or be pushed to a private repository. After the migration to OpenSilver is done, you can keep maintaining and improving your application like you did before. That is, you can keep using the same popular Microsoft programming technologies and languages (C# or VB.NET), UI stack (XAML), API’s (.NET), and tools (Visual Studio). You can leverage the extensive documentation, tutorials, and samples that were made for Silverlight. While backward compatibility with Microsoft Silverlight is one of the core features, OpenSilver also lets you modernize your application at your own pace by leveraging the latest technologies:

  • You can use the latest versions of C# (including C# 10, whereas Silverlight was stuck with C# 6)
  • You can use the latest versions of Visual Studio (including 2022, whereas Silverlight was stuck with VS 2015)
  • You can use the latest versions of .NET (including .NET 5, .NET 6, and .NET 7 Preview)
  • You can use .NET Standard to share assemblies between the client and the server or among disparate platforms (whereas Silverlight was stuck with Portable Class Libraries)
  • You can import .NET Standard-compatible packages from NuGet.org
  • You can leverage the latest browser API’s via simple yet powerful JavaScript interops
  • You can implement new features by importing JavaScript libraries
  • You can leverage both the .NET ecosystem and the JS ecosystem

No, usually the back-end code doesn’t need to be migrated. Silverlight and WPF are front-end technologies. The migration consists in replacing the Silverlight or WPF developer tools with the OpenSilver developer tools.

The front-end will keep communicating to the back-end Web Services via WCF SOAP or REST calls. Those technologies are internally implemented in OpenSilver via AJAX (XmlHttpRequest under the hood).

The only times that we might request to change the back-end code are usually:

  • If your application uses “WCF RIA Services”: we need to replace it with “Open RIA Services”
  • If your application uses “WCF Duplex” communications: we might replace them with SignalR
  • If your Silverlight or WPF application uses some unsupported client-side reporting libraries: it may be more convenient to generate PDF files or other reports server-side and then download them or display them on the client
  • Some minor endpoint configuration adjustments might be recommended in some cases (but they won’t impact the legacy Silverlight or WPF application)

Once we recover the source code from you, we start setting up the development environment on a local developer machine (alternatively, as mentioned, you can provide us with a VM if it works best for you). Then, we create new OpenSilver projects and we copy the legacy source files into those new projects to recreate the original structure. Usually, we share the same C# and XAML files between the legacy Silverlight/WPF projects and the new OpenSilver projects, to make sure that the changes do not break the original application.

The next step is fixing all the compilation errors. Errors are usually of 2 types: they are either unsupported third-party libraries, or Silverlight/WPF APIs that are not implemented in OpenSilver yet. To make the code compile, we repeat the steps above for both the application code and the third-party libraries code: that is, we create OpenSilver projects and we copy the Silverlight/WPF code inside them, then we reference those projects from the main application project.

At this stage we do not implement unsupported features yet: we use stubs to make the code compile properly, and we mark those stubs with the [WorkInProgress] attribute so that the compiler can display warnings.

Then we work on ensuring that client-server communications work as expected, and we move on to implementing the unsupported Silverlight or WPF features in OpenSilver. We also debug the features that behave differently compared to the legacy application. We try our best to never change your application code. Some browser sandbox security limitations might occasionally force us to make small changes to your application code. In those rare cases, we mark the changes with the #if OPENSILVER compiler directive so that it appears clearly what code is specific to OpenSilver. Examples of such scenarios include:

  • The “Open File Dialog” needs to be asynchronous in modern browsers, whereas in Silverlight it could be synchronous
  • A web application cannot force the display of a “Save File Dialog”, because browsers by default will save files to the “Downloads” folder. To approximate the behavior of the legacy application, we can add a “ChildWindow” inside your application. It will mimic the “Save as” dialog and let the end-user type the name of the file, which is then saved to the Downloads folder.
  • Access to the local file system and “interop” with Desktop applications is limited by the browser security sandbox

The migration is divided into milestones, the number of which depends on the complexity of the application being migrated. The main milestones are:

  • “Compile” - wherein we migrate away from SL and compile the source code on the OpenSilver framework.
  • “Preview” - wherein your code starts to run in WebAssembly on modern browsers, step-by-step debugging is functional, and client/server communications start to work
  • “Alpha” milestone - could be 1 to several Alpha phases based on the size of your application. Several features start functioning and some user scenarios work properly
  • “Beta” milestone - could be 1 to several Beta phases based on the size of your application. Your application is almost fully functional though some features might still need some work.

The milestones are detailed in the proposal that we send to you after analyzing your application (see the question about the process).

WebAssembly (aka WASM) is a standard file format that is recognized by all modern browsers, including Edge, Chrome, Firefox, and Safari, both on Desktop and Mobile systems. The list of browsers that support WebAssembly can be found here.

WebAssembly works like the other standard file formats such as .HTML, .CSS, .JS, .PNG, .JPG, etc. in the sense that the browser will download the .WASM files, put them in the browser cache, and process them locally on the end-user machine to run the web application inside the browser security sandbox.

– Do we need to publish a different version for each browser? –
No, you do not need to publish a different version for each browser.
– Will it render the same on all browsers? –
Yes, WebAssembly files will render the same on all browsers that support them.
– What about the security of WebAssembly files? –
WebAssembly files have the same security as JavaScript files. Like JavaScript files, they get downloaded from the web server to the web browser, then they get executed inside the browser security sandbox. Multiple layers of security of the browser ensure that those files do not access the local system. The WebAssembly files generated by OpenSilver are static files. They are generated when the OpenSilver application is compiled from its source code. This happens either on the developer machine or on a Build Server. No file is ever executed server-side. The WebAssembly files are pure client-side files. This allows for greater security: WebAssembly files cannot lead to unauthorized server access because they are client-side only.
– Do we need HTTPS? ––
HTTPS is a secure way to send data between a web server and a web browser. The decision to use HTTPS is not related to OpenSilver. The same security considerations apply to WebAssembly files as they do to other web files such as JavaScript files.

OpenSilver is a software development tool (SDK) that allows the creation of front-end web applications made of static self-contained files that run entirely client-side. The security of OpenSilver applications is great because application files run entirely inside the security sandbox of the end-users’ web browser. No code is ever executed server-side. The security of the OpenSilver framework is thus comparable to that of any “pure client-side” javascript library. This ensures maximum security because the code has neither access to the server nor to the local machine.

When compiling an OpenSilver application, the compiler output is a set of static files with the following extensions: .HTML, .CSS, .JS, and .WASM (in addition to .PNG, .JPG, and other possible resources used by your application). Those files are generated when the OpenSilver application is compiled from its source code. This happens either on the developer machine or on a Build Server.

No particular server-side technology is required to host those files: the host can be IIS, a Linux server, or just any other technology as long as it can serve static files to web clients. When navigating to the URL where the OpenSilver application is hosted, the end-user’s web browser downloads the .HTML, .CSS, .JS, and .WASM files of the application, caches them, and executes them locally inside the browser security sandbox. Multiple layers of security provided by web browsers ensure that those files do not access the local system.

The security is much better than that of Silverlight applications because the latter requires a plugin, which could lead to security risks related to the ability to access the local system. OpenSilver applications do not have this risk because they do not use any plugin. Instead, they run inside the browser security sandbox, enjoying the same level of protection as all the JavaScript files that get executed when visiting any website.

Yes, the original source code of Telerik UI for Silverlight (which comes with the Telerik license) can be successfully recompiled with OpenSilver and referenced from OpenSilver applications. The current level of support varies from control to control. For example, the RadGridView and other popular controls are already very well supported, whereas, at the time of writing, the RadMap control still has some known issues due to the incomplete implementation of the “MultiScaleImage” class in the OpenSilver framework. The support gets better and better with every OpenSilver release.

When we migrate your application from Silverlight to OpenSilver, we make sure that the Telerik controls work perfectly. To do so, we start by analyzing your application via an internal tool that lists all the Telerik controls used in your code. Then, we improve the OpenSilver framework until all those Telerik controls work as intended. We try our best to not make any changes to the Telerik source code but rather we fix the implementation in OpenSilver of the Silverlight API’s that those controls are built on. Eventually, all the Telerik controls will be supported - including the most rarely used ones - but at the moment we prioritize our work based on your application needs.
You can get an estimate of the workload to get all the Telerik controls used in your application to work by contacting us (see the question “How to get started and what does the migration process look like?”).

No, there are no license fees for the OpenSilver technology. As the name suggests, OpenSilver is 100% free and open-source. It is distributed under the very permissive MIT license.

– What about 3rd-party libraries like Telerik? –
If your application uses a 3rd-party commercial library, you need the corresponding license from the library vendor. However, since you are migrating an application from Silverlight or WPF, chances are that you already own that license, so you don’t need to buy additional licenses.
For example, the “Telerik UI for Silverlight” license (from Telerik) comes with its source code, and you are allowed to recompile that source code for your own use. This makes it possible to use Telerik UI in an OpenSilver application. If you hire us to do the end-to-end migration for you, we will give you our “OpenSilver Compatibility Pack for Telerik UI”, which simplifies the process of using Telerik UI in your OpenSilver application.

  • The timeline is shorter
  • The resulting application is almost pixel-perfect identical to the original one. Your end-users will barely notice any difference. No need to train existing users. (Note: you can always later modernize the GUI at your own pace, for example by tweaking the styles or making your app responsive to render well on phones too)
  • Your resources are 100% free to work on other topics
  • The back-end doesn't need to be touched
  • The vast majority of your source code remains unmodified, which means fewer risks of regressions and fewer unknowns
  • Take advantage of the many years of work that you have invested to build your application
  • Leverage the modern WebAssembly technology and use the power of .NET in the browser to further improve your application