Of Crashing and Sometimes Burning

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:

1. A bug in the platform
2. A security mitigation being acted out
3. The app doing an illegal reentrant call

Crashes due to platform bugs
These 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 mitigation
When 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 reentrancy
Silverlight 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             C
npctrl.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 uClass=1, unsigned short * pFilename=0x5ef4ef78, int iLine=64, int iValue=0, unsigned short * pTestString=0x5ef36dec, unsigned short * pMessageString=0x5ef31e78, ...)  Line 7258     C++
npctrl.dll!CReentrancyGuard::CheckReentrancy(int bNullAvOnReentrancy=1)  Line 64 + 0x36 bytes              C++
npctrl.dll!CXcpDispatcher::OnReentrancyProtectedWindowMessage(HWND__ * hwnd=0x004b039a, unsigned int msg=1026, unsigned int wParam=0, long lParam=0)  Line 900 + 0xa bytes  C++
npctrl.dll!CXcpDispatcher::WindowProc(HWND__ * hwnd=0x004b039a, unsigned int msg=1026, unsigned int wParam=0, long lParam=0)  Line 807 + 0x18 bytes    C++
user32.dll!_InternalCallWinProc@20()  Line 106         Asm
user32.dll!UserCallWinProcCheckWow(_ACTIVATION_CONTEXT * pActCtx=0x00000000, long (HWND__ *, unsigned int, unsigned int, long)* pfn=0x5f10bc90, HWND__ * hwnd=0x004b039a, _WM_VALUE msg=1026, unsigned int wParam=0, long lParam=0, void * pww=0x00e267f8, int fEnableLiteHooks=1)  Line 163 + 0x12 bytes         C
user32.dll!DispatchMessageWorker(tagMSG * pmsg=0x5f10bc90, int fAnsi=0)  Line 2591 + 0x1e bytes        C
user32.dll!DispatchMessageW(const tagMSG * lpMsg=0x037d9dec)  Line 999     C
user32.dll!DialogBox2(HWND__ * hwnd=0x002902ac, HWND__ * hwndOwner=0x000b0924, int fDisabled=0, int fOwnerIsActiveWindow=0)  Line 1150           C
user32.dll!InternalDialogBox(void * hModule=0x760b0000, DLGTEMPLATE * lpdt=0x04923388, HWND__ * hwndOwner=0x000708fe, int (HWND__ *, unsigned int, unsigned int, long)* pfnDialog=0x7611eec8, long lParam=58564704, unsigned int fSCDLGFlags=0)  Line 1314 + 0x9 bytes           C
user32.dll!SoftModalMessageBox(_MSGBOXDATA * lpmb=0x00000030)  Line 1237 + 0x18 bytes  C
user32.dll!MessageBoxWorker(_MSGBOXDATA * pMsgBoxParams=0x037da060)  Line 791             C
user32.dll!MessageBoxIndirectW(const tagMSGBOXPARAMSW * lpmbp=0x037da0d4)  Line 528 + 0xe bytes              C
ieframe.dll!6132ecd5()      

The presence of CReentrancyGuard::CheckReentrancy indicates the reentrancy guard; message 1026 indicates WM_INTERNAL_TICK the veritable sign of the apocalypse reentrancy; and the presence of a (non-Silverlight, in this case from NTUser) MessageBox at the bottom indicates an actor that pumps messages including Silverlight messages. Note that Silverlight's own MessageBox will not cause this reentrancy - it and the reentrancy guard were specifically designed to play well with each other. So I recommend using that any place you'd consider using an alert.

