Subscribe: Even a chimp can write code
Added By: Feedage Forager Feedage Grade B rated
Language: English
app  application  apps  browser apps  browser  data  install  new  offline  silverlight  support  user  web  windows  xaml 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Even a chimp can write code

Even a chimp can write code

Ideas on software and elsewhere by Ashish Shetty: erstwhile chimp and occasional re-inventor of the wheel.

Last Build Date: Sun, 25 Mar 2018 15:53:15 +0000


High performance UI without compromises

Thu, 15 Mar 2012 18:36:00 +0000

In my last post I left a teaser about more information forthcoming on XAML-DX interop. Wait no more. Jesse Bishop on my team has a post on Combining XAML and DirectX over on the Windows 8 app developer blog.

This feature is especially dear to me. Its one of the handful of things I had in the first deck outlining what the new XAML platform in Windows 8 was going to be. We spent the couple months preceding the release of the Developer Preview working on a brand new graphics stack with independent animation support, and it was only once that was in place that we could expose the niceties of this interop feature set.

Together with our web interop story, surfaced via the WebView control, the XAML-DX interop feature set represents our beliefs that app developers shouldn't have to pick between reuse and new code, nor between high performance and high productivity. Your feedback is appreciated.

Maps and Ads controls for Windows 8 Metro style apps

Mon, 12 Mar 2012 22:06:00 +0000

I wanted to highlight a couple controls that developers authoring Metro style apps will find useful. The Bing team recently announced a beta of their Bing Maps SDK with controls allowing you to integrate maps into your apps. The control targeted at XAML apps is especially neat. It relies on new XAML-DX interop features we added after the Developer Preview, and available in the Consumer Preview of Windows 8. More on that soon. Meanwhile I hope you try out the Maps app in the Consumer Preview to get a good feel for how great rendering performance can be achieved without compromises. The Bing Maps Portal has docs and other assets for your development.

At about the same time, the Microsoft Advertising team announced a beta of their Ads SDK for Windows 8 allowing developers to integrate ads into their apps.

Each is a custom control authored in a way as to provide a familiar programming model to HTML/JavaScript, XAML/C# and XAML/C++ developers alike. This is also a testament to the custom controls story in the XAML platform in Windows 8 and I hope to see others - controls vendors as well as folks with interesting web services - package up their functionality for use by the surge of Windows 8 apps to come.

Windows 8 Consumer Preview

Wed, 29 Feb 2012 16:27:00 +0000

Today the Windows team announced the release of the Windows 8 Consumer Preview, coming on the heels of the Developer Preview we'd released last year. While the next best thing is still a work in progress we hope you will try it out and tell us what you think.

There's also a new Windows developer blog where we can continue our conversation with the developer community.

Thanks to developers worldwide for your interest in Windows 8 thus far, for your feedback and the great apps you are building or planning - and for being true north for the XAML developer platform team and me.

PS: Yes I'm alive. Now you know what I've been up to.

Of Crashing and Sometimes Burning

Thu, 15 Apr 2010 21:41:00 +0000

I don't feel we've narrated the story about error and exception handling in Silverlight very well. We started out in v1.0 with a relatively sucky error reporting and diagnostics story and only did real work in building a robust internal infrastructure and adding diagnostics support incrementally, starting with Silverlight 2. We've since made big strides.Our core tenet is to always provide a robust and reliable operating experience for apps.What conditions can cause crashes?Crashes are rare occurences. Ideally we'd avoid them altogether. They are symptoms of one of the following conditions:A bug in the platformA security mitigation being acted outThe app doing an illegal reentrant callCrashes due to platform bugsThese are rare because few bugs of that severity ever get past our quality gates. This remedy is used within Silverlight only in situations where there's a reasonable chance the platform is in uncertain state and going ahead might be fraught with problems. Within this category, there are two variants: shutting down the app and then the runtime; and tearing down the host process. Of the two variants, the former is the more common approach. It is typical for Silverlight to notify the app via Application.UnhandledException, and most times followed by raising the OnError DOM event for the OBJECT tag prior to shutdown. If you don't see either of these happening, then that might also indicate a bug, and you should report it. In some situations Silverlight may not consider it tenable to continue processing. Instead it takes recourse to a failfast - aka a forceful teardown. Examples include when the internal state machine appears to be corrupt or required data is missing (an ExecutionEngineException thrown but not necessarily).If you think you've found a platform bug that is causing crashes, we'd love to get our hands on a simplified repro app with sources. If the bug does not reproduce reliably, we'd appreciate crash dumps. We will fix most of these issues as and when they're reported.Crashes due to an in-built security mitigationWhen Silverlight detects an Access Violation (aka segfault) or a Stack Overflow, or a Buffer Overflow, the runtime's built-in failfast routines kick in. These are deliberately designed to disallow app code to catch/suppress/rethrow these exceptions, and instead prevent any exploit from taking effect. Doing that would be folly... therein lie known attack vectors. Even in the most benign situations Silverlight assumes past performance is an indicator of future performance (no, we wouldn't be good investors with that mindset!) and finds its extreme action justifiable. We will not "fix" issues in this category.Crashes due to reentrancySilverlight does not deal well with reentrant behavior. Simply put, if Silverlight calls app code in a synchronous callout, it expects the call to be blocking, and it does not expect to be called back via that or another avenue until the blocking call exits. But when it finds itself in this situation, Silverlight will teardown with extreme prejudice, bringing down app, runtime and host (browser) together with a Null AccessViolation. A Null AV is different from a regular AV.Here's how to tell if this is happening to you. The simple way is to look for "Null AccessViolation" in your dump. A more contrived way requires symbols and involves looking at the callstack:KernelBase.dll!DebugBreak() Line 81 Cnpctrl.dll!CWindowsServices::DebugBreak() Line 4270 + 0x8 bytes C++npctrl.dll!DisplayDebugDialog(unsigned int uClass=1, unsigned short * pFileName=0x5ef4ef78, int iLine=64, int iValue=0, unsigned short * pTestString=0x5ef36dec, unsigned short * pMessage=0x037d9a0c) Line 926 C++npctrl.dll!XcpVTrace(unsigned int uClass=1, unsigned short * pFileName=0x5ef4ef78, int iLine=64, int iValue=0, unsigned short * pTestString=0x5ef36dec, unsigned short * pMessageString=0x5ef31e78, void * pVArgs=0x037d9c00) Line 1036 C++npctrl.dll!CWindowsServices::XcpTrace(unsigned int uClas[...]

