Silverlight 4 CAS restrictions (loadFromResourcesSwitch)

A whole morning wasted on this one..

I've been upgrading a bunch of silverlight stuff to version 4, which should be straight forward, except that I had included some third party controls in the projects.

Now whenever I try to build the project, VS2010 came back with the less than helpful error:

The "ValidateXaml" task failed unexpectedly...
System.IO.FileLoadException: Could not load file or An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go2.microsoft.com/fwlink/?LinkId=131738 for more information.

Problem? Well apart from something new to have to fix, the files concerned are not being loaded from a remote source: they are all referenced libraries on my local machine, with Copy Local settings.

Which led to three questions:

a) where exactly does this mythical switch go?
b) why does Microsoft think this is a remote file?
c) why is Microsoft once again insistent on breaking everything by treating everyone as idiots?

According to the knowledge base, the way to fix is to add a switch to the config file for the project.

<runtime >
<loadfromresourcesswitch enabled="true" >
</runtime >

Small problem here - Silverlight projects don't have a config file. I added the switch to the config file for the web application hosting it, but to no avail. I still can't build the project in the first place.

The Solution.

After a whole morning of hitting my head against a brick wall, I found the solution. The files are local, but these were custom controls originally downloaded from the vendors website. Which means that Windows had marked them as remote files (adding the 'Mark of the Web' to the file). That mark remains for ever, unless you explicitly Unlock the files using the Properties tab in Windows Explorer.

So the .NET runtime was confused into thinking they were remote files.

So I hope this helps someone else.

Now to fix the other stuff that the upgrade has broken - like all the service references..