On second thought

I've corrected only the Silverlight aspects, because that's what I know. People with significant knowledge of Flash are welcome to contribute corrections and updates.

If you put a web service in the host web for your Silverlight application and discover it then when you create the reference the URI is obtained from the debug web server. You can configure this with the ServiceReferences.ClientConfig file but you have to do so prior to building the XAP file.

To change things after the fact, you can rename the XAP to ZIP, extract the ServiceReference.ClientConfig file, edit it, update the ZIP file and rename it back to XAP. Tedious but possible with tools intrinsic to Windows.

Another option is to rewrite the binding address after you instantiate the service client. Here’s a sample from one of my XAML code-behind files.

This code exploits the habit Silverlight applications have of putting a # between the end of the application base URI and the name of the XAML page; the last slash before the hash marks the end of the base URI.

None of this is remotely difficult. What I want to know is why the generated service client doesn’t detect service URIs that begin with “http://localhost:” and perform this simple fix-up automatically.

The world is not waiting on EF directly handling spatial data types. You don’t need them.

Just use Lat and Lng columns typed as float, and set up a trigger so that whenever the Lat column is updated the trigger updates the Geography column.

Most data sinks use separate latitude and longitude values, so you have to handle them like this anyway. The trigger keeps the geography column in synch so stored procedures can use spatial indexes.

Sure you can’t use a spatial index directly in a Linq expression, but you couldn’t anyway because that would entail L2E carting all the rows to the client. To avoid this we always end up writing stored procedures and using a web service to call them, and this is where you munge coordinates into the right form for spatial indexing.

So, the absence of spatial types from EF is not now and never has been a problem.

If the EF team wants to do something useful they could figure out the Linq to Entities Guid join problem. For those fortunate enough not to have encountered this bug, L2E doesn’t like comparing Guids with parameters. It can’t figure out how to compare Guid with object, because object uses reference comparison but Guid uses value comparison.

The generated proxy in Silverlight works properly, probably because by the time the data reaches the Silverlight client you’re probably actually using Linq to Objects, which doesn’t manifest the problem.

In my opinion this is a much higher priority. Guids are very frequently used as primary keys, and therefore also as foreign keys. Guid comparison is extremely common, and L2E is completely broken in this very common scenario.