Four scores!

Thu, 15 Apr 2010 19:28:00 +0000

Silverlight 4 is now live! Here's what's new.

The team is taking a much-deserved couple days off to recharge. Besides, the sun's out in Seattle this week - after what seems like decades.

Can you access a loose XAML file from LoadComponent?

Thu, 15 Apr 2010 19:24:00 +0000

The answer is no. The job of Application.LoadComponent in Silverlight is to “merge” a specified XAML file with a specified object.

public void Application.LoadComponent(object, Uri);

In doing so, it does a series of validations:

  • checks that neither parameter is null
  • checks whether the specified XAML URI is absolute or relative. Absolute URIs are not allowed.
  • checks whether the specified XAML is embedded within an assembly. If not, LoadComponent fails.
  • checks whether the root element declared in the specified XAML is actually the same type as that of the specified object. If not, LoadComponent fails.

and only then attempts to merge the two in a custom parsing step.

Well, why not?

The last bullet point above is consequential in why we don’t allow loose XAML. LoadComponent thinks of an assembly as a logical boundary. In the presence of XAML with contents like this:

the only unambiguous way for Silverlight to identify and locate “Foo” is if it knew the DLL where that type was defined. Iterating through all DLLs loaded in the AppDomain isn’t an optimal solution at all. This is why it insists that the XAML be embedded within a DLL. Then it knows the un-qualified type is defined within that DLL. In practice, the URI specified on the LoadComponent call ends up being something like:


which has metadata on the provenance of said XAML i.e. that it came from an assembly with short name “SomeAssemblyName”. Silverlight can now happily match it against the type backing the other specified parameter – the object.

How does one work around this?

A workaround exists, but it has some limitations. You can use XamlReader.Load() to have Silverlight create an object tree from your specified markup. The caveat being that said XAML cannot have code-behind associations i.e. a backing type as root element, or event handler declarations. This approach is ideal if you’re dealing with sprites that are injected into the app, with other plumbing hooked up programmatically.

Aside: This is part of a recycling bits series I've been considering for a while. I frequently find myself answering the same questions over email or other forums, and figure I'd give some of those FAQs airtime on this blog, so as to multiply any benefits the information might have.

Stepping outside the browser with Silverlight 4

Thu, 18 Mar 2010 23:17:00 +0000

Thanks to all those who attended the talk "CL10 - Stepping outside the browser with Silverlight 4" at the Mix 2010 conference or caught it via the recorded session online. I talked about the evolution of Silverlight into a general purpose development platform, far away from its origins as a browser plugin. I walked through features that light up outside the browser through our deliberate nested doll design approach - both in Silverlight 3 and continuing into Silverlight 4 now. I also talked about trusted apps and emphasized how important getting the right user experience and removing friction from app deployment was to us in the Silverlight team.

Here is the slide deck from the talk. Source code for the basic sandboxed app is archived here; and code for the trusted app can be found here. Hope you find it valuable.

The Q&A session at the end was very useful. I appreciate all the interest in this space and was happy to learn of the apps people were building. We could only get here "with a little help from our friends" in the ecosystem. We can continue that conversation on this blog, or you can send me email (ashsh).

Update: as a postscript, the slide deck I linked to here looks different from the one I used in the talk. Due to "technical difficulties" the podium machine had an older copy of the deck from one of my previous uploads, and I only found out once I was into the talk (silly me for not checking). So if I looked like I crapped a brick at the beginning, now you know why. Live and learn.

Silverlight out-of-browser apps: Remove

Sat, 25 Jul 2009 22:45:00 +0000

Removing a Silverlight out-of-browser app is as easy as installing it was previously. From within the app, just right-click and choose “Remove this application…”.


Just so you don’t wipe away apps by accident, Silverlight will ask you to confirm, and when you do, the app is uninstalled and its binaries are scavenged from the offline application cache.


Data persisted by the app into local data store (Isolated Storage) is not removed. It is still consumable by the in-browser version of the app.

On Mac OS X, dragging the app bundle into the Trash can is another way to remove the app.

In line with our guiding principles which involve keeping the consumer end user firmly in control, keeping it simple and staying out of the way, the Remove experience does not allow the app to programmatically delay, defer or prevent its own uninstall.

Previous posts in this series:

Silverlight out-of-browser apps: How Updates Work

Sat, 11 Jul 2009 02:58:00 +0000

Silverlight makes updating your out-of-browser XAP a breeze. It does the heavy lifting for you, asking that you merely invoke the update logic from within your app at a time or frequency of your choosing, and respond to events raised by Silverlight. If an updated XAP has been published to your web server, Silverlight will download and induct it to the offline application cache. The next time your app is activated, Silverlight will ensure the updated bits are activated and the old bits are scavenged.What the app author needs to doEmploy the async-pattern APIs exposed for updates in your out-of-browser apps. The trigger method is the Application.CheckAndDownloadUpdateAsync() method. Hook up an event handler for the CheckAndDownloadUpdateCompleted event. See, there’s not much to it! No messing with version numbers or the like.Gotchas?Well the only thing to watch out for is the situation when a new version of Silverlight comes out (say v4) and your app is built against it, but the consumer is running an older runtime (say, v3) and an appropriate older version of your app. In this situation, the app update cannot be applied because it requires a runtime update first. Silverlight notifies your app of this situation by setting the event arg’s Error property value to System.PlatformNotSupportedException. All in all, here’s the code you’re going to write:private void SomeMethod(){ Application.Current.CheckAndDownloadUpdateAsync();}private void App_CheckAndDownloadUpdateCompleted(object sender, CheckAndDownloadUpdateCompletedEventArgs e){ if (e.UpdateAvailable) { MessageBox.Show("An update has been downloaded. " + "Restart the application to run the new version."); } else if (e.Error != null && e.Error is PlatformNotSupportedException) { MessageBox.Show("An application update is available, " + "but it requires a new version of Silverlight. " + "Visit the application home page to upgrade."); } else { MessageBox.Show("There is no update available."); }}What the app publisher needs to doIf you handle application deployments or administer web servers, all you need to do is xcopy the new XAP (plus any external content files it needs) in place of the old XAP. Silverlight will take it from there.   In the end, a word to the wise... Make sure you clearly articulate your app's update policy to your end users. Whether you auto-update, or require user-initiation; whether you update upon every app launch or at another discrete frequency; let your app's consumer audience know. Ideally you'd grant them the ability to override your defaults. This is the right thing to do. The user must always be in control. Previous posts in this series:Introducing Offline and Out of Browser support in SilverlightSilverlight out-of-browser support: What kind of apps can you build? Silverlight out-of-browser apps: The Install Silverlight out-of-browser apps: Launch Silverlight out-of-browser apps: Network Awareness Silverlight out-of-browser apps: Local Data Store [...]

