Mark FaultException as Serializable

[imcarolwang]

For issue #3984 .

@HongGit ,@mconnew , @StephenBonikowsky
I am not sure if mark the FaultException class as Serializable is enough to make the scenario function work, let me know your concerns.

[mconnew]

This should also be added to the reference assembly. Can you add a simple serialization test to the unit tests for S.SM.Primitives to ensure the serialized payload is the same between NetFx and Core.

[imcarolwang]

This should also be added to the reference assembly. Can you add a simple serialization test to the unit tests for S.SM.Primitives to ensure the serialized payload is the same between NetFx and Core.

Now I've added the attribute to the ref project file System.ServiceModel.Primitives.cs.

And I tried to serialize a FaultException instance with XmlSerializer, it doesn't work in .Net Framework nor .Net Core due to error about the base class "Exception" implements IDictionary.

I can use BinaryFormater to do serialization for FaultException type but serialized payload comparison with NetFramework is different. Any suggestion? Btw, deserialization from the serialized MemoryStream won't work as there seems has other dependencies not implemented, shall we support that as well?

[mconnew]

XmlSerializer can't serialize IDictionary, but DataContractSerializer can. I couldn't find an instance of MemoryStream on FaultException or Exception. Where are you seeing this?

[imcarolwang]

XmlSerializer can't serialize IDictionary, but DataContractSerializer can. I couldn't find an instance of MemoryStream on FaultException or Exception. Where are you seeing this?

I forgot to mention I tried DataContractSerializer, it threw exception with message:

System.Runtime.Serialization.InvalidDataContractException : Type 'System.ServiceModel.FaultException+FaultCodeData' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. Alternatively, you can ensure that the type is public and has a parameterless constructor - all public members of the type will then be serialized, and no attributes will be required.

Regarding the MemoryStream thing, I am sorry it's not clear said, I meant after serialize FaultException instance to a memory stream, I was trying to deserialize it back, but failed to do so.

[mconnew]

The FaultCodeData class also needs the Serializable attribute applied. If you compare the NetFx source with the .NET Core source, you can see that the attribute has been applied in NetFx.

[imcarolwang]

Thanks, @mconnew .

I've updated the product and test codes. Serializaing FaultException instance with DataContractSerializer would get same payload as .NetFramework baseline after making following changes:

1. mark class FaultCodeData and FaultReasonData with [Serializable] attribute
2. add method public override void GetObjectData(SerializationInfo info, StreamingContext context) and its dependencies to FaultException.cs (.net source ref)
3. rename the private variable names in class FaultCodeData and FaultReasonData.
4. update the original .NetFramework baseline string section
   <HResult i:type=""x:int"" xmlns="""">-2146233087</HResult> to
   <HResult i:type=""x:int"" xmlns="""">-2146233088</HResult>

Does the changes in step1,2,3 make sense to you? Is result in step4 expected?

[mconnew]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mconnew]

Your step 4 is interesting. On Framework, CommunicationException derives from SystemException which sets the default HResult to COR_E_SYSTEM (-2146233087). SystemException didn't exist in Core until netstandard2.0 so we had to derive from Exception instead, which defaults HResult to COR_E_EXCEPTION (-2146233088). This is where you are seeing the change. I'll open an issue around whether we should switch to SystemException as our base type. For now we'll include that change for the tests as it's caused by the base class difference.

[mconnew]

Tests are failing because the Windows machines are running with the Spanish culture "es-ES" and the test expects "en-US".

[mconnew]

@imcarolwang, can you modify the FaultExceptionTest.Serializable_Default test to capture the current culture before instantiating the FaultException, set the current culture to en-US, instantiate the FaultException object and then restore the current culture before continuing with the test? Some test machines purposefully have a different culture to catch product issues which don't show up with en-US so we need to be tolerant of running on a different culture.

[mconnew]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mconnew]

@imcarolwang, don't worry about my last comment. I've fixed the build to use the English Windows image.