InvalidProgramException on RPCs when using serialization extensions

Describe the bug Types serialized via ReadValueSafe and WriteValueSafe cannot be used in RPCs. InvalidProgramException is thrown.

To Reproduce Steps to reproduce the behavior:

1. Create a custom type to serialize (class/struct).
2. Create custom type serialization extensions ReadValueSafe and WriteValueSafe for that type, placed in a static class SerializationExtensions as in documentation examples.
3. Create Server/Client RPCs that pass our custom type as one of the parameters.
4. At runtime, call the RPC.

Actual outcome When RPC is called Unity throws the following exception (in my case): InvalidProgramException: Invalid IL code in Code.Eclipse.ItemSystem.Player.PlayerDetails:DropItemServerRpc (Code.Eclipse.ItemSystem.EclipseItemSystem.ItemBase): IL_00dd: call 0x06000b65 RPC is not sent.

Expected outcome The client and server should be able to send RPC containing custom type successfully,

Environment:

• OS: Windows 10
• Unity Version: 2021.2.0b16
• Netcode Version: v1.0.0-pre.2

Additional context I use this serialization method for various purposes like replicating items via factory method pattern (classes), sending player-data (struct), or passing player object context. None of these can be passed via RPCs. Passing them via a named messaging system works as expected. Passing INetworkSerializable types in RPCs works as expected.

[ShadauxCat]

@Taenebron Thank you for the sample code. I have managed to reproduce it and am working on a fix.

In the mean time, you can get around the issue by making the first parameter this ref instead of this.

[ShadauxCat]

In the case of it working without having the extension method to FastBufferReader/Writer, I actually changed Foo to be a struct instead of a class (not sure why that allowed it to send over an RPC though).

edit: I removed the extension method I wrote to BufferSerializer, and the struct is still able to be sent over an RPC.

So any struct that’s unmanaged can be serialized automatically via memcpy. This is what I was worried was happening for you… because your struct includes a string, it shouldn’t be considered unmanaged. So the fact that this value is accepted is also a bug. I’ll have to look at the code generation to see why it’s thinking that struct is unmanaged - I have a strong suspicion the string you get on the other end is probably not valid.