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
Related
I am new in windows phone development.
I really have some doubts,
Is WPF is actually using for the windows phone app development ?
I am just confused about to reply to one who ask "Which platform or technology will use for developing windows phone apps ?".
I hope to get a good clear reply here.. I googled it many times. but I didnt get any clear idea yet about this.
Thnks.
No, WP7 development does not use WPF. It uses Silverlight (or XNA for games).
However, the two are quite closely related. WPF was developed in 2006 and introduced the concepts of bindings, creation of UIs via XAML, visual trees, animation, dependency properties and much more. Many of the WPF concepts were re-used by Silverlight, the web-based plugin. Whilst WPF and Silverlight are similar, they are not the same. Despite this, with a little effort, code sharing between the two is possible.
See the following question for more references:
Getting Started with Windows Phone 7
Windows Phone 7 applications can be written using Silverlight or XNA.
With Silverlight you use XAML to create your user interface (as in WPF), but there are couple differences between these 2 technologies: Contrasting Silverlight and WPF.
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.
I am at the initial stage of designing a client application. However, being new to WPF and having already gained some experience in Win forms development, time pressures on the project means that there is a risk to going down the WPF route. If time were no pressure, then I would say forget forms and design with WPF. However, I am not lucky enough to have this luxury. Having spent a little time investigating the Composite Application Block for Forms, I have decided that I will definitely develop the application within this framework. However, there are 2 versions of the CAB, 1 for WinForms that targets the .Net 2.0 runtime which has now been retired, and then the WPF version which targets .Net 3.5. Not being a fan of 'retired' code libraries, I would prefer to use the WPF version of CAB. This may be a silly question, but is it possible to use the WPF version of CAB for Win forms application developement? I do envisage at some point in the future moving to towards WPF. If I could use the WPF version of CAB I am hoping that this would make it easier to migrate the forms application to WPF.
It looks like somebody had the same idea that you did.
I found it by reading this thread on the CompositeWPF codeplex forum, discussing this very issue.
You should be able to do this without too many issues. We are currently using CAB to enable us to display SQL Reporting Services reports in WPF (along with a couple other items). It's a pretty simple implementation, but our architecture is WPF-based, not WinForms. As far as we've been able to tell, there wouldn't be much of a problem were it the other way around, and displaying both types of forms is done the same way.
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.
I have a small project that I will be working on shortly that collects employees time and what project the person was working on. Pretty straight forward. I was orginally going to work on it in WinForms but since im new to that I though maybe using Silverlight for the application since I will have a learning curve for each. Here is a couple of business requirements that i need to incorporate into the application.
-System will use an Access database hosted on a particular persons computer.
-Ability to generate and print reports
-Installed on the emploees desktop who will have access.
Would one technology be recommended over the other in terms of what I need to do. Here is a screen mockup of one of the pages I will need to create.
http://teewebco.com/images/main-copy.png
If you want access to the machine on which the application will run (e.g. to access a database, and to use printing), that pretty much rules out Silverlight, without jumping through a lot of hoops (e.g. having to install something on the user's machine anyway).
You say that WinForms will require a learning curve for you - well you might as well use WPF then, as it's a similar technology from the UI perspective as Silverlight. However, you can proably find a lot more resources online for WinForms though, and it's likely you'd be more productive in WinForms given its strong Visual Studio designer support.
Deployment with WinForms or WPF should be fairly easy with ClickOnce.
Since it's a local (desktop) app which needs to access a local resource (Access database), it's probably better to do winforms.
However, you might be better off doing this as WPF instead - it's more current than winforms.
Winforms and WPF are easier than Silverlight when you have to access a database because you can do it directly. If your install base uses only .net 2.0 then stick with WinForms, if you know they can install .NET 3.5 then try out WPF. Just be warned, there is more to learn with WPF and XAML but it's very rewarding especially if you want to get fancy.
Silverlight 3 lets your application to run on desktop as well.
So I'd write it on silverlight. Yet another technology to master.