Now consider that SizeChanged and LayoutUpdated events are raised synchronously as part of a layout pass. (I've previously expressed my firm preference for all things async -- I'd have loved for these events to be async but lost that argument since it'd have broken WPF compat and eliminated a couple scenarios. But I digress.) Now if you were to use the DOM Bridge within a SizeChanged event handler to, say, do an alert(), that'd align all the stars. The alert would pump messages; Silverlight would be in a blocking call, not expecting any messages in its internal queue; its little "reentrancy guard" would see this as reentrant behavior, and initiate adverse action terminating with a Null AV.

Silverlight's behavior in this situation was intended to be moral equivalent of a shock collar. We wanted app authors to detect these situations at development time and fix their code, so it never shipped with reentrant behavior.

This condition is the most common cause for crashes in Silverlight, and is indicative of programming error in the app.

We're constantly evaluating whether this sort of positive reinforcement through operant conditioning actually works. If you have anecdotes or feedback, please drop a line. Bear in mind that we have done a poor job at advertising this behavior, and I do sincerely apologize. So the fact that it took you a good while longer than average to debug such an issue is unfortunate but explained away by that.

Where to look for crash dumps?
While developing apps on Windows, with Windows Error Reporting (Watson) you should see the path in the UI shown upon a crash. Alternately look under %Temp% for dirs with "WER" prefix, and look for a .mdmp file prefixed by process name. If this is an out of browser app, you should see "sllauncher.exe.mdmp" instead of one for the browser's executable.

Further reading

With the context from this post, I hope you will see the MSDN doc on Silverlight Error Handling in new light. Some of that content originated from my original spec on the topic written circa Silverlight 2. It will help you understand control flow. In addition, this topic page will help you understand how best to handle exceptions in your own Silverlight app code.

A word on diagnostics

If we could rewrite the past and change something, we'd have tweaked our initial conditions to one that enforced error reporting best practices in our internal development of the runtime. This would have eliminated having to perform triage and surgery on a rapidly evolving runtime as we added better diagnostics. There are still too many E_FAILs in our code that bubble up and result in the totally unhelpful "Unknown error" and the wildly melodramatic "Catastrophic error". There's a bit of dark humor in the backstory, but that's for another time.

Our work is not done though. We continue to seek feedback from app authors and fix our oversights. Keeping Silverlight easy to develop against is a giant priority for our team. Making sure you have great diagnostics and get past issues fast is one way we can make that happen.

Email this | Bookmark this

Four scores!

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

• End users can get it here: microsoft.com/GetSilverlight
  
• App authors can get the runtime and tools here: silverlight.net/GetStarted
  
• Developer docs for Silverlight are on MSDN

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.

Email this | Bookmark this

Can you access a loose XAML file from LoadComponent?

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:

<UserControl x:Class=”Foo”> …

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:

/SomeAssemblyName;component/Page.xaml

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.

Email this | Bookmark this

Stepping outside the browser with Silverlight 4

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.

Email this | Bookmark this

Silverlight out-of-browser apps: Remove

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:

• Introducing Offline and Out of Browser support in Silverlight
• The kinds of apps you can build
• Install
• Launch
• Network Awareness
• Local Data Store
• Updates

Email this | Bookmark this

Silverlight out-of-browser apps: How Updates Work

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 do

Employ 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 do

If 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 Silverlight
• Silverlight 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

Email this | Bookmark this

Three Years and Three Versions

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.

Microsoft.com/silverlight 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...

Email this | Bookmark this

User-initiated operations in Silverlight

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.

Email this | Bookmark this

Silverlight out-of-browser apps: Local Data Store

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/<user>/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 virtual file system, one needs to be aware of inherent limits on file path size. This is imposed on you because the Isolated Storage’s root dir itself occupies several characters in the path (151 on Vista/Win7, 183 on XP/2K, 160 on OS X) effectively leaving you only the remainder (109, 77 and 100) respectively for your own file and directory names before Silverlight’s limit of 260 chars for a file path is hit.

Saving files outside of Isolated Storage

Silverlight 3 allows for saving files outside of isolated storage. Saving to any location on the client-side file system requires user initiation and the use of the SaveFileDialog control - a new “safe” control which allows saving one file at a time via a stream with your app code not having access to the file system or structure. Saving data to the server via an HTTP postback is another option.

----

This was #6 in my ongoing series of posts on Silverlight’s new offline and out of browser support. Hope it is helping you gear up.

Previous posts in this series:

• Introducing Offline and Out of Browser support in Silverlight
• Silverlight 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 

Related links:

• Isolated Storage documentation
• Isolated Storage API reference
• MSDN magazine article : Isolated Storage in Silverlight 2 

Email this | Bookmark this

Silverlight out-of-browser apps: Network Awareness

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 have some connectivity (say you’re on a WiFi network in an airport or a coffee shop) but not any Internet connectivity until you sign in or pay up. Your app may see GetIsNetworkAvailable return true, but should still try that actual outbound request to ascertain this.

In some cases virtual machines (e.g. Hyper-V running on your Windows Server or running Windows with Parallels on your Mac) may interfere with this feature and your app may see false positives.

---

Previous posts in this series:

• Introducing Offline and Out of Browser support in Silverlight
• Silverlight out-of-browser support: What kind of apps can you build?
• Silverlight out-of-browser apps: The Install
• Silverlight out-of-browser apps: Launch

Related links:

• Peter Smith’s “Offline network detection in Silverlight” talk from Mix 09
• Code patterns for Online/Offline Network Detection

Email this | Bookmark this

Silverlight out-of-browser apps: Launch

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 id

Silverlight 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\<version>\
                                    sllauncher.exe <app id>” 

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. www.mysite.com.3509. 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 sequence

When 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_Startup(object sender, StartupEventArgs e)

{

     if (Application.Current.IsRunningOutOfBrowser)

{

this.RootVisual = new OutOfBrowserPage();

}

else

{

this.RootVisual = new PageToBeDisplayedInBrowser();

}

}

}

