Silverlight 5!

With great fanfare yesterday, a PR/Developer event called Silverlight Firestarter was unleashed upon the world.

Silverlight 5!

Silverlight 5 was announced, and is very good news for those that want to develop enhanced media experiences.  It's also good news for those developing line of business applications.  Boasting over 40 new features. John Papa has detailed many of them on his blog.  I'll touch on just a few of them here...  So grab a soda, ease into your comfortable chair, and lets have a look, shall we?


Media Experiences
So.. let's get the "media experiences" out of the way:

• Hardware Decode and presentation of H.264 improve performance for lower-power devices to render high-definition video using GPU support.
• TrickPlay allows video to be played at different speeds and supports fast-forward and rewind. At up to twice the speed, audio pitch correction allows users to watch videos while preserving a normal audio pitch.
• Improved power awareness prevents the screen saver from being shown while watching video and allows the computer to sleep when video is not active.
• Remote-control support allows users to control media playback.
• Digital rights management advancements allow seamless switching between DRM media sources.

In short, it's the obligatory "this is what Netflix wanted us to put in or risk a move to Flash" portion of the release.  I know that might sound a little harsh, as I'm sure there are other media rich sites out there that are using the playback capabilities of Silverlight.  Outside of Microsoft dog-fooding and Netflix, I can't think of any others off the top of my head.  A bit of a shame though, as these are some pretty powerful video features.  Just a very hard sell against similar components of the cross-platform focussed Flash players.

Personally, I'd like to see someone make a pretty HD cloud-based Dragon's Lair clone that will work on a Netbook without draining your battery after one play-through.  Are you listening Digital Leisure? I think Azure is the one platform you don't have a version of Dragon's Lair for yet. What are you waiting for?


Improved Text Presentation...

• Multicolumn text and linked text container allow text to flow around other elements.
• Tracking/leading set precisely how far apart each character is for full creative control.
• Text clarity is improved with Pixel Snapping.
• Text layout performance is significantly improved.
• OpenType support has been enhanced.
• Support for Postscript vector printing.

So what does this feature set mean?  Maybe PDF support (Or PDF enabling technology. That last bullet point provides a means for doing a sort of WYSIWYG ability)?  Or perhaps it's a precursor to a Silverlight version of the SQL Server Reporting Services report viewer component (which would be no less than awesome).   Or maybe it's a way to allow Silverlight as a deployment platform option for e-book reader developers.  And especially if these features find their way to Windows Phone 7, it would be an easy sell to encourage Barnes and Noble to target Silverlight as their deployment platform for Windows, Mac and WP7 for their Nook e-reader.

Business Applications...

• Model View ViewModel (popularly known as MVVM) pattern improvements.

Personally, I've had a bit of a love-hate relationship with the MVVM pattern in the XAML/WPF world.  Specifically, I've not been a fan of the lack of type-safe compile time warnings when utilizing it.  The XAML approach to MVVM still relies heavily on "reflective" behavior, which means a typo in my field binding is going to more than likely yield a "successful failure".  (i.e. a non-crashing bug that just renders ugly/incorrect  results).  Unless you're a stickler for detail, and an avid tester, you're not always going to catch all of those bugs, especially if changes to a ViewModel are not carefully propagated to it's dependencies.

Well it appears that this is a pain point was a noticeable one at Microsoft.  Silverlight 5 now allows setting break points in the XAML data-binding structures to at least see why binding failures are occurring.  It's not a perfect solution, but it's a good compromise without neutering the power given to the reflective way that MVVM operates on today.

• Support for 64-bit operating systems.

Why is 64-bit important?  Some other bloggers have their opinions as to why.  I believe the key reason for this is related to the final bullet point in the aforementioned link.  "Ability for Silverlight to work together with other 64-bit applications together"

Specifically, the primary motivation for this is the continued Active-X-like features (I have blogged about this direction previously).  Native/unmanaged code interoperability is a tricky thing in mixed environments.  When you are running an x64 version of Windows Vista or 7, you're essentially running two operating systems at the same time.  A 64-bit one, and a 32-bit one.  These two worlds are normally invisible to the end-user for homogeneous applications living on one-side or the other (such as running 32-bit Word alongside 64-bit Internet explorer -- which is a good thing).  And the ability to do this is a fundamental reason why AMD won the 64-bit processor war over the Itanium chipset from Intel (which more or less killed 32-bit compatibility at the binary level)

