Consolidate WPF & Silverlight Programming Models
As a WPF developer, moving to Silverlight has been like learning a whole new platform, and while I realize there are some things I might not be able to do related to network access or security, the fact that simple things like how a ComboBox works is different, has me pulling my hair out. So whether it is databinding, or MVVM support, or controls - allow me to write my code once and then target either WPF or Silverlight.
I am curious as to how many WPF developers have either given up on Silverlight or delayed projects until there is better compatibility with their WPF code and skills.
Making it easier to dual target Silverlight and WPF.
A way to go could be to make it possible to use Silverlight user controls in a WPF application (by referring the Silverlight assembly containing the SL user controls).
Another way to go could be making it possible to use "linked files" in studio in order to link in Silverlight user controls in a WPF app. For this to be possible any valid xaml in SL would have to work in WPF.
We did that for you already. If you use NOV:
you can code once and run on WPF, WinForms, Silverlight and MonoMac from a single code base. No more API changes, API differences etc. Enjoy it.
Please, comme on !!
These should be combined into one technology and the same API:
- Silverlight for Windows Phone
- .NET for Metro Style
For the base controls (Buttons, Textbox, Texblock, Canvas, ... etc.) it should be the same XAML api used.
I like this.
Silverlight and WPF should be combined into one technology and have native support in Windows, without plugins or browsers. Silverlight + WPF = the future of desktop development.
Agree totally, technically there may need to be some differences, but these should be kept to the absolute minimum, there's no reason that the vast majority of Xaml shouldn't be common to both platforms.
I'd like to add that that the various controls (including the toolkit controls which seem to have been largely forgotten) should also be exactly the same where possible.
Honestly, Microsoft can't even maintain a standard internally ....
I would say, I understand that there are technical limits..but the worse interopability between the two platforms is control templating, I still have NO idea why Silverlight does not support Triggers. They allow for the most complex logic to be built into a template without a single line of code...so please guys...can we have some triggers ?
this is a basic demand
Sergey Shandar commented
This is very important, the current MS advice of start with Silverlight and then move to WPF if/when more features are required is broken without this parity. Would be nice to be able to edit a project setting to move from Silverlight to WPF like changing the .Net Framework setting.. Streaming Video, WebCam and DeepZoom parity would be great too.
Mike G commented
I agree... but I think the most impoprtant things for me is this:
If I build a SL DLL with some classes, forms, controls etc... it should be able to be directly referenced from both SL and WPF.
Or if I have SL XAML then I should be able to use it in WPF.
Or if I have a SL form and/or control I should be able to inherit from it in SL and WPF
i.e. SL is a "compatible" subset of WPF with parity in tooling support
I don't think it's realistic to say that a multi-platform technology like SL to have all the features that WPF does. (Sure it could do with more but not all)
very important IMO. I'm very keen on knowing MS's vision for WPF and silverlight. I think MS should offer guidance to developers in choosing the correct platform ;most people including myself are a bit confused
Imran Shaik commented
I hate the fact that when doing perspective transform in Silverlight and porting the application to WPF I have to do more than what I would bargain for? Why not introduce perspective transform in WPF?
Rod Macdonald commented
Delayed and swithered, delayed and delayed ever since the iPad was close to market. The whole wpf vs silverlight vs it doesn't matter what you develop in does our heads in because we all know it really does. And where do things really breakdown? The emerging tablet market for Windows. MS's fix? Pop in a SL control for WPF and let two disparate teams continue to fragment a market. My fix? Stick with WinForms or switch to objective C and get developing for the iPad.
What was really needed was cross Windows device commonality, not cross browser.
I need it
Jeremiah Patterson commented
DeepZoom and SmoothStreaming in WPF!!!!!!! Pleeeasseeee!!!!!!