It's interesting that normal .NET is not affected but ASP.NET is since it uses a different hash function than the one available in the framework.

Also, it is interesting how many platforms are affected as well.

Use Compression

You can reduce network bandwidth requirements by employing a compression scheme, such as gzip. Using compression is even more important when using an XML-based format like Atom. You should consider using compression to reduce the network requirements when you use the OData client for Windows Phone, which only supports the Atom XML format.

Implementation

Enable compression at the server, and make sure it is configured for the MIME type of the response from your service (such as application/json or application/atom xml). For more information, see the post on IIS Compression in Windows Azure. To request a compressed response from the web server, set the Accept-Encoding header in the request to the supported compression scheme, such as gzip. Windows Phone does not currently have its own compression library, so you must use a third-party compression library, such as SharpCompress. The OData library for Windows Phone enables you to set the headers to request compression. It also provides an API to access a compressed response stream and return the decompressed response for the library to materialize into objects. For an example of how to use compression with the OData client for Windows Phone, see the article OData Compression with Windows Phone 7.5 (Mango).

The using Windows Phone on Azure page mentions using SharpCompress for the GZipStream. I guess no one else has bothered compiling the GZipStream into Silverlight/Windows Phone 7 :)

Threading was never so easy since .NET 4 with the TPL has been released. I know I am a bit late but there are so many nice things which might still be new to many of us. The IEnumerable interface has become famous with the introduction of LINQ but many of us have not yet realized that IEnumerable<T> and  T[] or List<T> can be exchanged in many cases but there are cases where it is important to fall back to a pure IEnumerable<T> if you want to support lazy evaluation. .NET 4 has for example taken advantage of the lazy nature of IEnumerable<T> with the introduction of Directory.EnumerateFiles which returns immediately until the first file is found. Previously you had only the option to call Directory.GetFiles which does potentially search for a long time and will only return when all matching files have been found. This can make a big difference if you search recursively in a big file tree or a directory with many files. I had up to 40s delays in some applications which did process a large directory. 40s waiting time until you can process the first file is certainly not something you want. I did solve this issue in .NET 3.5 with DirectorySearcherAsync which did work quite well.

I'm needing to remember this to keep responsive UIs.