Hi Pete,

I should not be on this list but since nobody replied yet....
I do work with Silverlight mainly but I started recently using WPF for a little basic stock management application. Is really strange to move from windows to wpf because of the different ways things work. But it looks interesting.

I don't really need to use it in what I do but I was thinking on improving my skills.

Well since no one else is answering...

Where I am we have no WPF experience at all but are learning and using Silverlight. For the last five years we've been building (and releasing btw.) a large web-based management application so there isn't a place for WPF.

I also have bene thinking that it would be nice to have a polling feature at silverlight.net to ask this kind of thing. I wonder if one of the moderators could do something about that? :)

-John

I am currently working on a large, rich UI, WPF project, using Prism with a separate tier of WCF based services to feed it data.

In a month or so we are going to try to start porting over our UI to Silverlight and see how things go. We have done a bit of porting in the other direction (porting Pete Blois' SL Virtual Earth control to WPF) I am hoping the port in the other direct is not *more* painful :)

I would love to see some strategies from MS for moving controls back and forth between the two. Or better yet, to build a complex control that shares its app logic between the two presentation APIs. Animations, Commands are key sore spots we know are going to cause us grief.

I'm developing broadly applicable custom controls for Silverlight and WPF using shared source code. I see quite a few reasons to develop this way.

Given the similarity between the two technologies and the effort Microsoft is making to enable targeting both with the same source code, it seems like it would be a waste for me to target only one. So far I'm not seeing any major must-have features in one or the other that make the least common denominator approach too limiting. I look forward to the code re-use possibilities both internally and externally. I see a place for both technologies going into the future, but if one of the two fails or stagnates, my code can continue to lead a happy life on the other one. And I think Silverlight will help increase interest and investment in WPF, both inside and outside of Microsoft. (What about the other way around? Well, that is an interesting thing to consider...)

Currently I leading the development of an enterprise scale WPF application also leading the training effort of Silverlight 2 within the company I work so sharing code across projects is a big deal for me. I try to design a core library that can shared among the two platforms and then when it comes to final part of the UI which will consume the information I use the core. So of the items that are great for a core library are Data Objects and Value Converters. This development will be lasting for a little over a year so I will see how well the shared source works out.

We are sharing large amounts of code between silverlight and wpf.

In my experience so far, you should build the common functionality in silverlight first then bring back to wpf. Trying to take something built in wpf and bring over to silverlight will cause lots of headaches because undoutly some non-existent feature in silverlight will be used. Of course, in most cases, with old wpf code this won't be possible - as was my case and spent many days working around differences and bugs in the silverlight 2 beta 2.

I'm working with WPF for 2 years and started Silverlight since the release of version 2. I have created couple of LineOfBusiness Application with WPF. I was excited when the version 2 of Silverlight released seeing the similarity between WPF and Silverlight. I want to see more WPF features added to Silverlight.
For Example,DockPanel,WrapPanel,ViewBox, 3D support etc.

This is all very cool, guys. I'm not currently working on a cross toolset (WPF/Silverlight) application or set of applications, but it is something I promote to clients as a real value-add.

In the "old days", you had separate skillsets for windows development vs. web development. Those teams tended to be highly specialized and completely separate in many organizations. Web folks specialized in Java/CSS, the windows folks specialized in Windows Forms or other technologies. The programming models were completely different with the only sharing going on behind service facades on the server.

I see us moving towards a day when the two teams can be one (cue "I'd like to buy the world a Coke" happy hippy song *) because WPF on Windows and Silverlight on the web are highly compatible skillsets and toolsets.

The other reason I ask is because I'm considering beefing up WPF content on this site. I've been away from WPF for far too long and am itching to get back into it.

@Lynn, I totally agree that starting with SL is often easier than starting with WPF. Better to add options than remove them.

@Adam that's a great ask. Sounds like a good series right there. (moving controls/code between the two)

@Tom bet you're looking forward to seeing VSM in WPF :)

All of you, I'd love to hear about how these projects are going (good/bad/ugly) over time. Feel free to email me here.

Keep the responses coming!

Pete

* http://www.youtube.com/watch?v=X23MoTtVplE

Pete: Yes, I'm definitely looking forward to seeing VSM in WPF. I heard that it would happen before the next major WPF release, but nothing more specific than that. Hopefully it won't take too long, as I don't particularly like the idea of having to choose between using VSM or supporting WPF. But I still have some research to do on this topic.

Thanks for doing this blog post, by the way. I'm also very interested in the responses here. :)

So far it is just Silverlight for me. I do however, think I will soon regret not having done more WPF specific work. At the very least, I could switch from a console app to a WPF app for those tiny 5 minute one-off "need it right now" utilities I seem to write once a week.