HMAC provides message integrity and authentication. If you receive a message with a correct HMAC on it, you know that:
- the message is intact;
- the sender has the key.
Since the sender has the key, you know the message originates from somebody you gave the key to. If you distribute the key only to known users, you can be sure that the message originated from a known user.
Sometimes the key is used by the same system and no key exchange is necessary. For example, a password reset functionality on a web site may create a HMAC and send that by email. If you click the link in the email, the same site verifies the HMAC. Since the HMAC is created and verified by the same software, not verification is necessary.
In other applications, for example in OpenID, each client has its secret shared with the server. When adding a client to OpenID you also need to specify the key for the HMAC operation. This configuring step is done once.
In your example with the C# client and server, the key is hardcoded. The server can then verify that the request really originates from the client. However, it
would be pretty easy to extract the key from the client and forge a request.
A key exchange method for HMAC does not really make sense. It may be usable in another cryptographic mechanism, but normally HMAC keys are fairly static.
Finally you ask how this works in conjuction with HTTPS. HTTPS provides server authentication. You could use client certificates to achieve client authentication, but this is not enabled by default. With HTTPS, messages can't be modified in transit. So the only thing that the HMAC solution could add is client authentication.