But when developers have to mix components from both worlds into a single application, things get a little trickier.  Especially if you're a 32-bit application trying to get 64-bit components to execute.  As most Windows installations today are leaning toward x64 installs, having a 64-bit version of Silverlight leaves fewer opportunities for things to go wrong when the COM interoperability aspects are utilized.

And speaking of COM interoperability, it looks like the out-of-browser context gained the ability to P/Invoke unmanaged code.  This means code can be accessed now that doesn't have a COM binding.  This presents opportunity for the creation of Silverlight wrappers for certain binaries.  For instance, future versions of DirectX could theoretically ship with Silverlight SDKs to get to XBox Controllers or Kinect or whatever if you wanted to provide that functionality to Windows specific applications.

It also looks like a mash-up class of applications that sit half way between out of browser and in browser (in terms of security and application permissions) has been put into play here as well.

3D Support! 

Quite possibly the most exciting feature about this release of Silverlight is it's introduction of 3D graphics support.

If you watch Scott Guthrie's keynote (around the 51:00 mark), there's a very impressive "medical" demo detailing a very scary-accurate 3D model of Scott Guthrie himself.  

There was an interesting "layering" feature demonstrated that allowed the presenter to control the opacity of various groups of polygons on Virtual Gu.  The effect was enough to make a TSA body scanning agent envious.

Neat stuff on the surface and it's easy to get excited about features like this.  However, given that Silverlight today now touches 3 specific platforms (not counting Symbian, which is WAY behind), what do the APIs look like between Windows, Mac and Windows Phone 7?

It's probably safe to say that the Windows and Mac APIs look alike.  But Windows Phone 7 already has a 3D API in it's Silverlight interoperability with the XNA framework.

WPF (which seems to be getting phased out more and more as Silverlight gains better display features), has it's version of a 3D API in WPF-3D.  It seems natural that the new 3D capabilities would look similar to either XNA or WPF-3D.

