Serializers are being generated for unneeded types

[dVakulen]

Such as OutboundMessageQueue, OrleansTaskScheduler, etc:

It results in 20k+ LOC generated files, slowing the build and IDE.

(using latest master branch (0aa92f3))

[sergeybykov]

Indeed, I see OrleansCodeGenOrleans_Runtime_Messaging_MessageCenterSerializer, OrleansCodeGenOrleans_Runtime_SocketManagerSerializer, OrleansCodeGenOrleans_Runtime_Messaging_OutboundMessageQueueSerializer and more such classes getting generated. Looks like a regression to me.

[sergeybykov]

I just checked that at 43efc4b this wasn't the case. So it's a relatively recent regression.

I think we can still release beta2 with this as it doesn't seem to break anything.

[sergeybykov]

The regression got introduced as part of #3669.

[ReubenBond]

My bad, I widened the search to consider all types in the target assemblies as though they were marked [Serializable]. I'll undo it if it's causing builds to be slower or build output to be significantly larger

[onionhammer]

Why not only generate serializers for the types used by Orleans grain interface contracts?

[sergeybykov]

@onionhammer Since Orleans is very accommodating when it comes to data types being passed (interfaces, object arguments, various collection types), it would be too restrictive to do that. We give developers a few ways to point to more types that they know could be passed over the wire.

[onionhammer]

It seems like those indeterminate type serializers could be generated at runtime and cached

[sergeybykov]

In theory, yes. In practice, we ran into a number of corner cases and subtle issues (e.g. with loading of dependency types and their order) with run time generation of serializers. Because of that, in 2.0 we are making run time codegen optional and more explicit - it runs only for specified assemblies and only during silo/client build time. That seems to produce more predictable and repeatable results.