@Jeffery, I’ll try to reword what @bko and @harrisonhjones said.
Since you want to use WiFi instead of cable bound serial, you have to use the “WiFi language” (protocol) which is TCP/UDP rather than a “cable language”.
The TCP-Serial-Bridge is like an interpreter who speaks both languages and can translate in a (sort of) transparent (for either side concealed) way, so that each side can speak their native tongue and will only hear their native tongue.
Since you’d have three parties taking part on this conversation there will be starting troubles, especially since TCP/UDP seems to be new land for you.
So what @bko and @harrisonhjones suggest is to keep the setup as simple as possible, by at least staying in the same room (on only one machine or platform - not involving the Core already) to get the interaction C# program <–> bridge (maybe loopback IP) <–> simplest thinkable test program (e.g. echo) up and running.
Once you got this set up you can move on and talk across platform boundaries, starting with a simple Core sketch that only mimics your test program, before going deeper into the Core functionality.
I hope this has cleared thing up a bit more.
BTW: Your outlined use case could be resolved a lot easier if you had the possibility to rework your C# code - either by use of the Spark cloud or by avoiding the need for an interpreting bridge.
If you “virtualize” (abstract communication class and two implementations, one for serial and one for OTA) the “language” could be easily chosen e.g. via some property settings and the program could run against a serial device and the Core, just the same.