I think you should look at Silverlight as a long-term play, just as Microsoft seems to be doing. There's an obvious balance on when to use Silverlight vs. Flash when you're concerned about reach and install base, but here are some reasons Silverlight is a good direction to move in:
Second mover advantage - Just as Microsoft built a "better Java" with .NET, they're able to look at how you'd design a RIA plugin from scratch, today. They have the advantage of knowing how people use the web today, something the inventors of Flash could never have accurately guessed. Flash can add features, but they can't realistically chuck the platform and start over.
Developer familiarity - While Silverlight is a new model, it's not entirely unfamiliar to developers. They'll "get" the way Silverlight works a lot more quickly than they'll understand firing up a new development environment with a new scripting language and new event paradigms.
Being rid of the timeline model in Flash - Flash was originally built for keyframe based animations, and while there are ways to abstract this away, it's at the core of how Flash works. Silverlight ditches that for an application-centric model.
ScottGu - ScottGu is fired up about Silverlight. Nuff said.
Cool new features - While Silverlight still has some catching up to do with Flash on some obvious features (like webcam / mic integration, or 3d / graphics acceleration), there are some slick new technologies built in to Silverlight - Deep Zoom is one example. I'm seeing more "revolutionary" technologies on the Silverlight side, while Flash seems to be in maintenance mode at this point.
Here is a trick you could use.
- Make sure your Silverlight Views and View Models are isolated within their own assembly that is easily referenceable by your WPF application.
- Add a reference to the Silverlight class library that houses the Views & View Models in the WPF application.
Move the contents of the UserControl, "CustomerView" into a DataTemplate housed in a resource dictionary called "customerViewTemplate"
Inside your root UI element XAML files in Silverlight and WPF do this:
<ContentControl ContentTemplate="{Staticresource customerViewTemplate}" />
- In the Silverlight application's App.xaml make sure to add the following Resource Dictionary reference to the merged dictionaries.
<ResourceDictionary Source="MyApp.Views;component/CustomerViewResources.xaml" />
- In the WPF application's App.xaml make sure to add the following resource dictionary reference to the merged dictionaries.
<ResourceDictionary Source="pack://application:,,,/MyApp.Views;component/CustomerViewResources.xaml" />
Sorry about the numbering, looks like Stack Overflow's ordered list mechanism is a little off.
The reason why this works is because you can't directly reference a Silverlight UserControl from XAML within WPF. It will give you the following error:
'Cannot resolve dependency to assembly
'System.Windows, Version=2.0.5.0,
Culture=neutral,
PublicKeyToken=7cec85d7bea7798e'
because it has not been preloaded.
When using the ReflectionOnly APIs,
dependent assemblies must be
pre-loaded or loaded on demand through
the ReflectionOnlyAssemblyResolve
event.
If you try to force the UserControl onto a WPF Grid using C# you will get the following 3 errors:
The best overloaded method match for
'System.Windows.Controls.UIElementCollection.Add(System.Windows.UIElement)' has some invalid arguments.
The type
'System.Windows.Controls.UserControl'
is defined in an assembly that is not
referenced. You must add a reference
to assembly 'System.Windows,
Version=2.0.5.0, Culture=neutral,
PublicKeyToken=7cec85d7bea7798e'
cannot convert from
'ToWpfTest.Views.TestView' to
'System.Windows.UIElement'
I gather this is because the System.Windows.UIElement in WPF is not the same as the System.Windows.UIElement in Silverlight.
Best Answer
Should you learn ASP.NET or Winforms first? ASP or MFC? HTML or VB? C# or VB?
Set aside the idea that there is a logical progression through what has become a highly complex interwoven set of technologies, and take a step back and ask yourself a series of questions:
The next and hardest step is to come to accept that any advice you are given is bound to be wrong; and the longer the time horizon the more likely it is to be incorrect. If the advice is for more than six to 12 months, the probability the advice is wildly incorrect approaches 1.
I can only tell you my story, quickly. In 2000 I was happy as a consultant working profitably in C++ on Windows applications, writing about ASP.NET and WinForms. then I saw C# and the world turned upside down. I never went back.
Two years ago I had the same kind of revelation, only an order of magnitude bigger, stronger and with more conviction about Silverlight. Yes, WPF is magnificent, and it may be that I'm all wet about this, but I believe in my gut that Silverlight changes everything. There was no doubt then and there is no doubt today that Silverlight is the most important development platform for Microsoft since .NET (certainly) and possibly since the switch to C++.
In a nutshell, here is why. I don't understand where its limitations are. With most platforms I do: you can do this, but you can't do that. WPF is a pretty good case in point, as was ASP.Net and WinForms and, well really everything until now.
With Silverlight, I don't see the boundaries yet. Silverlight has already leaped off the desktop onto phones, and I don't see any reason for it to stop there. Yes, it is true, it is bound by the browser, but I see that less as a jail cell than as a tank in which Silverlight will be riding over lots of terrain (it must be very late, I should go to bed).
In any case, for now, learning Silverlight is a gas, there is a lot of material on the Silverlight.net site, and what is the very best thing about learning Silverlight is that if you don't see what you need you can holler at me and I'll make sure you get it pretty quickly.
Enjoy, good luck and the dirty little secret is you'll be fine whichever you choose. It's all just software.
-jesse
Jesse Liberty "Silverlight Geek"