Vince Blasberg's Blog

RIA Services - Solutions to 'The remote server returned an error: NotFound'

Isn't it great when the answers are out there?  I finally got a Google hint and overcame this one.  So here are a few reasons that I encountered and overcame this error.  We can easily reproduce (and often fix) this error.  This occurs on the asynchronous return from a Silverlight 4 to RIA services.  It's as if for any of the few reasons it fails, the call just gets aborted and we get a head-scratching "Not Found".  We can sometimes even hit a debugger breakpoint in the Domain Service that gets the IQueryable call and wonder why the server appears to work in the debugger.

Here are a few suggestions to help.

1. Returning too much data for the object graph.  Solution: Edit the 'maxItemsInObjectGraph' setting in the web.config.
2. Throwing an unhandled error on the service logic.  It can't get back to the client.  Solution: Comment out logic and see if the call succeeds.
3. Solution: Only enable Anonymous authentication.  The request can then avoid authentication errors and possibly return successfully.  This one got me again tonight when deployed a new client’s project for the first time.  It also confused several of us at the Dallas Silverlight and WP7 DevCamp that I mentored at the other day.   The project will work great in the local development server but when deployed to IIS, we get a Not Found error.  So try disabling the Forms and Basic Authentication with only Anonymous enabled.  I'm convinced that this is the most likely reason for most people.

Hope this helps others with this unintuitive error message....Hopefully it's "Now Found".

-Vince

Silverlight OOB - CheckAndDownloadUpdateAsync

I’ve been looking at the Silverlight Out-Of-Browser support and the easy update feature.  In the current version, we’re given the method, CheckAndDownloadUpdateAsync().  This method does a lot for us but is rather limited.  With an asynchronous method and no parameters, what can we expect?  With a huge team in Redmond working for us and trying to meet deadlines, we get what we get.  In the spirit of sharing, here’s what I see so far.

Features:

• Detect network connectivity (and sometimes it fails miserably…)
• Connect to the original authorized URL that it was installed from
• Download the new XAP file and compare the current version against the downloaded version from the manifest
• Detect the current Silverlight version vs. the new version’s Silverlight version
• If a failure occurs, failure exception types are provided for recovery such as “PlatformNotSupportedException”

Limitations:

• Can’t interrupted the request.  So when it times out, we wait for it.
• Can’t download the update and make it optional to install and replace the currently running XAP.  A flag to just detect a newer version would be better.  This would allow the UI to show the current version and available update version.
• Returns a false for the “UpdateAvailable” property for several reasons such as the new XAP is not signed, is a newer Silverlight Version, or various other errors.  We must then look at *ALL* of the possible error class types placed in the error collection.  A bunch of try-catches are therefore necessary.  The try-catches do the job as long as we have every possible error type in a catch.  An enum for the actual error reason may be better.
• Can’t revert to a previous stable version and have it install over a newer bad version.  It makes sense, but real development teams have recovery plans when updating production versions.

Q: What if we want to make the newer XAP file replacement optional?   Here are some thoughts.

Not everyone wants to increase the newer version number for a rollback version.  The Silverlight client can call the web server to get the new version number using other networking connectivity options.  The server call could be as complicated as a WCF service, ASMX service, Web Method call, or an HTTPRequest to get the online version information.  Getting the version from the server could be as complicated as reading the newer version’s manifest file, read the new file date and time, or newer folder date and time.  It could be as simple as getting a text file that has only the expected Silverlight version and the new XAP version.  If the major or minor version is different, then the Silverlight client can act appropriately such as displaying an update message box or button to perform the CheckAndDownloadUpdateAsync() call.  The only issues I can imagine would be security issues of calling back to a “different” server where a ClientAccessPolicy.xml file is required.  If it were HTTPS from the install, the new version check call may to an HTTP.  The different server could also include “WWW” or not include it and therefore require the ClientAccessPolicy.xml file.  The simple version text file can be automatically generated in the Silverlight application build script.  This way DEV, QA, and Production can generate and test it easily without requiring the file to be edited every time it gets deployed.  This may not allow a previous version to replace a new bad version (users install updates with the Silverlight plugin, not our code) but it does get closer so the installed version can stop working or corrupting data until they uninstall and reinstall the previous version.  A rollback with a version increase is easier so we can just call CheckAndDownloadUpdateAsync for the actual rollback.  Again, these are just some thoughts to get closer to real-world deployments.

A Silverlight OOB launcher debugger is available. More information: http://blogs.msdn.com/b/silverlight_sdk/archive/2010/04/10/sllauncher-error-messages.aspx

Q: Needs some good code examples?  A few really good Silverlight OOB blog entries can be found here: http://nerddawg.blogspot.com/search/label/Out-of-browser

This should give some food for thought until we get a more robust CheckAndDownloadUpdateAsync method.

-Vince