There are a number of things your code is trying to do that just is NOT going to work.
You are trying to transmit multiple types of data between the two systems, and you have no reliable identification of the types of data that are being transmitted. Not only that, but you want all these things to be handled in one call, which is still possible, but only magnifies the need to uniquely identify all the different types of data being transmitted.
For example: You have a request for analog read data that immediately reads what comes back from the Arduino and assumes it's your result from that request. Bad assumption.
In general, you have 4 different commands of varying lengths. 2 are expected results back also of varying lengths. Your serial comms need to include a few things in order to make such a scenario reliable.
- Unique start and end of packet markers. It is essential they be unique. In other words, these start and end of packet markers cannot be used anywhere within the packet itself.
- Unique headers for each of the command types and response types. The uniqueness is the same as for the start and end markers.
- A processing framework that either does not expect the result to be the very next packet of data received after the command is sent (flexible, but a bit more complicated to code), or strictly enforces a rigid command/response ordering for all commands (not as complicated to code, but introduces a lot of blocking and waiting, and isn't very efficient, responsive in general).
You are currently using binary serial comms, which makes a lot of the above more difficult (unique markers/headers in particular, since writing out an int value can generate any byte value output). Switching to human readable transmission makes most of the above easier, but introduces a layer of conversion/parsing. Both the Arduino Serial object and C# serial object provide provisions for converting, and both the Arduino and C# environment provide additional libraries for parsing. As a result, it's generally easier to get human readable Serial comms functional than it is to get binary Serial comms functional. It's also easier to debug human readable Serial comms since it's, well, human readable.