Fixing the "attempting to access a service in a cross-domain way..." error when consuming a WCF service running via a VS.NET 'localhost' binding

There must be 1000 good blog posts about setting up the clientaccesspolicy.xml and crossdomain.xml files for a WCF service being accessed by a Silverlight application or control. This consists of dropping these files in the root of the site on the server where the site is hosted. But where do these guys go if you are actively running your WCF service locally (through VS.NET) and still want to consume the service?

I recently had my WCF service running through VS.NET so I could consume and debug it through an ASP.NET test harness. This is a really powerful way to iron out any WCF service issues. Upon launching the .aspx page that contained the .xap Silverlight control that had consumed the localhost version of the WCF service running (not a locally installed WCF service to reiterate; just actively running through VS.NET) I began to get the following exception:

"An error occurred while trying to make a request to URI 'http://localhost:6000/MyWCFService.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent."

What - I thought I fixed this a long time ago?? I realized I had never configured the clientaccesspolicy and crossdomain .xml files just for a service running locally. I started plopping those (2) files everywhere: wwwroot, project, etc. I finally found where they should be placed in order for an ASP.NET app containing a Silverlight control that has consumed a locally running WCF service is supposed to go: in the root of the project folder alongside the .svc and .vbproj files. Once I placed the (2) files into that directory containing the raw VS.NET files, the SL control began working properly.

Makes 100% sense too. If running through VS.NET Cassini local server, those files should be located with the actual service itself.

Again, this is only 1 of many, many ways to solve the original issue at hand. This is only a solution for Silverlight controls that consume a locally running (not installed) WCF service. Hopefully this saves someone else a few minutes.