I need to convert an existing WPF project to Silverlight. I know that there is no an automatic way of doing it.
Could you share your experience and give advise regarding steps for this conversion and what pitfalls one should be aware of?
Considering that Silverlight is a subset of WPF, there are many potential issues.
First I would ask why you want to do this, since generally they are used for different purposes. That being said, if you are determined to do a port, then you need to do a namespace analysis to validate that all of the namespaces you are using in your WPF app exist within the silverlight runtime. If you are using things not supported in SL, then you are going to be spending quite a bit of time re-writing those portions.
Other issues I know of are that Silverlight 3 runs in a sandbox, so you can't use the disk, hardware on the box, etc. You also are limited with regards to any requests made over the network, as they must be back to the hosting domain, or use a cross-domain policy file.
Silverlight 4 brings more parity to the party, in that it allows you to run as a trusted desktop app, and brings more of the WPF functionality in, but still not equal.
Kind of a hard question to answer without further detail, but this should get you started.
Related
I know this question was asked before, but almost 2 years have passed and the business requirements are a little different.
We are in the beginning of developing a mid-sized application and are divided which technology to use for the front end, WPF or ASP.Net MVC 3?
We are not an IT-company, but a business company with an IT-department who can outsource programming tasks, while the business core shall remain within the company. I did spend a lot time searching the internet for the answer, and I partially did succeed, but since the question is so important, I thought I ask here as well.
Of course, before someone can answer the question I need to specify the requirements and environment for the application at stake:
Infrastructure:
We have a pure Windows environment. Each user will have either Windows XP SP3 (currently) or a future version of Windows (if we skip from XP to Windows 8 remains to be seen, but let us assume that the user will use Windows 7 next) installed.
We are aiming for a service oriented architecture, meaning we only want to run/show on the client machine what is really needed. This is especially important since the databases are far away from the clients (USA/Europe). We plan on using WCF for cross machine communication between user system (brower or WPF), application and database server.
We expect the main user group to be around 30+, but since we are a growing company there should be no issue scaling up to 100 users. The users are spread over three main locations over the world, while we want the option to support smaller locations as well. All those locations are connected to the same intranet.
UI Experience
The new system is supposed to replace existing systems which are desktop applications (Winform). The number of screens are likely to be around 100+ with many labels, comboboxes, graphs. I like to call it an expert system b/c we expect the user to spend multiple hours a day with it, the user is expected to do interact fast with it (many clicks, multiple dialogs pop-up and close etc.) and the application will contain a lot of business logic (mostly mathematically).
Some limited interaction with Excel is required. At this stage only importing formatted data out of .xlsx file into the application in order to work with the data. This we expect to happen often.
Copy&Paste from Excel or other applications into our new application is a requirement (no pictures, just text).
We will use a vendor control library for a richer UI experience.
The users are used to desktop applications for their daily work (current systems/Excel etc.).
Tablet or smartphone support is not a requirement.
Deployment
If we were to use a WPF application we would likely either deploy it in CITRIX or use Click-Once.
Here are arguments of the two opposing factions:
Pro Web:
Deployment is much easier. All the requirements can be done in a web application directly, and if not we use ActiveX or make a separate desktop application for the missing parts. Also, the IT world is going to stop doing pure desktop applications and everything is moving to HTML 5 (Windows 8).
Pro WPF:
Web applications use many different technologies which makes it more difficult and costly to develop and maintain (HTML, ASP.NET, CSS, JavaScript, JQuery, AJAX). There are major deficiencies in a web-applications, mainly
Considering the various browsers and versions.
Screen resolutions
No hardware support for graphics (business graphs, point graphs with 200+ points)
Restricted access to local hardware (importing files, creating files, printing)
Keyboard shortcuts
Point #1 is also worrying since the browser is more out of control since other web-applications in the company (not expert systems) are used, and we fear conflicting interests with the new application (e.g., we must use a browser version where ALL applications run/render fine).
I know there is no black and white on this, but I would be interesting in the following:
Who was in a similar situation and how did they solve it?
(there is a nice article at http://karlshifflett.wordpress.com/2007/12/20/reasons-for-choosing-wpf-over-aspnet-for-very-large-project/, but the problem is that the article is 5 years old :(
How much more expensive is a web solution?
For development assume that the programmers are equally skilled in both (we can outsource this). For maintainance assume that we will internally support this where we have limited knowledge in ASP.NET and WPF. We know WinForm/WCF using C#. We would have to train/learn either technology.
How easy can a web application do Excel interaction, printing etc.?
I read a lot about "ActiveX hell" and I am wondering where we stand today?
Deployment
I have used Click-Once quite successfully in the past, although some team members mention that Click-once can be an issue. Any experiences?
Future?
The system is supposed to last 5+ years. We can not target HTML5 at this time (WinXP only up to IE 8). Where does Windows 8 stand on this?
Other thoughts?
What important things am I missing?
Thank you!
I know this entry is long and not an easy question. So I think you for reading and thank you even more for constructive feedback. Thank you!!!!
I would not build a business application in WPF, especially if your goal is to have it last for 5+ years. Silverlight is in sunset phase now - Win8 apps are betting on JavaScript and HTML5 now, though you are correctly noting that HTML5 support is not universal across all browsers and platforms (see http://caniuse.com/)
Let me try and address some of your concerns above to hopefully persuade you to build a web app:
Considering the various browsers and versions. Yes, you would have to do that. However, for enterprise applications most of the time you can find an acceptable solution if you use industry-standard web technologies and don't use esoteric HTML5 stuff that is not universally supported. It won't be a slam dunk, but it is very much doable.
Screen resolutions. You can address this by utilizing what is commonly known as Responsive Web Design. Once again, there is broad community and industry support for CSS frameworks that allow you to achieve responsiveness. YUI and Bootstrap come to mind as two examples.
No hardware support for graphics (business graphs, point graphs with 200+ points). Well, here is where HTML5 Hardware Acceleration may help you, but I'd say that libraries like HighCharts can easily handle 200+ points graphs - see this example
Restricted access to local hardware (importing files, creating files, printing). Fair point. I'd argue that working with files is MUCH easier with things like Socket.io, Filepicker.io and Zip.js, but "enterprise" requirements may get in the way. And as for printing, you can create "printable" version of your pages or generate PDFs and Excel Exports on the server side. Not ideal, but very much workable.
Keyboard shortcuts. Have you used Gmail app? It is full of shortcuts and keyboard-based interactions. This applies to any application - if you need keyboard interactions, you'd have to build them regardless of your choice of WPF or Web
I am thinking...
Is Monocross a good option to use so
we could port to the IPad if we were
forced to?
You are correct that we intend to support the platforms mentioned above, but we will support Windows Phone 7 moving forward, and have deprecated earlier versions of Windows Mobile.
Since the last post on this thread, we have added the concept of view perspectives to help with CRUD operations. View perspectives are used to enable multiple views for each of your model types, and are represented as a string passed from your controller to the view container to indicate the perspective you wish to provide the user. This makes it easier to construct and render views for CRUD, or any other, operations.
We are also currently writing a book for Wrox Press that will cover cross-platform development with MonoCross in much more detail. The book will be available in early 2012.
Scott Olson
MonoCross Project
Monocross very nicely follows the kind of pattern enforced by monotouch and monodroid, with a separate presentation layer and application code
According to MonoCross' own wiki, their intent seems to be to fully support these platforms, and windows mobile in the future.
At the time of this writing however, (monoCross 0.3.2) all CRUD related operations are either in development, or not yet started, so there is a good chance you will still run into trouble during your own application development.
The biggest hamper (in my opinion) in porting applications to monotouch, is the lack of databinding support, and monocross has most of those implemented at its current release, but not all of them.
We are considering migrating our site from flash to silverlight, and also building additional components in silverlight. However there is a strong argument that many people do not have silverlight on their computers, and will not or cannot install silverlight.
Are there any official figures on how many computers have adopted silverlight, and is it a bad idea to build a company website with elements of silverlight on it?
Please note I am not trying to be subjective here, I am looking for solid, official figures and also advice about whether this is considered in general by developers to be an acceptable deployment solution.
I have to discuss this issue with my boss later.
From my answer to this question:
Adobe Flash is on 97% of computers.
Silverlight is on 55% of computers.
Java is on 73%
Source
According to Microsoft (so read into that what you will) current Silverlight penetration is 60%. For further "solid, official figures" you might need to cite the authorities you are willing to accept as being "official".
Whether it would be a good idea for you to migrate would depend very much on what sort of site you are running. Your site would need to be quite compelling to entice others of the 40% or more web clients to install Silveright to access your application.
If you are already a "Flash site" you must surely have built up some skills in this tool and you already have access to a larger set of clients. You would therefore have to have some killer reason to use Silverlight because Flash has something very important missing. What would that be?
"Is it a bad idea to have elements of Silverlight on your site"? I would say that this is the best way forward as long as those elements are not critical to delivery of your content. That way you can gauge the willingness of your visitors to install Silverlight without blocking their access to the reason they came to your site in the first place. This will give you basis for your own "solid, official figures" about whether to grow your usage of Silverlight or not.
First I'd like to make it clear, I'm not looking for a "my tech is better than yours" type of post; this is a real case scenario and I have been faced with this decision. With this in mind, let me explain:
We have a WinForms application. It started in the early .NET 1.0 but the first shipping version was using .NET 1.1. There are layers (like BusinessLayer.dll, Datalayer.dll, Framework.DLL, etc.) but at some point during the "long" development cycle of this application, the "presentation" layer (Win Forms) got infected with some code, thus the "separation between the code and the presentation with code behind" is some sort of myth.
Bad practices or whatever, the truth is that the application is there and it works.
Years passed and we had .NET 2.0, we slowly migrated and it mostly worked, had to change a few calls here and there. Last version did the same thing, but for .NET 3.5sp1. We needed some sort of Webservices thing, and decided to use WCF instead. It works fine.
But despite all these .NET upgrades, most of the application's codebase is still the same old rock and roll from 5 years ago. We use Gentle.NET (old and unmaintained now) for our dataobjects (it was a blessing 5 years ago!).
Our presentation layer, the winforms, are "nice looking" since we employ 90% of completely gdi+ custom controls. (whenever possible without having to hack the WinAPi). The application is touch based (i.e.: it makes use of the Ink but it doesn't rely on that), but the buttons, labels, etc, everything is "designed" to be used with a tactile device. (TabletPC or Touchscreen). Of course some users use keyboard/mouse.
With all that in mind, and with all this web2.0 and Internet fuzz (plus Jeff's posts ;) ), we are considering the possibility of rewriting the application but using a web technology.
The idea is obviously bringing more availability for our customers (they can use the system whenever/wherever they want), and less maintenance (we can upgrade and it is an instant upgrade for 'em all), etc. You know, the usual Internet vs WinApp thingy.
The problem is that given that this is the healthcare industry, not all of our customers might be willing to "move" their databases to our server/s, which is acceptable, and would force us to install a webserver/database server in their own servers so they have their own copy. Not a big problem (except we would have to update those manually but that's not an issue, given that we've been updating win32 apps for 5 years now!).
Now, back to the main "question".
The team has little Asp.NET experience, we did program a lot in ASP 2.0 (in 1999/2000) but that was a spaghetti of HTML+VBScript+CSS, so I don't think it counts. After all that experience (the Internet bubble!) we went back to VB6 then C#.NET 1x and you know the rest of the story. We're a small team of C# developers for WinForms. We've acquired some Linq To SQL Experience in our last .NET 3.5 ride, and we liked it. We felt it very natural and very "if we would have had this five years ago…" like.
Given all this, rewriting the application is not a "simple task" (not even if we wanted to do it in the already known C#.NET), it would take time and planning, but we could correct dozens of mistakes and with 5 years of experience working with the application, we now can say that we have a better idea of how the customers would like to use the software and what limitations we created (by ourselves) when we designed the current app.
All that "knowledge" of the application and the way the business works, could be applied to produce a much better application in terms of design and code and usability. Remember in .NET 1.1 we didn't even have generics! ;) (you'll see lots of ArrayList's hanging around here).
As an additional note, we use Crystal Reports (and, as usual, we hate it). We don't think the ink control is a "must" either. The HTML/CSS could be shaped to look the way we want it, although we're aware that HTML is not WinForms (and hence some things cannot be reproduced).
Do you think that planning this in MVC (or WebForms) would be too crazy?
I like the MVC (ruby on rails like) idea (I've never programmed in ruby beyond the basics of the book), so no one in our team is an expert, but we can always learn and read. It mustn't be "rocket science", must it?
I know that this whole question might be a little bit subjective, but would you replace an aging Winforms application with a new ASP/MVC/XXX web application? Do you have experience or have tried (and had success or failed) ?
Any insight in helping use better decide what to do will be appreciated.
Thanks in advance!
UPDATE: Thanks to all who responded, we'll evaluate whether this is a good move or not, it sure is a hell of work, but I am afraid the the desktop app is getting older (using old net 1.1 hacks) and tho it has been more or less working without problems in Vista and W7, I'm afraid a future update may break it.
Also, lots of "more or less core" parts of the application are exposing some badly designed ideas and we had to hack here and there to accomplish certain tasks. Part inexperience, part lack of 100% knowledge of how the business worked (and Customers not sure what they wanted).
A new application (in any form) would allow us to create a better foundation while retaining all the user knowledge.
But, it's a L O T of work :) So we'll consider all these options here.
As some of you have mentioned, maybe a thinner client and some (ab)use of WCF here and there might be more appropriate.
Once again, thanks to all!
It would be best to ditch all your efforts of reusing the desktop application code when you recreate the web app. Following are the reasons:
Web apps especially asp.net use a different model. For starters note http is stateless. Each time the browser talks to server you have to explicitly send the current content of all the controls on the current page. You would not have used such a model in your Windows application.
To decrease load on the network you want to optimize the size of viewstate and how frequent you make http requests. Again your existing window app does not have any such provisions.
Updating view. You might have different event handlers, threads and what not in your windows application to update the GUI in different scenarios. All of that will need to be replaced. Javascript is a totally different animal.
Security. When using a browser your access to the local disk is highly limited whereas you will take the same for granted in windows application. If there is any code in the windows app that requires local resources, then that is going to be a trouble spot for you.
I would recommend the following:
Verify if your current application has any local disk access requirements (e.g. read/write to local file etc).
As you write the different http modules or handlers, you can try leveraging some of the backend/ business logic part of the existing windows application.
Give some thought to what part of your application can become a web service.
It sounds like the application needs a lot of refactoring to clean it up. If you want to move to a web model, and have maximum reuse you will really need to do that. Before you move to a web model I think you need to understand if it will be possible to replicate your user interface in that model. Is it your unique selling point from a customer perspective? You want decisions like this to be user driven rather than purely technical decisions.
It sounds like your application is the perfect candidate for a thick client application, rather than the lowest common denominator web model.
Some things to consider:
How will the web interface impact the Tablet interaction?
What new customers will having a web version bring you?
Will existing customers abandon your product?
Do you have access to consultants or outside resource with the right skills to mentor you in web technology? If you don't you can rely on StackOverflow or other web resources to help. You need some good mentoring and guidance on the ground with you.
What happens if you start this effort and it takes much longer than you expect? You know the app but don't sound like you know the web. Past experience shows that massive rewrites like this can end in disaster (it never sounds so difficult at the start)
Can you possibly write new features in a web-based version?
Could you move to ClickOnce deployment to make the application easier to deploy to customers. One of the benefits of the web is easier (zero) deployment. Can you get closer to that?
Would it be easier to migrate to WPF and create a browser application with that?
Silverlight or Flex might be better options for creating a rich experience, and may be more approachable for WinForms developers. Is this a possibility?
It seems like your app. is one of those that works best as a desktop app. Though you want your users to be able to access your app. using a browser.
I would suggest refactoring as much as possible so that the GUI gets cleaner and don't have "code".
When you've done this, start developing a asp.net mvc app but keep your desktop app. You should be able to use all layers except the UI layer, making it easier/faster/... Now that mvc exists, I'd say webforms is more about letting non-web devs do web. But you know web, sort of, and you want control so mvc is the way to go.
I'm mainly asking this to professionals who know the playing field of professional developing. Is it worth it to learn and develop skills in Silverlight?
I know that penetration for Silverlight is obviously low in comparison to Flash but Silverlight seems lighter and a more cutting edge technology.
What are some of the benefits Silverlight has over Flash?
Is there a lot of work for Silverlight developers (of course combining them with ASP.net)?
Thank you very much for all the responses. :)
Edit: I program mainly in C# so there will be an obvious plus side to using it.
Also, how reliable are these results: BubbleMark
It's a huge topic and you can read articles all day on Flash-vs-Silverlight-vs-AJAX.
I use Silverlight and was completely over the moon when it was released due to the ability to employ the CLR in browser based applications. Javascript/DHTML development drives me nuts and for me Silverlight was my way to escape its clutches. As far as Flash goes my very brief foray into it found ActionScript to be more painful than Javascript but that was years ago and things have undoubtedly improved since then.
Basically if you're using .Net for your back end then it makes perfect sense to use Silverlight for the front end. It means you only have one development environment and language to deal with and where appropriate you can reuse a lot of your back end code on the client.
In practice it's not quite that easy and my experience has been that there is a lot of resistance in user land towards Silverlight. The main bone of contention is generally that the cross browser and operating system support is not good enough. Users that employ Opera or use Linux or PowerPC Macs can't use Silverlight (Moonlight isn't there yet). Those users are generally vocal ones.
If you know all your users will be on IE/Firefox on Windows/Mac Intels or you have a compelling application that users will change their set ups for then Silverlight is almost certainly your best option. If you have an application that you want to hit a wide range or disparate users you may need to weigh up the options a bit more.
The fact that Microsoft has thrown their weight behind Silverlight as the Web Application Framework of choice gives it a pretty decent chance of becoming widely used (though certainly no guarantee).
To position yourself in the most versatile way, though, you might want to consider first learning about the capabilities and limitations of both systems and then learning how to implement with both.
There will probably be many projects done with Flash, and many done with Silverlight. If you can program to either, you will be in a good position. If you are able to provide skillful assistance in deciding which one is best for a given project, you will be in a great position.
I tried it and did not like it. I didn't like the split development environment, xaml, or the limited install base and platforms it runs on. The IDE and platform itself still has a ways to go before I would consider it for use in a production environment.