I'd like to answer initially around a broader concern regarding the expectation that the virtual service exposed by the MSE is a 1:1 correlation to whatever implements the service logic... albeit with the exception of the soapAction as has already been discussed.
While this 1:1 correlation may be valid (and even more so for a newly developed 1.0 service implementation), our view is that there should be no expectation of this direct correlation. The virtual service can and will often be exposing
operations from different implementations over different protocols (HTTP, HTTPS, TCP) and message versions (POX, SOAP11, SOAP12, etc). And will use different contracts.... what if the resource the MSE is virtualizing isn't even a web service?
Now more to your question. The developer trying to consume a service should be unaware of whether or not the service is virtual. In the case of the access assemblies you mention, the development of those should leverage "add service
reference" pointing to the virtual service. This assumes there is an MSE instance in place within the development environment. For this scenario it ought to be ok (at least temporarily) to allow the virtual services to expose metadata
(or publish to a UDDI registry where a WSDL can be retrieved from) within the Development environment so that you can create the access assembly as needed (you'd need to do this anyway even without the use of MSE). Once this is performed, there should
be no issue going from development to deployment since the access assembly already has the proper contracts.
As a developer trying to create a service, there would likely be unit tests that hit the service directly, but ultimately it should be imported into the MSE and consumers under development should reference a virtual service that exposes those operations.
Note that this gives the service developer the added flexibility of creating a new service (2.x), importing it into the MSE, and applying a policy to map the original consumer requests(1.x) to the new implementation without those consumers even knowing
about it. Then as consumers reach a convenient development cycle, they can re-generate their development proxies to pull in the new 2.x contracts to benefit from whatever the new functionality is.
I think what is a bit more difficult than it should be is the ability for a developer within a development environment to be able to re-import their service overwriting whatever resource and contracts existed previously... this is akin to going from
Alpha 1 to Alpha 2 where you really don't care about how to transition possible consumers or map the differences between the contracts... this is a seriously breaking change which we try to prevent in the solution but from a pure development perspective causes
the developer to have to do a few extra steps.
Service Virtualization is a key aspect to the MSE that breaks this 1:1 expectation even during the development cycle. Using the MSE only in the final "production" environment is going to be fought with challenges as you have already encountered.
We are interested in more feedback on this and how to improve the developer experience (pre-deployment of a service).