Note: we’re changing API names to better reflect behavior; so expect the code snippet to change with Silverlight 3 RTW, but the principles will more or less remain true.

In the next post we will look at network awareness in offline/out-of-browser Silverlight apps. See you then.

Previous posts in this series:

• Introducing Offline and Out of Browser support in Silverlight
• Silverlight out-of-browser support: What kind of apps can you build?
• Silverlight out-of-browser apps: The Install

[Update 10-Jul-09]: Code snippets updated for Silverlight 3 RTW.

Email this | Bookmark this

Silverlight out-of-browser apps: The Install

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 type

Implicit 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-of-browser copy has been installed. The out-of-browser app gets a higher default quota (25MB to the previous 1MB) within Isolated Storage for its local data persistence needs. The in-browser and out-of-browser apps share this Isolated Storage with each other. We’re not yet sure if the magic number of 25MB is the right one (or if there is in fact any right value); it is however orders of magnitude higher than the default for in-browser apps and we hope it will open up new scenarios and result in the proverbial 80% of our apps not having to ask the consumer user for a quota increase yet again.

Upon successful install, Silverlight auto-launches the newly installed app – all sandboxed, out of the browser, and ready to go! The salient points of this Install operation are:

• keep it lightweight
• showcase the app brand, not the technology powering it
• keep the decision simple for the consumer, and in context
• get the consumer to their desired goal in the shortest time possible i.e. launch the app upon install

More about the story behind the Launch experience in the next post. Until then, cheerio, toodle-ooh and all that.

Related posts:

• Introducing Offline and Out of Browser support in Silverlight
• Silverlight out-of-browser support: What kind of apps can you build?

[Update 10-Jul-09] API names updated to reflect Silverlight 3 RTW

Email this | Bookmark this

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

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:

Connectedness

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

Approach

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

Email this | Bookmark this

Introducing Offline and Out of Browser support in Silverlight

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 applications in HTML5 goes and how mainstream browsers adopt it. At some point I do want our model to co-exist with the experiences they introduce.

Developers can evaluate and play with the Silverlight 3 Beta build these apps using Silverlight 3 right now. There's great runtime and tools support.

In future posts, I will be introducing this feature set from a technical perspective.

Post script: You can now understand why there’s been radio silence on this blog for months. This feature took a lot of Mountain Dew, sweat and tiers from a couple handful of the best darned engineers in the world. And a lot of questions, comments, critiques and feedback from the best darned customers a product can have. Here’s to takeoff and the EAP!

[Update 10-Jul-09] Auto-update section modified based on changes post beta; now reflective of Silverlight 3 RTW behavior
[Update 25-Jul-09] Links updated to Silverlight 3 RTW

