Going HTTPS-only doesn't help protect you in this case. This other question should help illustrate why. In short, if an attacker can force a client to communicate over HTTP then the attacker get between you can the client relay the data between the both of you - talking to the client in HTTP and the server in HTTPS.
It would be nice if there was a way to force the client never attempt an HTTP call to your server - thankfully you can with HSTS. But the typical HSTS configuration protects your users if, and only if, you can establish a secure connection before an attempted attack. This is because HSTS relies on a Trust On First Use, or TOFU, model. If you can get an HSTS header on the client's machine before any attack then the client will be safe. If an attacker is already in place then they can strip out the HSTS header and continue their attack on the client.
This can be avoided if you pre-load the HSTS header. Pre-laoding HSTS means that you register your domain with the browser vendors and they'll hardcode their browsers to never allow an unsecured connection to your server. This makes an SSLstrip attack very difficult becasue the client will never send an HTTP request to your server. But be careful, HSTS Preload comes with its own set of risks. This other question has some great references to HSTS and HSTS Preloading, please read the questions and top 3 answers for all of the details.
Like Tom mentioned in his answer, you can set up HSTS with a custom HTTP Response Header. You can also do it in your Web.Config file:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
Note: This does not include the preload attribute. It also excludes the includeSubDomains attribute which you may want as well. Again, be very careful with both of these attributes. Don't naively implement them.