Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

Silverlight Connections 2011 Moving from Windows Forms to Silverlight and WPF Presentation

Pete Brown - 04 April 2011

At DevConnections (Silverlight Connections) this year, I gave a short session on moving your applications from Windows Forms to Silverlight.In that session, I covered a little bit of WinForms, a little Entity Framework Code First, and a lot of code shuffling. I did a bit with the Silverlight navigation framework, and even a little bit of Word automation via COM Automation.

I'll be doing a slightly longer version at Tech Ed NA 2011 this year, with an updated demo set. I hope to see you there!

Feel free to use this code/presentation and adapt it for your own needs, for local presentations.

               
posted by Pete Brown on Monday, April 4, 2011
filed under:                

14 comments for “Silverlight Connections 2011 Moving from Windows Forms to Silverlight and WPF Presentation”

  1. Gravatar of Paul StovellReply
    Paul Stovellsays:
    Monday, April 4, 2011 at 9:28:27 PM
    Nice slide deck Pete. I was a little surprised that on the "Rewrite vs. Reuse" chart, Forms and Custom Controls in WPF were ranked as likely to be rewritten. Was that because of the benefits of rewriting, or because customers have had trouble making hybrid solutions work?

    I loved the "career limiting" slide - it's great to see honesty around when to pick technologies.
  2. Gravatar of PeteReply
    Petesays:
    Monday, April 4, 2011 at 9:37:07 PM
    @Paul

    Good point. I covered hybrid solutions a little, but without the airspace fixes in WPF v.next, those tend not to be appealing for many users. The main issues are around drop-down listboxes, and top and context menus.

    If that's not a concern, then control reuse as a migration strategy is pretty good. Not so much as a final reuse solution, though. (IOW, you'll end up rewriting them at some point, but you aren't forced to do so like you are with Silverlight)

    Pete
  3. Gravatar of Mike StrobelReply
    Mike Strobelsays:
    Wednesday, April 6, 2011 at 2:51:47 PM
    I take issue with the suggestion that Silverlight and WPF are on par with each other as far as the potential for reuse of business logic. Considering that Silverlight only supports a subset of the .NET Framework APIs, moving any significant .NET-based application to Silverlight would likely involve rewriting *lot* of code. We briefly considered some internal Silverlight projects a couple years ago, but abandoned the idea when we realized that none of our core libraries could be ported to Silverlight without *massive* rewriting (with many breaking changes).

    I won't bother rehashing my opinion that there is no reason whatsoever to choose Silverlight over WPF for desktop (i.e. out of browser) application development, but to suggest that most WinForms-era business logic and data access(!) could be reused with Silverlight is simply misleading.
  4. Gravatar of PeteReply
    Petesays:
    Wednesday, April 6, 2011 at 3:05:12 PM
    @Mike

    Data access has to be rewritten with Silverlight. I thought I was pretty clear there.

    Straight business logic is often pretty portable, at least in my past experience as a consultant. It only gets messy when that business logic is designed with lots of other dependencies or has too many responsibilities.

    As to Silverlight vs. WPF, I can only go where the customers go. Many customers have chosen SIlverlight, and Microsoft has said that Silverlight (in general) has more momentum. Therefore, I try and help people make the most of it.

    Pete
  5. Gravatar of Mike StrobelReply
    Mike Strobelsays:
    Wednesday, April 6, 2011 at 3:28:18 PM
    A lot of WinForms-era code related to business objects has dependencies on namespaces like System.ComponentModel, which (last I checked) was missing entirely in Silverlight. I can't speak for anyone else, but I know our dynamic (metadata-driven) entities depended heavily on that namespace. There are also many subtle annoyances (various APIs and overloads missing) which are easy enough to adapt to when writing code from scratch, but which create significant work when porting existing code. Even if you're lucky enough to have business logic which can be ported to Silverlight without too much of a headache, it's almost certainly not going to be as smooth as it would have been with WPF (which may not require any changes, as it is part of the full .NET Framework). Your graph suggests equivalent reusability for Silverlight and WPF, which is what I took issue with. I'd bump that Silverlight point up a couple of notches :).

    As for data access, your slides did mention that local databases are an issue in Silverlight, and that there is no ADO access. However, the data points on your "Reuse vs. Rewrite" chart look pretty close together to me (with both leaning towards 'reuse'). I suspect most WinForms apps aren't using EF or RIA services, so there's probably going to be a lot more 'rewriting' going on.
  6. Gravatar of TazReply
    Tazsays:
    Tuesday, April 12, 2011 at 5:31:21 AM
    Pete,

    I'm with Mike on this one, on one hand back at the tail end of 2010 your talking up WPF and saying it's not dead etc etc and here your pretty much saying that in a roundabout fashion.

    The fact is, writing a desktop LOB app in Silverlight as it stands will be very difficult if you want to use a lot of the .NET framework features and we don't want to write something in a browser for desktop apps so if it's out of browser why use Silverlight ?

    The development path coming out of MS is so foggy that following blogs likes yours is the only way to get clues about where MS is going, same story with EF, we ended up using LLBLGen Pro which actually works as an ORM mapper on large databases.

    Does VS2012 use WPF for the IDE front end ?

    We're looking at redeveloping a very large legacy VB6 system, I was brought in to evaluate new technologies, as a long term investment forms didn't make sense and Silverlight doesn't tick all the boxes, WPF seemed to be the only thing out there (from MS) that will do the job and as an early adopter of WPF I know it can deliver good solutions despite its flaws.

    TBH the fog coming from Microsoft makes me utterly fed up with software dev at times (well Microsoft anyway).

    IF Microsoft intend to quietly drop WPF then have the courage to come out and say so instead of changing direction to try and fight Google etc, don't do a LINQ2SQL and drop it for EF which falls short in so many areas (still in 2011).



  8. Gravatar of MichaelReply
    Michaelsays:
    Tuesday, April 12, 2011 at 1:29:52 PM
    I completely agree with Taz. We are looking at redeveloping an existing legacy system and considering WPF, but the general consensus on WPF seems to be;

    - Nobody knows the future direction of the product, including Microsoft.
    - Everyone seems to be scratching their heads and wondering, "what's going on with WPF."
    - Public relations from Microsoft on WPF are basically non-existent, particularly with the development community.
    - Product had initial issues with performance, bugs - some solved with 3.5 and 4.0, many bugs still are not.

    In summary, it seems Windows forms will continue to live on with some future development. With such a large community it's not going anywhere soon. Silverlight is being given all of the immediate attention. And finally, WPF....is left to sit in the corner by itself with an unknown fate.

    Not the kind of gamble any business wants to take.


  9. Gravatar of PeteReply
    Petesays:
    Tuesday, April 12, 2011 at 3:10:20 PM
    Sooo.

    Windows forms developers are going to stick with a technology that we've said is in maintenance mode, no new features?

    So you'd rather use something you know is on the way out rather than use the products I keep telling folks are in active development? They'll simply fall further behind.

    Silverlight is not dead. WPF is not dead. WPF momentum has slowed down due to the maturity of the feature set, the needs of the user base (we're putting in key features and bug fixes) and due to Silverlight's x-plat momentum continuing to pick up.

    However, I wish we'd stop talking about the two as "vs." technologies. It's about XAML and .NET. Yes, there are differences between SL and WPF, but the learning curve is not nearly as high as you might think.

    Building a big app that needs system integration? Use WPF. Building forms over data or other types of apps that fit in Sivlerlight's core capabilities: use Silverlight. Building a web property for the public internet, probably use HTML5.

    - Silverlight 5 is going to beta this week.
    - WPF v.next is under development. It's coming, but we can't release any schedule information.
    - I can't talk about VS v.next or .NET vnext yet. Sorry. We're tied by a number of things that we simply can't pre-announce.
    - Look for more info about this space at the developer conference in September.

    WebMatrix (relative new product) was built using WPF. The Expression tools all use WPF. Visual Studio uses WPF.

    Even if we killed off one of those technologies (which we're not) you have something like 10 years of support after the fact.

    Use XAML. Use .NET. Be Happy :)

    Pete
  10. Gravatar of TazReply
    Tazsays:
    Wednesday, April 13, 2011 at 5:36:18 AM
    Pete,

    Surely you can understand our frustration ?

    You can't say the roadmap from Microsoft is clear, I hear what your saying but take off your MS hat and look at it from a customer perspective, would you have the reassurance to pick these technologies based on the information Microsoft give (very little) ?

    As I said, the only way we can get an insight into Microsoft's direction is to follow your blog or Scott Guthrie and a few others, communication with it's customers is something Microsoft really needs to work on.

    On a side note, I notice your a C64 fan, I spotted you can get a C64 with a PC motherboard and windows installed...seems all wrong to me but it will sell :) I'm sure I have a C64 emulator somewhere, was more a Spectrum and Atari guy myself, learned to program on a 16K Atari, probably explain why my exe's are always small :)

    http://www.dailymail.co.uk/sciencetech/article-1374554/Return-Commodore-64-Classic-80s-home-given-new-lease-life-Windows-PC.html





  12. Gravatar of MichaelReply
    Michaelsays:
    Thursday, April 14, 2011 at 12:58:09 PM
    I agree that Windows forms is on the way out, but when you look at WPF from a practical business perspective (memory usage, cpu usage, performance, real world feasibility) there's very little information on how well it will run as a replacement for forms, particularly in a multi-user environment. For example, QB 2011 written in C#/forms uses 32MB on launch and you can run a 700 page report, using up another 32MB. The two WPF apps I was able to find and test, which are very limited in functionality, used 75MB and 130MB respectively at launch. A 700 page report we ran and tested used a very signficant amount of RAM. So questions such as what happens when you throw 50 users on a network running a WPF app connected to an SQL database, using virtualization/wmware, etc. arise. The decision to adopt WPF would be easy if there was just one single case study or example of a business who has successfully designed a multi-user WPF app and SQL database combination that performs well. If you know of any I'd be very grateful if you could pass that information on!
  13. Gravatar of Scott BarnesReply
    Scott Barnessays:
    Thursday, April 14, 2011 at 8:35:24 PM
    Pete,

    You know i'm a big fan of your work - but..there's always a but when someone says that right? ...trying to get the general population to change the conversation to XAML vs .NET isn't going to work. Trying to convince the general population that "maturity" is the reason why WPF is quiet also isn't going to work. People are a lot smarter than that and me thinks all in the teams need to take a step back from the messaging framework laid before them and start thinking about where this bus leads to next?

    Right now its like we're all in a room and someone farted but we're all trying to keep focus on our conversations around how life would smell better if there were flowers etc nearby...the reality is, we probably need to address the stink in the room and start owning up to who farted......wait..i took a u-turn on that metaphor somewhere...my point is, abstracting it won't work :)

    The only real way out for you guys on this one is to either amplify its existence more - or - come clean and just starting talking about where the bets are being placed...

    Sorry dude :)
  14. Gravatar of TazReply
    Tazsays:
    Friday, April 15, 2011 at 12:27:10 PM
    @Michael

    I do agree.

    Well we're teetering on the edge of the abys of commiting to such an app and Silverlight isn't going to cut it for us so......it's a tough call.

    Forms is proven but management view it as 'old' technology and not a good long term investment.

    I'm a big WPF fan and I think it will be ok but you have to be very careful about how you go about implementing a big app.

Comment on this Post

Remember me