Three Years and Three Versions

Fri, 10 Jul 2009 16:58:00 +0000

Silverlight 3 just shipped! 3 is so much bigger than 2; and here's what's new. See Scott's post announcing the release to web (RTW) and outlining the major features. gets a facelift. Goodbye dusk (theme), hello dawn. Be sure to check out the overview of Silverlight 3 there.

Thanks to all of you for your persistent feedback and support in making this such a powerhouse of a release. Keep that feedback coming - we're already working on 4.

More soon...

User-initiated operations in Silverlight

Sat, 09 May 2009 23:32:00 +0000

User-initiated operations in Silverlight:
  1. must be initiated by the user via an input device like keyboard, mouse or accessibility client...
  2. ...within Silverlight
  3. have an in-built timeout
  4. have atomicity of transaction
  5. cannot be marshalled across the specific Silverlight plugin's boundaries

#1 is obvious.

#2 isn't. Silverlight will not honor user-initiated operations that start from an HTML element, have a JavaScript handler which calls into a Silverlight scriptable API or other such endpoint.

#3, the in-built timeout in a user-initiated operation exists to eliminate long running, blocking, iterative, recursive tasks within one user-initiated method call. The timeout value is sort of a magic number, chosen to be small enough to no be a pain point for most developers and their scenarios, and large enough not to compromise on its goals.

#4 indicates that you cannot combine two operations in Silverlight which both require user initation into one transaction.

#5 means that the user-initiated "bit" doesn't traverse the Silverlight plugin boundaries, via IPC calls such as local messaging or even intra-process calls via DOM bridge or Scriptable object features.

These may look like quirks but are actually "features" that exist in Silverlight as secure defaults and to provide consistency of behavior across its supported browser and platform matrix. It is important for every Silverlight designer and developer to understand these nuances.

Silverlight out-of-browser apps: Local Data Store

Tue, 28 Apr 2009 02:03:00 +0000

Silverlight applications – whether in-browser or out-of-browser, and whether running online or offline - can persist data into a local data store referred to as “Isolated Storage”. With the new offline/out-of-browser support in Silverlight 3, the platform further ensures that an app has access to the same Isolated Storage data regardless of whether it was activated in-browser or locally. This way, apps can share data between the in-browser and out of browser versions. As I’d mentioned in a previous post, Silverlight will enforce the provenance URI of the XAP in either case, ensuring that when each queries for its local store, it gets the very same artifact. What can you do with this power? Scenario #0: Local playback sure beats network playback. Scenario #1: Assuming you have consumer use cases that involve using your in-browser and out-of-browser apps interchangeably, you now have a way to share data between them. Scenario #2: If you need to share data between your in-browser app and your newly minted out-of-browser app immediately upon install (detach), you can use this local store as your custom “cookie store”. Scenario #3: If your out-of-browser app detects no network connection, it can still take user input but persist that into local store, to later playback when connectivity is regained.  Internals Silverlight’s Isolated Storage feature provides a virtual file system in which apps can create and store both files and directories with arbitrary data. Apps are abstracted from the lower level file I/O functionality; they do not (need to) know where the files are stored or what sort of internal formats and directory hierarchies are in place. While apps can use file paths and dot-out syntax, these paths cannot escape the bounds of the virtual file system. This sort of virtualization provides isolation of app data, preventing other apps from inadvertently reading from or writing to your app’s store. Hence the term “Isolated” in the name. Apps and app authors do need to recognize that data stored in this persistence store is per-user and per-domain. The Isolated Storage feature in Silverlight persists app data within a directory in the user profile (\%AppData%\LocalLow\Microsoft\Silverlight\is on Windows Vista and up and /Users//Library/Application Support/Microsoft/Silverlight/is on Mac OS X). The AppData folder is a hidden folder. This has the beneficial side effect of hiding your data from from OS search utilities (Windows desktop search and Spotlight) as well as the casual user. This should not be seen as a security boundary – only as a perpetuating the isolation of data. Quotas The space allocated for local data storage in a Silverlight app is bounded by a default quota assigned to that app’s domain of origin. At install (detach) time out-of-browser Silverlight apps will have 25MB space available within the Isolated Storage by default. Contrast this to the default quota of 1MB enjoyed by conventional in-browser Silverlight apps. Needless to say, more space is available to the app upon user consent when the app invokes the System.IO.IsolatedStorage.IsolatedStorageFile.IncreaseQuotaTo() method. That method invocation itself needs to be in response to a user-initiated action such as mouse click or key press. When your out-of-browser app is uninstalled, Silverlight does not reclaim your special quota or erase data persisted there. Encryption Although the isolated storage maintains data in an obscure location, it should not be confused with secure or encrypted data. However apps can easily encrypt and decrypt isolated storage files; they may also sign and validate the signature of an isolated storage file using the SHA256 hash function. Gotchas When saving to a vir[...]

Silverlight out-of-browser apps: Network Awareness

Wed, 22 Apr 2009 23:29:00 +0000

