Merge Wpf and Silverlight to be one framework (that would be called silverlight??)
Merge both frameworks to use the same assemblies and controls and make a .net silverlight profile that would be a subset of .net client profile and used by partially trusted xaps.
Brian Lagunas commented
@Anonymous, it is extremely easy to share code between WPF and Silverlight. The exact same code.
Suppose .NET code should be able to call each other. Now it is not true, there is no Way WPF calls Silverlight. No easy way to covert project between silverlight Windows phone app and Windows desktop
Matt Dotson commented
It would be fine if WPF was a heavyweight superset of Silverlight, but there's a bunch of stuff in WPF that never gets back ported to WPF. MultiscaleImage, SmoothStreaming, etc. If I have to choose WPF for other reasons, I lose the ability to use rich media.
Microsoft has been misled by HTML5. Their goal should be WPF / Silverlight instead. Combine the two and have native support in Windows without plugins or browsers. Developers would flock to it and give VS / Windows even more of a developer base. There can be only one!
This is really important for Silverlight. Right now it's too restrictive.
Instead of bring HTML5 to the table.
I'm going to be a lot more confused when Windows 8 comes out. There will be a new Silverlight-based app execution model? Both WPF and SL are great, but they should be merged so we don't have to make a decision as to which one to go with.
Chris Mylonas commented
Totally aggre with shimmy. I think its too late to do it.
I also think that difference in the base classes between WPF and Silvelight create a lot of confusion.
Sergey Shandar commented
I think, the question is more for .NET and Silverlight teams. So, I created a feature suggestion also in Silverlight
I would like to have a shared .NET/Silverlight profile to use my libraries for .NET, Silverlight and Windows Phone 7. Currently, even if it is very simple library, you still need to make at least two projects, one for .NET and another one for Silverlight which are share the same code. C/C++ Deja Vu.
Ryan D. Hatch commented
Instead of 3 parallel projects (WPF, Silverlight, WP7). We need Convergence, less Divergence.
Silverlight Core, Silverlight Desktop, Silverlight Mobile.
We need a Common XAML Core, with XAML & code compatibility across platforms. And full hardware acceleration on all platforms. Microsoft, your strategy needs to converge.
I don't think it's a good idea to create one framework. Silverlight should stay as light and fast as possible. Still, try to consolidate programming models. And make SL subset of WPF by implementing all features, that are not present in WPF.
@Michael, I agree with the need, the problem is IT'S TOO LATE, and that's the reason why your request ain't gonna happen. cuz what will happen with all the existing WPF applications??
@Pete - fwiw, we have an application that has 3 target platforms - client/server for "all the time" users (Winforms / WPF), Silverlight for "sometimes" users, handhelds for disconnected users (Winforms). We cross compile as much as possible across all targets. The more code we can write that does not use #if SILVERLIGHT #if WINDOWSCE or separate UI altogether, the less code we have to write / test / maintain - the more we produce - the happier our clients are, etc.
Joel Barsotti commented
I think that Silverlight on the web is getting a bit killed by HTML5.
But the ability to cross platform development is phenomonal. If we could get a more fully featured experience and be able to deploy to mac and linux would be amazing!
Its hard to argue with the need for code re-use. However, SL has the challenge of remaining lightweight (One speaker at the PDC, can't remember whom, mentioned that there is scrutiny given over every kilobyte that the plug-in increases by) as well as cross-platform capability.
I have a project that has gone from Silverlight to WPF, and it was relatively painless. I imagine the other way around could be a bit more difficult if you aren't aware of Silverlight's limitations.
Maybe a good compromise would be some sort of "Silverlight Compatibility Mode" at the project level that would introduce the limitations of Silverlight into WPF if the developer chose to turn that option on. It's not a perfect solution, but it would allow developers to develop compatible assemblies in WPF first if they knew their project would eventually need to work in Silverlight.
Angel Escobedo commented
agree with @Pete, different stories obviously.
@Michael for an example just check it out about IsolatedStorage different ways to access to in, security and others things are not the same on both platforms !
The advantage of integrating WPF and Silverlight into a single framework is that both would be working from a single codeset.
Right now you have the Silverlight team, in essence, emulating WPF. Everytime WPF changes it breaks the existing Silverlight functionality and they have to play catchup to get themselves in sync again.
Having a common UI specification for desktops AND the web is huge.
You can let the actual implementations vary as needed and to allow each product to leverage their strengths, but Microsofts job would be much easier if they didn't have to maintain (and synch) two different codesets...
This is really a request for the Silverlight team more than it is for the WPF team. Currently, replicating the same controls and behaviors in Silverlight takes a LOT more work than in WPF. Please do not vote for this--it's a good idea, but you should really be pressuring the Silverlight team instead.
Jowen Mei commented
It shouldn't be a single framework, simply because there are different targets.
We must avoid creating one framework to rule them all.
I do think both teams should cooperate more. Silverlight must be a subset of WPF;
It amazes me that they come up with new features independently...
In my humble opinion the request is dangerous because wpf and silverlight have conflicting targets
For me the target/focus/requirements of silverlight are:
- Should be a small package that it is easy and fast to install
- Should be supported on a lot of platforms (Windows, Linux, Max, ...)
- Should be supported by a lot of browsers
- Should be supported also on small devices (PDA, Small PCs, ...)
- Focus: Rich WEB applications, secure, without installation.
- Be a competitor to flash
For me the target/focus/requirements of WPF are:
- Installation size not very important
- Provide features to enable developing outstanding desktop applications.
(take best advantages of hardware, windows os, ...)
- Support of integration different technologies like Win32, COM, WinForms, MFC...
- Focus: Create rich DESKTOP application for windows
- With WPF it should be possible to develop very fast with high productivity desktop
applications with outstanding user experience.
Therefore these great applications are running on windows os which is therefore
the best choice for best applications.
- The dekstiop CLR have to take advantage of a tight integration with windows to be fast because .NET it is a stil in a competion with unmanaged languages.
But of course a lot of thinks should be shared/common:
- Using the same XAML parser stack
(which enables common tools for refactoring, designing, ,...)
- Should share a common set of controls
- Design ideas should be the same. Which results in a common application design
- Sharing of assemblies