Email this | Bookmark this

Search Engine Optimization for Silverlight applications

My whitepaper on Search Engine Optimization for Silverlight is now online: http://silverlight.net/learn/whitepapers/seo.aspx

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.

Email this | Bookmark this

Silverlight 2 RC0: Here's what's new

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.

Controls
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.

Accessibility
Improvements in accessibility and UI automation on Silverlight controls.

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

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

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

XAML
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…!

Email this | Bookmark this

Death, Taxes and Latency

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.

Email this | Bookmark this

Pages in Silverlight

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 Application


• Frame.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 frame

This 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 RootVisual

Ordinarily the code generated by Silverlight tools (Visual Studio or Blend) will have a user control hooked up as Application.RootVisual within the Startup event handler. You will change this to hook up the navigation frame. Then hook up the user control to be the navigation frame's content (by invoking the NavigationFrame.Navigate method you created above).

// Contents of App.xaml.cs
// the Startup event handler sets the root visual
private void App_Startup(object sender, StartupEventArgs e)
{
    // Navigate to home page
    Navigate(Pages.HOME_PAGE);
} 
public void Navigate(UIElement content)
{
    // Create frame on an as-needed basis
    if (this.frame == null)
    {
        this.frame = new NavigationFrame();
        this.RootVisual = this.frame;
    } 
    // Navigate to content
    this.frame.Navigate(content); 
} 
 

Step 3: Build your pages

Now that the navigation infrastructure is ready, go ahead and create a couple pages. These are merely user controls which would otherwise have been hooked up directly as the RootVisual. That part is simple. An important attribute in this equation is the fact that pages need to provide the experience of "navigating away". You can use a hyperlink, a button, or trap mouse/key events. We'll use a button and insert the navigation logic in it's click event handler.

// Contents of Page1.xaml.cs 
// on btn click, this navigates to the second page
private void navigateButton_Click(object sender,
                                  RoutedEventArgs e)
{
     (Application.Current as App).Navigate(Pages.ANOTHER_PAGE);
}
 
 

Let's create another user control which will be navigated to.

// Contents of Page2.xaml.cs 
// on btn click, this navigates to the first page
private void navigateButton_Click(object sender,
                                  RoutedEventArgs e)
{
     (Application.Current as App).Navigate(Pages.HOME_PAGE);
}
 
 

Well, that's all there is to it really. Build and run, and you've got your simple little navigation application.

In this pattern, the navigation frame element:

• is the equivalent of the implicit navigation control


• is a container with no visible visual properties (e.g. Background, etc.)


• has only a Content element representing the current page

In the pattern, the page element:

• is the equivalent of the navigable Page


• has visuals or contains visual elements


• can be attached and detached from the tree on a navigate event (i.e. the current element is removed, and a new one added in its place)

Our example used the Navigate By Object approach. Note that we invoked the Navigate method and passed it a page object. You could tweak the logic so your pages can be given data as part of the Navigate call. You could just as easily add URI-to-type mapping into the Pages utility type. That would allow you to replicate the Navigate By URI approach which is more organic to content on the web. If you use the Navigate By Object approach and you have a journal that maintains a back/forward stack of pages you've previously navigated to, you can incur a working set hit. This is because your journal will retain references the page objects in memory for long intervals - usually the life of the app - preventing the garbage collector from reclaiming them. Using the Navigate By URI approach in such situations can offer better use of memory. This is because you can delay instantiation of page objects until when the Navigate needs to happen.

In closing, there is a good case for pages, navigation service, journalling, transition animations, deep linking etc. to be part of the Silverlight platform. This is certainly of interest to us as we look toward the next version of the runtime and it's framework. I'd like your thoughts and feedback on these features and how important they are to your scenarios.

Further reading:

• Navigation overview in WPF


• Page, Hyperlink and NavigationService


• Jesse Liberty: Multi-page applications in Silverlight


• Dave Relyea: Navigation with Transition Effects

PS: For Ben. Sorry this has been long overdue.

PPS: Thanks to Michael Weinhardt for valuable insights.