From a portability standpoint, it would be best if it were a convergence of XNA and Silverlight.  This would allow applications (in a slight twist of fate) to port from Windows Phone 7 back to the desktop version of Silverlight.  This would allow developers a path for 3D games to the Mac without splitting their efforts too much.  And as Apple now has an app store, this could be a way of monetizing Silverlight on the Mac platform (provided Apple doesn't have certain regulations in place similar to their iOS line that prevent it).  It would also present opportunities for Silverlight applications to communicate with XBox Live.  How cool would it be to get achievements on a game you're playing on your XBox, Windows Phone, Windows AND Mac? 

I tweeted a question related to this to Pete Brown, Microsoft community program manager for Silverlight, and author of the excellent book "Silverlight In Action":

To which he replied:

Now to be fair, Silverlight 5 is in it's early stages (or at least early enough to not give us a preview binary).  And Pete's answer seems speculative more than definitive, so what he's said here may not be correct or subject to change.  But I think it's a missed opportunity if the API set for 3D is inconsistent across the 3 Silverlight platforms that matter most.  Given the disappointing lack of interest  Microsoft has shown recently to attempt to get Silverlight on more platforms, an effort toward the "code once, run all" originally promised by the framework would be greatly appreciated for the few platforms they DO support.

Silverlight 5 seems to be on track to be a minor leap in some areas and major exciting (and maybe disruptive)  leaps in others.  What was shown was impressive, but (as I mentioned here and others have mentioned here and here), Silverlight's biggest sought after feature by developers continues to be the one they seem the least interested in pursuing:

PDC 2010 Predictions: The future is soon!

Microsoft Professional Developer's Conference starts this week.  Amazingly, this conference sold out only 5 weeks after opening.  Compare this to last year, where I was able to secure a spot there within a couple weeks of it’s first workshop day.

I wasn’t quick enough this year to secure a spot, but for those of you who were lucky enough to get a spot, PDC allows you to participate in a bit of Microsoft history.  PDC and MIX tend to bookend implied direction of Microsoft’s strategy.  Those of you who are like me and unable to make it this year, the PDC website is going to have live streaming.  Hopefully since Steve Ballmer is doing the keynote, we’ll see “Developers!: The sequel”.

It’s always fun to speculate based on the events of the past and news items that have floated around for awhile.  So here are a few things I think we will see this coming week before PDC comes to a close:


The No-brainers
Windows Phone 7 development will be a huge focus, as will Azure.
Heck, this isn’t really so much of a prediction as it’s mostly confirmed by the agenda at the PDC website.  But it will be pushed heavily through the magic of the mind control devices strategically placed in the auditoriums on the Microsoft campus as well as peer pressure from the well respected “who’s who” of the Microsoft development teams.  In all seriousness, these items have been and will be big deals to Microsoft’s future.  So therefore, they will get a lot of attention.

Certain limitations that exist within Azure right now, such as limited ability of customizing the virtualization images in your “spun up” farm drones, will probably be lifted with new announcements around this platform.  Hopefully a new pricing model will be announced as well or some analysis tools to give companies an idea of how much a cloud-based application will cost them.  As it is at the moment, it’s far too easy for an application in the cloud to cost a lot of money unless that application is optimized to minimize it’s dependencies on cloud transactions.

I believe the next version of the Windows Phone 7 operating system and Silverlight/XNA development tools will be announced as well.  Bringing it closer to Silverlight 4, and closing at least some of the criticized gaps in functionality that the launch version of the OS has.  I also predict that these upgrades will go beta for public consumption and testing with the goal of making it available on the handsets in time for WP7’s wider release to carriers that do not rhyme with Bay-Tee and Tee.


The ultimate in swag: Part II
Those that attended last year got the ultimate in swag: A limited edition Acer Aspire 1420P laptop, filled with features that allowed developers to exploit the new snazzy APIs that were revealed in the also announced Silverlight 4.  Continuing in that trend, I predict that developers will receive free phone hardware to assist them in writing Windows Phone 7 applications.  I’d also not be too surprised if attendees were to get a voucher waiving the first year’s $99 fee in the application store.  They do this already for the Dreamspark students, so it doesn’t seem too far-fetched to give the same opportunity to those who take their development efforts seriously enough to pay money to participate in a Microsoft conference.  In other words, if they HAVEN’T thought of this as a give-away.  They really should.  (And this is coming from a guy who won’t be there to reap the benefits of such giveaways)


Silverlight: the new Borg
The next version of Silverlight/Everywhere will be announced for PC and Mac. (Silverlight 5)

WPF will be officially dead (as previously alleged elsewhere).  Although “dead” in this case will just be a synonym to “rebranded” or in Borg-speak "assimilated".

Lately, Silverlight’s true definition is a little fuzzy.  What was originally intended to be a “code once, deploy many” type of framework, has turned into more of a clever marketing buzzword.
 
And in keeping with this trend, “Silverlight for Windows” will be the newest flavor to join the likes of “Silverlight for Windows Phone”, “Silverlight for Symbian”, “Silverlight for Windows Embedded”, and “Silverlight for your toilet” (Okay. Just kidding about that last one, I hope).  The book publisher of “Silverlight for Dummies” may have to change the name of their book to avoid potential confusion for those who may ultimately seek to develop for the “Dummies” platform. (which, in a way, would be somewhat ironic. Insert your iPhone/Android joke here.)

On the other hand, Silverlight 5 may be enough to mark the end of further WPF development.  Like the COM capabilities introduced in Silverlight 4 through the “dynamic” keyword in the new .Net and Silverlight APIs, it’s probably not too far off to allow .Net assemblies a point of entry in a Silverlight application in nearly the same way.  In fact, you can bring in .Net assemblies today by leveraging some COM objects already built into Windows/.Net.  Silverlight just needs a more straightforward way to do it. This gives existing applications that sit a little closer to the .Net metal a migration path, and still allows a common Silverlight codebase.  Of course, this would have to exist under the blanket-centric “elevated trust” model, which has it’s own issues (as I ranted about here).




Silverlight expands 3 Screens and a Cloud.
Three screens and a cloud reveals it’s 3rd screen
Last year, Ray Ozzie evangelized his vision and strategy of leveraging the cloud as a service provider for browser and rich client plugins:

“So, moving forward, again I believe that the world some number of years from now in terms of how we consume IT is really shifting from a machine-centric viewpoint to what we refer to as three screens and a cloud:  the phone, the PC, and the TV ultimately, and how we deliver value to them.”
-Ray Ozzie 

With WP7, Zune, XBox 360, and Windows already able to consume XNA applications, one could argue that XBox 360 was already part of the 3-screen trifecta.  However, XNA’s purpose is nearly exclusive to gaming, doesn’t provide a standard UI for applications, and it’s application focus has not been one for consuming cloud content.  This doesn’t fulfill the true vision of applications AND games being represented on the three screens.

Rumors have been circulating for awhile that the Xbox 360 Dashboard’s 2010 update this fall (which I believe will be shortly after PDC) will have the “Indie games” area renamed to “Xbox Live Apps”.  XBox Live’s new dashboard looks to be heavily influenced by the Metro design standards.  And such a rename would imply that XBox would be the conduit to the television “screen” for more than game applications. It just seems more than a coincidence.

So, I suspect “Silverlight for XBox”, coupled with a renaming of the Indie portal on XBox Live will be the defining moment of the third missing screen in Mr. Ozzie’s vision and strategy.  This will be monetized the same way the Indie game developers and WP7 developers are charged now:  As development partners for the app store.


The PC screen gets bigger… (or rather, deeper)
Some time ago, Microsoft’s Silverlight team announced a collaboration to bring Silverlight to the Linux based open source Moblin operating system destined for their Atom-based netbooks.

There was even a live demonstration of Silverlight 3 in action on a Moblin netbook given at an Intel convention by (then) Microsoft General Manager Ian Ellison-Taylor (who recently resigned from Microsoft as well).

In parallel, Nokia was working on a similar mobile open source operating system called Maemo.

Recognizing similar philosophies and goals of targeting mobile and netbook devices, Nokia and Intel merged the projects and it became Meego.  This new hybrid project has basically been a mash up of the best features, and strengths on the two systems.

So where does Silverlight fit into all of this?  I posed that very question at the Meego forums, presenting all the evidence and questions around Silverlight’s implementation on the Moblin OS.  The result was a couple of friendly responses from community members.  But neither Nokia nor Intel’s people have commented.  In the course of 2 months, my post gathered over 800 views, which I think implies some interest for Silverlight on this platform.  And such popularity deserves a comment by someone “in the know”… unless they are forbidden to prior to official announcements.

A few changes at Nokia as a company point to this platform being a new home for Silverlight as well:

A former Microsoft President, Mr. Stephen Elop is now CEO of Nokia.  In announcing Mr. Elop’s departure from Microsoft, Steve Ballmer casually mentioned a continuation of a working relationship with him at Nokia.

Of course, this could mean something simply in the realm of a manufacturing agreement for Windows Phone 7 hardware.  Or it could mean that “Silverlight for Symbian” will be getting an upgrade sometime soon.

However, it’s been mentioned that Meego may be the operating system of choice on Nokia smart phones in the future.  And recent news implies that the Symbian foundation itself is facing a little bit of trouble.

So that really leaves Meego to be the platform successor for “Silverlight for Symbian”.


Moonlight
Just like last year, I expect the free software version of Silverlight (Moonlight) to be given an ultra quiet nod as well.  I suspect that Moonlight 3 will finally be released out of it’s preview state to either a beta or production release.  I would also expect to see the “Ahead of Time”/N-Gen compiling option getting added to Moonlight sometime in the future to give Silverlight an equivalent deployment strategy to iPhone as Adobe currently provides with Flash/Air. 




What we won’t see…
Silverlight for Android handsets
So what will NOT be making an appearance at PDC?  I highly doubt we will see anything resembling “Silverlight for Android Phone” outside of anything that the Mono/Moonlight team at Novell may have brewing.  Why? Such an announcement would take the wind out of the sales (ha, get it?) of Windows Phone 7.

While Microsoft has not denied any work in the area of Android, the timing for this is not correct (at least on the smartphone/ARM version.  More on this in a minute)

Best bet would be some announcement at MIX11 if there’s a strategy in place to monetize application deployment similarly to WP7 without hurting WP7 momentum.  And even then, I doubt support will be a priority if only out of respect for their partnership with Nokia/Symbian/Meego.

Silverlight for iPhone
Big surprise?

The long shot: The app store bandwagon
I know this might seem WAY out there, but if you were at PDC last year, eBay was given some airtime during the keynote to tout their “App store” to allow Silverlight 4 developers to monetize their development efforts.

I suspect we will see a similar product announced as an agreement between Microsoft and Intel.
Intel’s AppUp developer sales portal is already live, and it’s very possible that it’s going to be heavily promoted through their OEMs on all Intel devices in the near future.

AppUp currently supports .Net applications for Windows, Moblin has an SDK, but I imagine that’s just going to remain there until the Meego SDK is announced (which will probably also work with the Moblin deployments out there that just won’t go away).  Silverlight support has also been noted on the roadmap.
If this is true, Miguel de Icaza's Windows App Store idea might actually take some shape here, even if not specifically managed by Microsoft themselves.

So what’s in it for Microsoft?  If a partnership is in place here (and there is suspicion that one already is based on this little "top-secret" exchange), it means plenty of opportunity for monetization.  Monetization in the form of some sort of profit sharing agreement, perhaps.  Or, Azure could simply be providing the hosting for the applications.  Hosting costs as well as download “transactions” equate to dollars (or rather, many, many cents) in Azure’s typical billing agreement.  This means that “cross platform” platform strategies such as Silverlight existing outside of the Windows eco system widens the audience and revenue stream for these downloads.

This also figures into Mr. Ozzie’s strategy.  Let’s not forget that Silverlight applications, regardless of the platform it runs from, is a good catalyst for cloud transactions from within the applications themselves.  And as Microsoft knows, money that doesn’t originate from an application running on Windows is just as green as one running from Meego... (or a tablet based Android)

Android support without disrupting WP7?
Intel has been working on an Android tablet running on the Atom processor.

One of the things that many people do not realize about Android is that while it is an “open” operating system, there are a few key closed applications that Google reserves for their licensed handset partners.

One such item is their App Store browsing application.  This is a very important application currently.  However, if Intel has it’s own app store, and has it’s own application for browsing it, I don’t imagine it’s too far fetched to allow Android applications to exist on AppUp as well and offer this to OEMs as a free/subsidizing alternative to Google’s store.

And if the only applications that exist on this store are Android netbook applications running on a version of Silverlight for x86 Android, this doesn’t necessarily interfere with Windows Phone 7 since the Android handsets run on the ARM/Snapdragon processors.  In fact, the netbook version of Meego’s Silverlight (if it exists) probably ports to the x86 version of Android with little effort due to their common Linux roots.




Politics…
In conclusion, its worth noting that Ray Ozzie has not been mentioned as a keynote speaker this year.  Clearly this is due to his recent announcement to leave the company.
So who should succeed Mr. Ozzie?

PDC is a great place to make this announcement if it’s someone that Microsoft KNOWS that the development community will approve of and get behind.  If anything, Microsoft knows how to market to it’s developers.

So.. will the next chief software architect hire be a Jobsian move, and bring Bill Gates back?  I doubt it.  If an announcement is made at all, I’m personally betting on the red shirt.


To all of you attending PDC this year, have a good time!  I can attest that 2009’s was one of the best events I’ve ever attended.  Be sure to wave on the web cast.  I’ll be looking for you.

A brief history of Silverlight and a few cautions for the newbies...

This is a small history of Silverlight.  Based on my experience, it would have been nice to know what I was getting myself into before I embarked upon this technology.  Not that it's been a decision of regret.  However it wasn't nearly as smooth for me as it was implied it should have been.  Perhaps my expectations were too high or out of line, or perhaps my skills were just deficient.  At any rate, here's a brief overview and some words of wisdom for those of you new to the technology:

In the beginning... there was WPF...  
The origins of Silverlight rest on the coat-tails of a technology Microsoft invented on the Windows platform called WPF (which stands for Windows Presentation Foundation).  The basis of this technology is a mark-up language called XAML.  Basically, the idea here is that UI is expressed in an HTML/XML mashup.  The XAML reader within the WPF framework converts this tree of nodes into text, pictures, drop down lists, etc and renders them on screen as such. Basically this mark-up is a specification/recipe of how to render the visuals to your screen.  Microsoft has viewed this as a sort of Microsoft version of HTML (though some would argue it shares more resemblance to SVG).  And as such, there are strategies that allow this to exist on the web as well as in desktop applications.

The goal of this was to provide a GUI application platform alternative to the mess that is AJAX and the dinosaur that is Windows Forms.  With Apple having a very rich and friendly design environment in Cocoa, this was a huge step forward to creating a flexible platform for designing UI in Windows.  The key concept of WPF's flexibility is the notion of a "behavior" model or "non-graphic" implementation of various control elements.  From WPF's design philosophy, what a control does or can do is far more important than what it looks like.  For instance, a "Button" is basically defined as a group of behaviors and events associated with what a Button can do and how you interact with it.  You can click it, you label it with content in some form, you can hover over it, and so forth.  But whether the button is silver, round, or shaped like a cashew doesn't take away from the fact that it needs to carry one or more of those behaviors to be considered a "Button".

Microsoft provides default "skins" to the various controls (including the Button).  However, nearly every aspect of the controls beyond that can have their own custom skin provided by the developer.  Borrowing heavily from the concepts of cascading style sheets (CSS) in HTML markup, the re-skinning of the various elements can occur at various levels:  from the control's own definition, to the application (which affects every control) with similar rules of overriding the behavior.

Also like HTML, the notion of event handling is accomplished through code.  While HTML/AJAX accomplishes this with Javascript, WPF accomplishes this with code from syntaxes compatible with .Net (such as C# or VB.Net)

By the nature of using an abstract mark-up language like XAML, the implementation is very portable between the desktop and web versions.  However,  WPF has a complete dependency on the .Net framework.  Which (unless you count the Mono project) is a technology exclusive to the Windows OS.  Consequently, WPF has just been viewed as a fancier version of ActiveX by most.  And just like ActiveX, you're not going to see WPF content on a Mac or Linux.

Enter WPF/E Silverlight
With the proof of concept for deploying WPF content to a browser essentially proven, the next step was to see if this could be forked off into a solution that was not only cross-browser compatible, but cross-platform. So, the first prototype of this was called WPF/E (WPF/Everywhere).  "Everywhere" at the time was considered the Mac and Windows platform.

Basically the concepts are and were the same as WPF.  UI is expressed in XAML mark-up (with WPF XAML mark-up nearly 100% compatible with WPF/E's version).  It was given it's own version/runtime of the .Net framework (which eliminated a lot of implementation redundancy and Windows specific APIs).  And as a result, given it's own development environment and deployment strategy in the form of a browser plug-in not too dissimilar to Adobe's Flash.

At release, WPF/E was dropped in favor of the term coined today:  "Silverlight".  Through a collaborative effort between Novell and Microsoft, an open source free software foundation-ish implementation has been created called Moonlight.  This is intended to target the Linux platforms.

Development Gotcha's...
This is where all the marketing and hype get put into perspective.  Before you get working on Silverlight, there are some things and certain mindsets you need to get accustomed to.  I know that if I had this knowledge, it would have made things a whole lot less painful.

1. Silverlight is it's own thing.
   One of the most common misconceptions about Silverlight is that it is part of the standard .Net ecosystem.  This is simply not true. (Or not entirely true) While it certainly shares the same design and development philosophies and IDE, the only thing it really has in common is the syntax's supported by it.  Assemblies (DLLs) compiled in the standard .Net framework are not designed to be compatible in Silverlight, nor are Silverlight assemblies designed for compatibility with standard .Net.  Outside of certain unit test hacks, Visual Studio will generally forbid you from attempting to cross pollinate like this.
   
   Remember that Silverlight's .Net runtime is a much smaller subset of the "real" .Net framework, with pattern redundancies reduced and Windows-specific APIs removed or abstracted to fit a context suitable for cross-platform implementations.  As of this writing, both Windows/.Net and Silverlight contain APIs specific to their deployment platforms, which makes forcing this compatibility even more of a challenge.
   
   As long as you remember that you're basically targeting another framework that simply has C# in common with it and a few libraries that just happen to look like standard .Net libraries, you're on the right track.
   
   I should note that Silverlight 4.0 has tried to address some of this weirdness by allowing some .Net class libraries to exist in Silverlight 4.  However, this only works if your .Net class library's external library references are limited to a few common references between .Net and Silverlight's equivalent library sets.  Basically, the purpose of sharing assemblies here are for lightweight value objects and common algorithms that aren't doing a whole lot and don't require a lot of dependencies on a lot of .Net libraries on either side of the coin.
   
   
2. Silverlight is designed for the browser first and foremost.
   Since version 3 of Silverlight, the concept of an "out of browser" application has been introduced.  However, it should be noted that (at least on the desktop versions of Silverlight), even out of browser applications need to originate from a web-page.  In these scenarios, your webpage acts as the "setup.exe" boot strapper to the installation process.  Users can right click and choose to install the application from the Silverlight plug-in directly.  Or, if you want to build a mandatory or custom install experience, there are APIs built into the Silverlight-specific libraries to handle that.  In that scenario, your application contains the installer logic in addition to it's primary functions.  This is significantly different than the installer deployment packages created with the .Net framework such as msi's or ClickOnce.
   
   As Silverlight is designed for the browser, communications with the hosting server (or any other web service) are only allowed asynchronously.  This is intended to prevent a Silverlight application from locking up a browser while it waits for results.  Remember that Silverlight's access to the outside world rests on what the browser allows and provides.  This interface is a published standard, and how it's implemented from browser to browser is largely up to the browser's development team.  This asynchronous way of doing things is to ensure a consistent experience for service calls.  It should also be noted that this communication occurs only when Silverlight's engine has control.
   
   A side effect of this is that you generally want UI elements to change based on what you get back from a service call.  You have to do this in the call-back event handler you specify on the web service call.  This essentially makes you split your UI logic up amongst one or more methods that have little knowledge of one another.  For example, a click event on a button could trigger a web service call.  But you can't fill in text boxes based on the results of that event until the web service's asynchronous callback has been fired.
   
   
3. Rendering occurs as RETAINED (or once per frame)
   When dealing with graphics, and especially when targetting OpenGL or DirectX, it's important to understand the difference between rendering modes.  There are basically two main flavors:  Immediate Mode and Retained Mode.
   
   Immediate mode rendering is similar to the way you're doing in Windows Forms.  Basically, every instruction you give that modifies the display in some way occurs IMMEDIATELY.  Traditionally, what this has meant in the Windows Forms realm is that you introduce an inefficient effect called "over draw".  Basically what this means is, your program can end up triggering events and processes that force the display to repeated update and display portions of the screen.  Sometimes this is desirable.  In other cases you end up re-painting over the same part of the screen over and over again until it resembles the final state that the user see's.  Often times this generates artifacts on the screen, or simply introduces lag time and unresponsiveness until all of those unnecessary draw operations have completed.
   
   In Silverlight, nothing is rendered until control is given back to the Silverlight engine.  This is called "Retained" mode.  The concept here is that the screen's display element hierarchy is scanned once for changes and rendered once to reflect those changes.  
   
   What this means is that setting a checkbox control to checked in an event handler will not actually perform anything on the visual until your call stack has emptied out and control returns to the Silverlight engine.  Setting properties that affect visuals at this point are merely providing a specification to the renderer when it scans through the objects that make up your display.  This makes for efficient rendering, but it doesn't give you accurate access to any properties that are changed as the result of a render.
   
   So in a way, Silverlight has a rendering lifecycle closer to ASP.Net than Windows Forms.  Except the lifecycle completes several times a second and doesn't require any communication back to the server to figure out what the page looks like.
   
   
4. Silverlight IS the application.  Your program is merely a parameter passed to it.
   Okay.. I know that sounds a little harsh.  But consider that none of the heavy system level lifting ever occurs until the Silverlight runtime retains control (i.e. your program's call-stack empties itself out).  This is true of rendering, and also true of any service calls out to the internet or hosting server.  
   With very few exceptions (pardon the pun as that's one of the cases), methods, classes and properties that interact directly with the Silverlight runtime act like a checklist for the engine to follow rather than performing any particular action directly.  Calling methods to perform a web service simply queues up the request.  That's right. It's true!  If you call a web service that only takes a second and then force a wait delay in your code for five seconds, you will find that the request never even fires until your method returns control back to Silverlight.  So if you prefer synchronous calls, you're out of luck.  As I just mentioned, you can't even add delays to block code while you're waiting for the call back.
   
   Also, as mentioned above in #3, the UI renders in a retained rendering pattern, and basically follows this same process for the visuals.

So if you are embarking on Silverlight for the first time, beware of these items. Peripheral understanding of how the runtime operates helps quite a bit before you waste time trying to implement patterns or APIs that fight the way Silverlight processes things.  Silverlight will always win in those fights, so it's good to know how to develop around the way the runtime prefers to execute.