There will be times when your Silverlight app is run but the end user does not have a network connection. A key attribute of making a functional offline Silverlight app is building in network awareness. In this post, we’ll look at how easy Silverlight 3 makes this for you. The API Silverlight provides current network status via the NetworkInterface.GetIsNetworkAvailable() method. Apps can be notified of changes in network availability via the NetworkChange.NetworkAddressChanged event. The NetworkInterface and NetworkChange types are both declared in the System.Net.NetworkInformation namespace. Here’s sample usage of the network detection APIs: ...     NetworkChange.NetworkAddressChanged +=                        new EventHandler (OnNetworkChange); } void OnNetworkChange (object sender, EventArgs e) {     if (NetworkInterface.GetIsNetworkAvailable())     {         nwIndicatorEllipse.Fill =                               new SolidColorBrush(Colors.Green);         // and do something     }     else     {         nwIndicatorEllipse.Fill =                               new SolidColorBrush(Colors.Red);         // and do something else     } } What This Feature Is The NetworkAddressChanged event – as the name suggests - advertises a change in IP address (availability). It is to be used in concert with the NetworkInformation.GetIsNetworkAvailable() to identify whether the recent change resulted in the system obtaining an IP address or losing one. The IP address is seen as a good primordial proxy for availability of network connection or lack thereof. This feature is an answer to the question “Is this is a good time to make an outbound network request?”. Silverlight plays an enabling role in detecting offline status, telling you whether it’s worth your while to make an outbound call, or alternately to cache and persist data locally until network connectivity is regained. What this Feature Isn’t This feature is not an answer to the question “Is my site (or web service) up and running at this moment?”. The way I see it, Silverlight doesn’t play an enabling role in that situation – that is something your app can achieve with 10 lines of code. And such a service indicator is better off taking the actual URI and returning an actual response, rather than being a glorified HTTP HEAD wrapper. Gotchas Say you have 2 adapters – a wireless and wireline Ethernet – both of which are connected. If your wireless connection drops, the NetworkAddressChanged event is raised but in the handler when you query NetworkInformation.GetIsNetworkAvailable(), you still get true because your wireline Ethernet connection is still valid. When that goes down as well, the event is raised yet again and the NetworkInformation.GetIsNetworkAvailable() returns false. Always remember: from your NetworkAddressChanged handler, you must query GetIsNetworkAvailable to definitively find out the connectivity situation. Other gotchas include the “illusion of connectivity”. This happens when you [...]

Silverlight out-of-browser apps: Launch

Wed, 22 Apr 2009 01:13:00 +0000

Silverlight 3 offline/out-of-browser apps maintain a sticky presence on your desktop upon the initial detach (install) operation. They can be looked up and launched in an experience not unlike the one you see with conventional desktop applications. You can search for and find these apps using OS search utilities (Windows desktop search, Spotlight on OS X) where they show up in as Programs.Application idSilverlight uses some indirection from the shortcut to the real app binaries on Windows (however on the Mac, the bundle created on install is the app, with limited metadata squirreled away in the offline application cache). This isn’t because we drink the “architecture astronaut” kool-aid on indirection, rather because doing so in this case allows us to add runtime logic around housekeeping which is effective when updates for the app or runtime exist. If you deconstruct the shortcut to a Silverlight out-of-browser app on Windows, you’ll find a command like this:“C:\Program Files\Microsoft Silverlight\\ sllauncher.exe ” Ignore the newlines above. You’ll notice that the app id is a string made with the union of the domain of origin and some random number/text e.g. During install on Windows, Silverlight creates a directory hive within your user profile so it can store the app binaries along with other metadata. It also assigns the app an identifier which is unique for a specific user on that machine. It appends this id into the shortcut, wherever the app is to be referenced. The app launch sequenceWhen the shortcut is activated, the command is run, and as a result, sllauncher.exe is launched with that app id as argument. The launcher is a container program that chiefly handles the windowing logic for the app, while instantiating and deferring to Silverlight the specific function of loading and running the app. Among the things the launcher controls are the window adornments like icon and title text, a settings such as position. This is just scratching the surface. In future we expect to provide more window customization.When sllauncher.exe hosts Silverlight, the runtime does a reverse lookup of the XAP file using the app id, additionally collects all metadata persisted in the offline application cache and then initializes Silverlight core services to the provenance URI of the XAP. This is the app’s original site of origin, not the location it was loaded off disk. This cascades into the correct (i.e. original) networking and security settings being applied to the app. All fallback lookups for relative URIs get resolved against the right base URI. All policy settings for cross-domain and cross-scheme access get applied properly; and the app has access to the same local persistence store (Isolated Storage) as its in-browser sibling. If not for the ExecutionState data exposed by the Silverlight runtime, the app would “think” it was running within the browser like it did prior to install. If updates to the XAP were successfully downloaded in a previous app launch, Silverlight will scavenge the old bits and use the updated bits instead. It is now ready to launch the app.Was the app locally activated?Upon launch, Silverlight applications can detect whether the current activation was from within a browser, or locally as a standalone window (aka out of browser). This is done by looking at the RunningOffline property of the Application type. When the value is true, the app was locally activated. When false, the app was activated via an OBJECT tag within a web page in the browser.public partial class App : Application {public App () {...this.Startup += this.App_Startup;}void App_Startu[...]

Silverlight out-of-browser apps: The Install

Sun, 12 Apr 2009 19:15:00 +0000

There are three main pillars to the new offline and out-of-browser feature set in Silverlight. These pillars are also tied to user experience; namely Install, Launch and Manage. In additions there are framework-level APIs and behind the scenes support from the runtime for a plethora of things that cross-cut these 3 pillars.  In this post we will look specifically at the Install operation.A Silverlight app needs to be specially crafted for that out-of-browser function. There’s not much to it really: the application manifest (AppManifest.xaml) should be adorned with the OutOfBrowserSettings element which declares such metadata on the app as short name, window title, blurb and icons. No worries, tools make this easy for you via the Silverlight application project properties pane. Silverlight treats the presence of this element as an indication from the app author for opt-in to the out-of-browser feature set. Only this class of apps can be “installed”.The install operation itself can be achieved in one of two ways: via platform UI on the context menu that says “Install {app short name} onto this computer…” via app driven UI which calls the Install() method on the Application typeImplicit in either case is the fact that install is required to be a user-initiated operation. And that too user-initiated within the Silverlight display surface on a web page. This allows us (building the runtime and platform) to better control the user experience and guarantee predictability, security etc.Further, Silverlight apps cannot be installed without the consumer end user specifically consenting to this action. This removes the element of surprise. We’ve tried to maintain consistency with the experience one intuits on a particular operating system, while also balancing the needs of Silverlight app authors and our own user experience goals. As a result, you will see different UX on Windows and Mac – each appealing to its demographic. On Windows, Silverlight shows an application modal dialog like this, seeking the user’s permission to proceed:The dialog is modeled as a confirmation dialog, and the user is asked to allow or deny permission in context, with the assertion “You are installing {app short name} from {domain of origin}”.  The astute reader will notice that the dialogs are similar across Windows and Mac OS X – at least in principle – but each adheres to the native OS theme. The Mac dialog does not seek shortcut preferences, given that Mac users are expected in the very next step to drag the out-of-browser app bundle into a location of their choice, much like they would when installing another application.A dialog of the form above is shown when the app declares no icons of its own. You see the “fallback” icon shown by the runtime.  When the app declares its own brand icon, Silverlight will gladly display it at install time, as the following screenshot of the dialog on Windows attests: If the install were initiated via the Install() method call on the UI thread, the method would synchronously block until the consumer end user made their decision. If they declined, the method returns false; otherwise true. The other install related activities happen asynchronously. The platform signals this to the app via the InstallStateChanged event and the InstallState.Installing state; it inducts the XAP, along with some metadata and housekeeping information into the offline application cache within the user’s profile dir. When this is successfully completed, the platform raises the InstallStateChanged event with the InstallState.Installed state. This is the official notification to the hitherto in-browser app that its out-o[...]

Silverlight out-of-browser support: What kind of apps can you build?

Thu, 02 Apr 2009 02:51:00 +0000

This is first in my series of technical drilldown posts on the new offline and out of browser support in Silverlight 3.

It is something of a tradition in Microsoft to list out scenarios when a new feature set is being conceived. This practice is by no means unique to this company. I feel that doing so establishes a common baseline and taxonomy which immensely helps as the concept matures and gains complexity. Typically these scenarios are fleshed out in functional specifications.

In this post, I summarize the flavors of apps and scenarios that are enabled by the new offline and out of browser support in Silverlight 3. Most of these are self-explanatory and so using another Microsoft tradition, I will stick to concise bullet points rather than prose. A list similar to the one below in fact was used by our crew when we started our planning for this feature set a few months ago:


Fully disconnected app

  • App has no networking needs
  • Reliance on Silverlight just as an installation vehicle for the app
  • We don’t expect this will be very common

Occasionally connected app

  • App is resilient to network outage
  • Conditionally persists data into iso store or cloud based on network availability
  • This is the sweet spot for our feature offerings and where most of our attention goes

Connected app

  • App uses the offline feature set only for the sticky desktop presence
  • We don’t expect this will be very common

User experience

App behaves exactly the same in browser and out

  • App author wants to deliver the same experience in either case
  • “Try before you buy”, “Get more features upon install” and other such progressively enhanced SKU situations
  • Our data suggests consumers find comfort in apps that – in broad brushes – seem similar OOB as when they did in-browser

App shows different UI in-browser and out-of-browser

  • App author wants to exploit the real estate available in standalone window
  • Browser page could have limited functionality which lights up only upon detach
  • Browser page shows only the “Install” badge and the “real” UI only shows up when launched out of browser


Porting an existing Silverlight 2 app to run offline/out-of-browser

  • Even though the feature is a new addition to SL3, some SL2 apps can benefit from it
  • Requires no changes to code and no rebuilds
  • Can be done as a post-production step by modifying the manifest and optionally adding icons into the XAP
  • Build disconnected and connected apps, but not occasionally connected

Building a new offline/out-of-browser app

  • Our mainline scenario
  • Leverage everything the offline/out-of-browser feature set and the rest of Silverlight has to offer
  • Build disconnected, connected and occasionally connected apps

In the next post, we will look at the pillars of this feature, starting with the install (a.k.a detach) operation.

Related posts:

Introducing Offline and Out of Browser support in Silverlight

Wed, 18 Mar 2009 16:39:00 +0000

Today we are making a radical upgrade to your web experience with Silverlight 3’s support for offline and out of browser apps. App authors can now build one app that works in the browser and out; at home, at work or on the go. Among the new set of features enabling this experience are: Sticky presence on the desktop: Upon user consent, a Silverlight app can be detached and pinned on the user’s desktop using familiar OS metaphors for this action. On Windows this can be through Start menu and/or Desktop shortcuts. On the Mac the user can drag and drop the application bundle to a location of their choice. Run outside of browser: activating the app locally launches it outside of the web browser. Our data suggests consumers find this more intuitive as a result of clicking on a desktop shortcut.  Safe by default: Silverlight still retains a rigid security sandbox within which the app operates. Apps cannot elevate beyond the privileges granted by this sandbox. Our philosophy is to stretch this sandbox by providing features within it on a case by case basis. More on this in future. Non-administrative install: Along with the sandbox, Silverlight furthers the consumer’s security by never requiring administrative privileges either for install or for run. An exception may be if optionally a user on the Mac wants to drop the app bundle into a dir that requires sign-on. In that case Silverlight honors the framework set out by the OS and user intuition. Higher default persistence space: the default quota for Isolated Storage for Out of Browser apps is a higher value than for browser based apps. It is currently 25MB. Network awareness: One of the key ingredients of this feature set is the ability for Silverlight apps to be aware of network connectivity and to be notified when that changes. Apps can cache data (or outbound calls) into Isolated Storage and post-back (or playback) when connectivity is regained. This works in Silverlight apps in the browser and out. Built-in auto update: Silverlight will check for new versions of the app asynchronously upon app requesting such a check, guaranteeing users an instant-on experience. Updates are applied at next launch, providing apps complete control over when and how frequently updates are applied with Silverlight doing all the heavy lifting. Execution state notifications to the app: Silverlight notifies the app on momentous events throughout its lifetime and transition from in-browser to out-of-browser, allowing the app to model its UI accordingly. A short note on our philosophy before I end: When my team and I originally started thinking about delivering this feature set, we were absolutely certain about some things. Namely that this would be inherently a part of Silverlight, requiring no new runtimes/frameworks, no additional downloads, no new learning curve for app authors, no security elevations for consumer installs. That is the Carmot, if you will, in our offline and out of browser support. We’re also introducing a user experience that – in my biased opinion – fits well with the rest of the web; a model that allows consumers to try before they install; a model that takes an app familiar to them on the Web and makes it a companion on their desktop. Contrast that a model that requires consumers to have “install intent” and click on a hyperlink or a badge in good faith to experience an app they haven’t hitherto seen. There’s certainly a place for that install model and we’ve supported that in other products in the past for non-Web scenarios. And finally, I’m closely watching where support for offline ap[...]

Search Engine Optimization for Silverlight applications

Tue, 28 Oct 2008 21:32:00 +0000

My whitepaper on Search Engine Optimization for Silverlight is now online:

It provides a story for Silverlight 2 application authors and publishers who want their apps and content to show up in search engine results pages (SERPs) today.

Downloadable copies are here on the MS Download Center:
Word Doc | XPS | PDF

Thanks to Dan Penn, Jon Rooney and Nitya Ravi for all their help in getting this off the ground.

Silverlight 2 RC0: Here's what's new

Fri, 26 Sep 2008 15:38:00 +0000

The Silverlight 2 release candidate build has been released to developers so they can prepare for the upcoming release to web (RTW) of the product, and migrate their Beta 2 applications forward. This build has a number of functional, performance and stability related bug fixes. We’ve had to making some breaking changes along the way. There are also a few new features (which explains the silence on this blog and others like it, over the past few weeks). Here’s an incomplete list:

Per-frame callbacks
Create physics animations or override the animation system by hooking up for the CompositionTarget.Rendering event.

PasswordBox, ComboBox (well, a non-editable dropdown list only for now), MessageBox and ProgressBar.
Updated look and feel for controls.
IsEnabled and IsEnabledChanged added to the Control type.
Exposed virtual On* events on Control e.g. OnGotFocus, OnKeyDown, OnKeyUp, OnMouseEnter etc.

Support for popping up windows
Use the HtmlPage.PopupWindow API, in association with the new AllowHtmlPopupWindow param on the OBJECT tag to open a URI in a new browser window upon a user-initiated action. Note: doesn’t work on Safari because it doesn’t implement the right NPAPI contracts for this.

Improvements in accessibility and UI automation on Silverlight controls.

Support for making HTTP requests on background threads.
Upload support added to WebClient.
Support for percent escaped internationalized URIs for remote endpoints.

A new LostMouseCapture bubbling event for when you lost capture.
Support for global keyboard character input into a TextBox (diacritics, non-ASCII characters etc.)

Extended the kinds of things that can be designated as application or element level resources e.g. Color, FontFamily, TextAlignment and many many more.

Default value support for custom dependency properties via PropertyMetadata.
Support for object element syntax for StaticResource.

With this release, the Silverlight 2 product is feature complete. Absent any major last-minute fire drills, the public surface area (APIs) in this RC should mirror the upcoming RTW product. Thank you for helping us build this product. Your feedback has been our magnetic north. Just a few more days until the ship sails…!

Death, Taxes and Latency

Thu, 24 Jul 2008 03:55:00 +0000

By the time Silverlight came around, the problems afflicting web applications all round were well known and somewhat well understood. The burden of dealing with network latency, cancellation and errors should not be thrust on every web developer. Platforms have a unique role in abstracting away these problems. However, beyond band-aid solutions, web platforms haven’t provided any effective remedies. With Silverlight we’ve tried to tackle these head on. I wouldn’t say we’ve solved them, but we’re a ways ahead than many others out there in recognizing and fixing issues in this space.

Our strategy involves giving fish as well as fishing lessons. Silverlight enforces an asynchronous programming model for just about every latency, cancellation or conflict -afflicted scenario your web app would encounter. We further the mindset that much everything you’re trying to access can be on a remote machine or can take forever to return or can simply fail. This defensive posture is critical. And so whether it is invoking and consuming a web service, or modifying the UI from off-thread, there is an API in Silverlight that does this asynchronously. We go further though. Aside from areas where it simply must be compatible with prior art in Windows Presentation Foundation (WPF), it is de jure for events in Silverlight to be async. As of Beta 2 I can only think of layout events as being synchronous a.k.a. blocking and at least one more I can’t talk about just yet being added in RTW.

The novice developer may encounter a bit of friction in learning how to code to this asynchronous programming model. But there is friction in learning that Ctrl+Alt+Del unlocks a Windows machine, but you master it pretty quickly, and it becomes muscle-memory after a while. Likewise, we hope you will master async coding soon enough and be on your way to building web apps the way they were meant to. You and your app consumers will be the better off for it.

Another axis to this is the provision of tools and user experience options in Silverlight around async coding. This includes the options of using BackgroundWorker, multi-threading, splash screens and other forms of progress indication. Whatever your expertise, there’s an option available for you.

Still another axis is the defensiveness in the platform to counter issues like reentrancy. Silverlight has a reentrancy guard which will throw a Null AV (resulting in a process shutdown) if it detects reentrant behavior such as a draw call from within an existing draw call. You can be sure to catch these things at development time, rather than deal with them at runtime.

Given the ambient environment where Silverlight is hosted and run, the runtime needs to deal with problems such as message pumping and reentrancy arising from STA threads. Besides it doesn’t own its own UI thread – the browser does. Async patterns really shine here. Please tell us how we’re doing in this area. Has the predominantly async model been a hindrance in your development or had you not noticed until you saw this blog post?

Remember, like death and taxes, latency issues afflict all who build apps for the web. Asynchrony fixes one of those.

Pages in Silverlight

Mon, 09 Jun 2008 01:00:00 +0000

Pages as a paradigm likely pre-date the web itself although they have been popularized by document-based markup languages deriving from SGML. Windows Presentation Foundation (WPF) with XAML further codifies Pages as a first-class UI element from its heretofore usage as a logical element. Looking back from Silverlight, this is as good a point in history to start as any. WPF has built-in support for reusable pages in its applications, and the task of navigation between them. It provides the infrastructure for declarative navigation via hyperlinks or programmatic navigation via NavigationService, and a journal that remembers which pages were navigated to or from. For XBAPs on IE7+, WPF supports integration of the journal with the browser's Back and Forward buttons, while elsewhere it displays a substitute navigation bar with this functionality (the limitation is an effect of how the XBAP host plugs into the browser). There is also a building block called PageFunction which introduces a paradigm for invoking pages as if they were methods, providing a neat little way to build wizard UI. Unlike WPF, Silverlight does not support these things, as of version 2. This post isn't about brooding that absence though -- instead we'll look at the lay of the land in Silverlight 2 with regard to pages and navigation, and look at common workarounds.Although Silverlight does not have the Page type at this time, the term is currently used for its root visual UserControl. That root visual object is analogous to the root window in WPF, can only be set once for the lifetime of the app, and is effective once the Application's Startup event is raised. The act of navigating from one page to another is similar in principle to the act of removing one child element from an invisible root and adding another child in its place. [Actually given the journal it is more like switching Z-indices between siblings, so that one gets prominence while the other is made inconspicuous]. You can use this same principle in devising the notion of paging in a Silverlight app.This recipe requires the following ingredients:App.xaml.cs: the code-behind for the ApplicationFrame.cs: a user control which will serve as our "navigation frame". This has no UI.Page1.xaml/Page1.xaml.cs: a user control representing a unique "page". This has a button whose click event navigates away to Page 2.Page2.xaml/Page2.xaml.cs: similar to Page 1 in logic and function, only this represents the second page in your app. Step 1: Create a navigation frameThis is a really simple user control. It has a public Navigate method which is passed a "page" object for which it duly resets its original content. // Contents of Frame.cs public class NavigationFrame : UserControl { // Navigate the frame to the specified content public void Navigate(UIElement content) { // the existing content of this user control is // discarded and the specified param is plugged in // its place this.Content = content; } } // Optional abstraction for page config public static class Pages { // for simplicity we're using static properties, // but this could just as easily be a URI to // Type mapping table public static UserControl HOME_PAGE = new Page1(); public static UserControl ANOTHER_PAGE = new Page2(); } Step 2: Wire up the navigation frame as the app's RootVisualOrdinarily the code generated by Silverlight tools (Visual Studio or Blend) will have a user control h[...]

How to tell a Silverlight assembly from a .NET Framework one?

Sun, 08 Jun 2008 20:41:00 +0000

Silverlight 2 application code is compiled to Common IL and packaged into assemblies (.dll) which are in turn deflated into a Zip file (container with .xap extension). The IL is a CPU- and platform- independent instruction set. The Silverlight runtime has in it the Core CLR which executes this IL. Given that .NET Framework involves much of the same things save for the .xap packaging, how does one tell between a DLL built for Silverlight versus one for .NET Framework?

Well, the answer is in one of the security assumptions that Silverlight's Core CLR makes to distinguish a core platform assembly from a transparent code app assembly. The mscorlib.dll in Silverlight is signed with a different key than it's namesake in .NET Framework. This is apparent in it's full name, or specifically it's public key token.

The public key token for mscorlib in Silverlight is:


while the public key token for mscorlib in .NET Framework is:


So the trick to sniffing out an arbitrary managed code assembly for its allegiance - Silverlight or .NET Framework - is to look through it's list of referenced assemblies, locate mscorlib and then check the public key token. Here is a sample application that does that.

Beta 2 of Silverlight 2 has just shipped

Thu, 05 Jun 2008 16:21:00 +0000

The second beta of Silverlight 2 has just been released. The team has been cranking away and there are some new features and lots of bug fixes to show. A big thanks to all who provided vital feedback on our previous pre-releases!Animation Support for animating custom data points Object Animation support (animating structs) Deep Zoom New XML-based file format MultiScaleTileSource to wire up your own images and get the Deep Zoom experience Better notifications when sub-images enter the view Controls Customize the look and feel of controls using Visual State Manager. Interactive control templates were never so easy. Some base controls are now part of the core platform, rather than packaged into apps. Say hello to smaller app sizes. Calendar now supports multi-selection and blackout dates New TabControlControl properties changes (Background, Tooltip, FontFamily, FontSize…) DataGrid improvements: auto size, reorder, sort, performance and more TextBox IME Level 3 input support Text wrapping and multiline selection highlighting in textbox Scrolling and clipboard support Document level navigation keys Improvements in error handling, reporting Parser and Property system DependencyProperty.Register/RegisterAttached now supports PropertyMetadata New DependencyObject.ClearValue Visual tree helper Data-binding Per binding level validation Support for element syntax for binding markup extensions Binding to attached properties ItemsControl extensibility (OnItemsChanged method) Fallback in value conversion (Binding.UnsetValue) Input Support for limited keyboard input in Full Screen mode (arrow, tab, enter, home, end, pageup/pagedown, space). I've seen more than a few requests for this on the forums. Managed APIs for Inking and stylus input Networking and Data Cross Domain support in Sockets Cross Domain security enhancements HttpWebRequest and WebClient callable from background threads Upload support in WebClient Isolated Storage: default size increased to 1MB and new ability to change quota with user consent. Also a new management UI. Duplex communications ("push" from server to Silverlight client with no need to "poll" for data) LINQ -to- JSON serialization Significantly improved SOAP interop "Add New Item" template in Visual Studio for "Silverlight-enabled WCF Service" ADO.NET Data Services support UIAutomation and Accessibility support in the platform Media Platform support for Adaptive Streaming (also referred to by people as multi bitrate), the ability for Silverlight to switch between media depending on network and CPU conditions Content protection with PlayReady DRM and Windows DRM Basic server-side playlist (SSPL) support Localization Changes to localized application model. You now create one xap per locale, instead of one monolithic multilingual app Expanded localization languages of runtime and SDK Japanese SDK Installer and documentation (July 10) Several changes to make API and behavior more compatible with WPF Tools Beta 1 projects will be automatically ported to Beta 2Remote debugging for VB on the Mac CLR A new developer-oriented runtime package with debugging binaries, localized strings, docs etc. Support for OS fallback logic for resources CurrentCulture and CurrentUICulture isolation to AppDomain level DLR Performance improvements Various new DLR and IronPython 2.0 Beta 2 language features Various new IronRuby features We're not quite done for Silverlight 2, but are getting really close. There's some ongoing work to get more c[...]

WPF 3.5 SP1: Don't let the SP moniker fool you

Wed, 14 May 2008 02:00:00 +0000

Yesterday the WPF team shipped some major horsepower features in the vastly understated preview Service Pack to .NET Framework 3.5. It is an exception to the rule for an SP release to have features, and not just bug fixes. In the mold of Windows XP SP2, this SP of .NET Framework 3.5 is chock full of new WPF features. For the first time the .NET Framework has been divided into a Client profile which - intuitively - does not contain server specific libraries such as ASP.NET. This cuts down the size of the .NET Framework to about 25MB (which as Dr. Sneath reminds us is close to Adobe Reader's size) and people like me with a Java background can associate it loosely with the Java SE and Java EE split. In many ways, this is the realization of the Longhorn-era "WinFX" give-or-take a couple assemblies. Given my previous association with the WPF Application Model, I'll begin with a shout out to improvements from and driven by that crew. The Web Browser control in WPF is embodied by the Frame element. There's new support for interop between WPF and HTML content hosted within it (yay for DOM and script access!). In addition to the existing support for rendering HTML content via URI comes new support for rendering HTML via a stream. This allows for dynamically created HTML content to be rendered in a WPF app. And oh, XBAP enthusiasts will note that this all works in the partial trust sandbox. The progress UI on XBAP launch gets a perf boost and is now an instant-on UI. There's wide ranging real and perceived perf enhancements in the product that customers will truly love. Besides, there are some ClickOnce improvements allowing you to customize the activation error experience, suppress/customize the ClickOnce UI, set up file associations (yes, despite my reservations to this), opting out of signing your apps (I've long maintained that shelling out 300 bucks for a cert is good news for Verisign and gang but bad tidings for hobbyist developers; good to see this change) but with support for corps to block unsigned apps (so this is a wash security-wise). And yeah, ClickOnce-deployed apps can be launched with a click of a hyperlink on Firefox!  An update to Visual Studio 2008 now lets you target your apps specifically to this Client profile of .NET Framework. You have an option of packaging up your app in an installer which will bootstrap .NET Framework 3.5 and uses some nifty tricks (like asynchronous NGEN) to speed up the time between the click and bits showing up on screen. This release contains the graphics features demoed at Mix 08, like extensible shader effects which will let you harness the power of the GPU while still using animation, data-binding, media, composition and other WPF goodness. Fittingly, as has been WPF's charter, these features bring advanced concepts like HLSL effects and SIMD processing to the realm of application developers like me with simple abstractions and none of the complexity (I mean creating an effect is still the realm of experts, but using it is as simple as instantiating a control in WPF which I'm perfectly capable of doing, equating it with something like a DataGrid). Besides, there's deeper DirectX integration so you can blend or overlay D3D content with WPF. There's a new DataGrid and Office Ribbon control provided out of band with WPF. I can go on and on, but I should stop now because I can't hold this smile much longer. The WPF and other partners contribut[...]

Silverlight 2: Layout and Rendering engines

Mon, 14 Apr 2008 22:15:00 +0000

A layout engine which does precise and optimal size or position calculations is critical in any user interface framework for building responsive, interactive and high-performance applications. The term "layout engine" is often interchangeably used with "rendering engine" to mean code that takes markup content along with styles, templates and other formatting instructions to display content on screen. As prominent examples, you know of Trident, the layout engine in Internet Explorer, or Gecko which performs a similar function in Netscape/Mozilla family browsers. In Silverlight, we typically look at the layout and rendering engines as two distinct things rather than one amorphous entity. The former handles the math which dictates how UI elements are sized and positioned on screen, and how they may be constrained or clipped in order to fit into the bounding box. The latter deals with the logic of taking bits representing graphical objects and showing them on screen. Lets do a quick lap around these features. The Silverlight layout engine Among the goals of the layout engine is to: Enable highly complex and dynamic user interfaces where elements can be automatically positioned Provide a gradient of Panel choices in which to place UI elements, as well a mix of knobs to achieve very precise positioning: absolute/relative sizes, margins, padding, static or specified sizes as well as dynamic or calculated sizes Allow app code to participate in layout. This can be as simple as being notified on layout events, or as niche as extending the layout behavior by actively participating in the process With the design patterns and public APIs of the layout engine in Silverlight, we've stayed close to the behavior displayed by Windows Presentation Foundation (WPF), even if the implementation is custom keeping in mind the needs and constraints of Silverlight. Very simply put, layout in WPF or Silverlight is a recursive operation that involves two passes, measurement and arrangement. During measurement, a child element is effectively told by its parent element "Here's how much room is available to all you kids and your 'gear'. Tell me how much you really need." Once all appropriate elements in the tree have been measured in this way, the arrangement pass kicks in. At this time, the elements' sizes are finalized. The parent element can choose to say either "Sure you can have your own room" or if the demands are profligate, then "Oh, the kids these days! I'd like champagne on a beer budget too. But no can do. Get your things together - you and your brother are rooming up." After arrangement, the elements in the tree are ready to be rendered. Example of a grid with constrained size. The rectangle within it asks the parent for all its got -- and gets it:        Example of a stack panel with constrained size. The first rectangle gets what it desires. The second rectangle gets clipped because it desires more than the parent has room for: