4

I have a class library named WebAccounts.dll that calls some (of my own) WCF web services. I have the web services project automatically build a client version of its data contracts for consumption by its .net clients. It builds both a .net 3.5 and 4.0 version. So I have:

OMWebServices.dll
OMWebServices.ClientDataContracts35.dll
OMWebServices.ClientDataContracts.dll (.net 4.0 version)

As part of a new website we are building, I've upgraded WebAccounts.dll from .net 3.5 to 4.5. So I also updated it's ClientDataContracts reference from the 3.5 version, to the 4.0 version just because it could now use it.

Now when WebAccounts tries to call a service method, I get a MethodAccessException:

Attempt by method 'WebAccounts.Data.Franchise..ctor(System.String, IdentifierType)' to access method 'WebAccounts.OMConfigService.ConfigurationServiceClient.GetFranchise(System.String, OMWebServices.DataContracts.FranchiseIDType, Boolean)' failed.

If I change back to ClientDataContracts35, it works successfully. It is bewildering that changing my data contract assembly version affects whether or not my code can access the generated proxy method (which is not in the ClientDataContacts assembly, and is public).

I've stumbled onto this Question, which says that you can add <xmlSerializer useLegacySerializerGeneration="true"/> to the web.config to fix some kind of .net 4.5 serialization compatibility issue. I gave it a shot and it fixes it when using the 4.0 ClientDataContracts. But why?

One last twist is if I skip using WebAccounts in my website project and just add a service reference and call the same service directly, it works even with the 4.0 ClientDataContracts without needing to add the useLegacySerializerGeneration configuration. So using ClientDataContracts (4.0), the website can call the web service directly, but calling WebAccounts which calls the same web service gets the exception. I've also verified WebAccounts gets the exception when called from a test project to rule out anything specific to the website project.

Can anyone explain what's going on here?

Community
  • 1
  • 1
xr280xr
  • 12,621
  • 7
  • 81
  • 125

1 Answers1

0

In .NET Framework v4.5, XMLSerializer default implementation had been changed to dynamic code generation. The main benefit of this dynamic code generation approach is that it doesn’t require access to hard drive, which is one of the features that customers asked. However, its limitation is that it can’t access non-public members from other assemblies. This is why you see the MethodAccessException in some cases. For customers, who don’t need this dynamic code generation feature, can still use v4.0 serializer by using “useLegacySerializerGeneration” config switch as documented in [this blog post] (http://blogs.msdn.com/b/praburaj/archive/2013/12/06/xmlserializer-compat-switch.aspx). Basically, both serialization code paths are supported.

Alicial
  • 1
  • 1