RuntimeTypeModel.CanSerializeContractType has some counter-intuitive behavior.

[alennartz]

Hey,

I'm observing some counter intuitive behavior with regards to what types are reported as serializable. Not sure if this is by design or not so here goes.

What I'm trying to accomplish

Obtain an instance of a RuntimeTypeModel that will return false on bool CanSerializeContractType(Type t) unless that type has been explicitely annotated by a ProtoContractAttribute or is a List of such types. Now I can obviously just do the attribute check myself but I was expecting that I could configure an instance to basically behave in this way.

What I have tried:

var strictModel = RuntimeTypeModel.Create("strict");
strictModel.AutoAddProtoContractTypesOnly = true;
strictModel.InferTagFromNameDefault = false;

What I have observed

Some types even when not annotated by the attribute will come back as being supported by the type model. I have not been super exhaustive in my testing but what i have observed is that the types that seem to magically work are types that have get only properties where each of those properties can be found as a constructor parameter and that the constructor parameter has the same name (case insensitive) as the property.

The type definitions I have tested with

public class TypeA
{
	
}

public class TypeB
{
	public int Value { get; }
	
	public TypeB(int value)
	{
		
	}
}

public class TypeC
{
	public int Value { get; }
	
	public TypeC(int notValue)
	{
			
	}
}

public class TypeD
{
	public int Value { get; set; }

	public TypeD(int value)
	{

	}
}

public class TypeE
{
	public int Value { get; set; }

	public TypeE()
	{

	}
}

Out of all these types TypeB is the only one that returns true.

The Questions

• Is this intended behavior?
• Is there a way of getting an instance of RuntimeTypeModel that behaves the way I would like?
• Why are the other types in my test not considered to be serializeable the same way TypeB is?

[mgravell]

TypeB is coming under the umbrella of "tuple-like" types. It should probably be possible for us to disable this, though. I'll take a look.

…

On Mon, 17 Aug 2020, 21:47 alennartz, ***@***.***> wrote: Hey, I'm observing some counter intuitive behavior with regards to what types are reported as serializable. Not sure if this is by design or not so here goes. What I'm trying to accomplish Obtain an instance of a RuntimeTypeModel that will return false on bool CanSerializeContractType(Type t) unless that type has been explicitely annotated by a ProtoContractAttribute or is a List of such types. Now I can obviously just do the attribute check myself but I was expecting that I could configure an instance to basically behave in this way. What I have tried: var strictModel = RuntimeTypeModel.Create("strict"); strictModel.AutoAddProtoContractTypesOnly = true; strictModel.InferTagFromNameDefault = false; What I have observed Some types even when not annotated by the attribute will come back as being supported by the type model. I have not been super exhaustive in my testing but what i have observed is that the types that seem to *magically* work are types that have get only properties where each of those properties can be found as a constructor parameter *and* that the constructor parameter has the same name (case insensitive) as the property. The type definitions I have tested with public class TypeA { } public class TypeB { public int Value { get; } public TypeB(int value) { } } public class TypeC { public int Value { get; } public TypeC(int notValue) { } } public class TypeD { public int Value { get; set; } public TypeD(int value) { } } public class TypeE { public int Value { get; set; } public TypeE() { } } Out of all these types TypeB is the only one that returns true. The Questions - Is this intended behavior? - Is there a way of getting an instance of RuntimeTypeModel that behaves the way I would like? - Why are the other types in my test not considered to be serializeable the same way TypeB is? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#701>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMHYWBLVDVVRJSVX7I3SBGJPZANCNFSM4QCGEEMA> .

[alennartz]

Ah Interesting,
It would be nice to be able to opt out of it at some point but no rush. For now I ended up working around the problem by double checking the presence of attributes on top of the type in question. It'l slow down my serializer a bit but i'm caching the result so probably won't be that big of a deal.

Just out of curiosity where in the solution is the code that "makes this work"?

Thanks,

[mgravell]

Originally (not any more), "KeyValuePair<TKey, TValue>" worked via this approach, which means that without this support: dictionary wouldn't work. This hasn't been true since "map" was added to V2, and in V3 there's a completely different API for dictionary support. What library version are you using? As any new "turn it on/off" feature would only be V3 by default.

…

On Tue, 18 Aug 2020, 23:38 alennartz, ***@***.***> wrote: Ah Interesting, It would be nice to be able to opt out of it at some point but no rush. For now I ended up working around the problem by double checking the presence of attributes on top of the type in question. It'l slow down my serializer a bit but i'm caching the result so probably won't be that big of a deal. Just out of curiosity where in the solution is the code that "makes this work"? Thanks, — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMBOC7IOTCYIVGLIUXDSBL7FTANCNFSM4QCGEEMA> .

[alennartz]

Yeah I'm on version 3. It's all pretty much greenfield stuff so i'm pretty flexible at this stage.

[danstur]

@mgravell What is the state of the issue? Has there been any progress or is this up for grabs?

Would you accept a Pull Request that "fixes" this issue for v3 by providing an option to disable this? (Also if we're at it, any naming preferences for the option?)