We don't know how the data is moving around, so here is some advice:
If the client and server communicate over a two-way channel, then use SSL. Python has good built-in support for SSL, I'm sure C# has good support too. This is easy to set up, you can even use stunnel so your Python and C# code doesn't have to touch crypto.
If the client and server communicate asynchronously (e.g., email, batch jobs, etc.) then use PGP / GPG. Encryption and decryption can be offloaded to an external process, such as GPG, so the cost of implementation (no matter what the language) will be relatively minimal and your Python and C# code don't have to touch crypto.
Neither of these require using a library.
In both cases, you will need to create a public/private key pair. The normal procedure is to install this key pair on the server, and bundle the public key with the client. If your app does not have a simple division between "client" and "server" then you will need to figure something else out, but you should ASK FIRST because it is easy to get crypto wrong. Frighteningly easy.
DO NOT USE "AES".
If you type "AES" into your source code somewhere, you are doing it wrong.
Also, don't use AES.
AES is a cipher, which is one of the building blocks of a cryptography system. You don't want a building block, you want a complete system. SSL and PGP/GPG are complete systems. If you try to invent your own system by using AES, you will probably make a simple mistake somewhere and this is a very bad thing.
Creating a viable cryptography system is difficult. Like brain surgery, there are lots of people who can pick up a knife but only a few who know where to cut.
Did I mention that you shouldn't use AES?
Okay, don't use AES.
Don't forget to avoid AES.