Being able to decompile/reverse engineer the client code easily is really only a slight hindrance. Enterprising hackers have been bending executables to their will (maliciously and non-) for years before high-level, trivial-to-decompile languages like C# came on to the scene. Security through obscurity alone is no security at all.
Any data on the user's machine (code or regular asset data) is essentially compromised already. You can't really protect yourself against that -- if you don't want people editing data, don't put it on their machine, save it on your servers. Similarly if you don't want them modifying the code in the client, make sure the client doesn't have control over anything useful.
If that's not an option (for example your multiplayer is entirely peer-to-peer) you can do things like compute hashes of the relevant assets and only allow people to play with eachother if the hashes match. Yes, somebody could carefully craft an edit to the executable such that it returned a different hash, but all that should mean is that the offending player will desynchronize and disconnect from the game relatively quickly because his or her assets don't match the rest of the players'.
You could also employ a "majority rules" type of test that allows for you to disconnect players whose simulation has drifted out of sync with other players, giving the "host" player (whoever started the game) the tie-breaking vote.