Update [06/16/2008]: Dave has a new post on navigation with transition effects. Link under the Further Reading section above.

Email this | Bookmark this

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

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:

7cec85d7bea7798e

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

b77a5c561934e089

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.

Email this | Bookmark this

Beta 2 of Silverlight 2 has just shipped

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
  1. Support for animating custom data points
  2. Object Animation support (animating structs)
• Deep Zoom
  1. New XML-based file format
  2. MultiScaleTileSource to wire up your own images and get the Deep Zoom experience
  3. Better notifications when sub-images enter the view
• Controls
  1. Customize the look and feel of controls using Visual State Manager. Interactive control templates were never so easy.
  2. Some base controls are now part of the core platform, rather than packaged into apps. Say hello to smaller app sizes.
  3. Calendar now supports multi-selection and blackout dates
  4. New TabControl
  5. Control properties changes (Background, Tooltip, FontFamily, FontSize…)
  6. DataGrid improvements: auto size, reorder, sort, performance and more
• TextBox
  1. IME Level 3 input support
  2. Text wrapping and multiline selection highlighting in textbox
  3. Scrolling and clipboard support
  4. Document level navigation keys
• Improvements in error handling, reporting
• Parser and Property system
  1. DependencyProperty.Register/RegisterAttached now supports PropertyMetadata
  2. New DependencyObject.ClearValue
  3. Visual tree helper
• Data-binding
  1. Per binding level validation
  2. Support for element syntax for binding markup extensions
  3. Binding to attached properties
  4. ItemsControl extensibility (OnItemsChanged method)
  5. Fallback in value conversion (Binding.UnsetValue)
• Input
  1. 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.
  2. Managed APIs for Inking and stylus input
• Networking and Data
  1. Cross Domain support in Sockets
  2. Cross Domain security enhancements
  3. HttpWebRequest and WebClient callable from background threads
  4. Upload support in WebClient
  5. Isolated Storage: default size increased to 1MB and new ability to change quota with user consent. Also a new management UI.
  6. Duplex communications ("push" from server to Silverlight client with no need to "poll" for data)
  7. LINQ -to- JSON serialization
  8. Significantly improved SOAP interop
  9. "Add New Item" template in Visual Studio for "Silverlight-enabled WCF Service"
  10. ADO.NET Data Services support
• UIAutomation and Accessibility support in the platform
• Media
  1. 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
  2. Content protection with PlayReady DRM and Windows DRM
  3. Basic server-side playlist (SSPL) support
• Localization
  1. Changes to localized application model. You now create one xap per locale, instead of one monolithic multilingual app
  2. Expanded localization languages of runtime and SDK
  3. Japanese SDK Installer and documentation (July 10)
• Several changes to make API and behavior more compatible with WPF
• Tools
  1. Beta 1 projects will be automatically ported to Beta 2
  2. Remote debugging for VB on the Mac
• CLR
  1. A new developer-oriented runtime package with debugging binaries, localized strings, docs etc.
  2. Support for OS fallback logic for resources
  3. CurrentCulture and CurrentUICulture isolation to AppDomain level
• DLR
  1. Performance improvements
  2. Various new DLR and IronPython 2.0 Beta 2 language features
  3. 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 controls delivered (Scott has said the expectation was to ship over 100 controls) at and beyond RTW. I know people have asked for ComboBox and PasswordBox. We'll also have per-frame callback support (CompositionTarget.Rendering event) to light up those physics animation scenarios you're dreaming of, and further accessibility work on controls, improvements to PNG support in imaging, among other things. Needless to say, the focus from here on will be to stabilize and ship a solid product.

I hope you like what we've cooked. Please keep that feedback coming. Without you this would not be possible and be quite meaningless.

Further content:

• Get Silverlight 2 Beta 2 now!
• Breaking changes between Silverlight 2 Beta 1 and Beta 2
• Install Beta 2 tools for Visual Studio 2008
• Silverlight 2 Beta 2 documentation on MSDN
• Scott Guthrie: Silverlight 2 Beta 2 released

Email this | Bookmark this