Problem with API on framework 4.6.1 and deploy with VS2017

Question

I have a website that was developed a few years ago with the 4.5.2 framework and VS2015. Following two changes of technos integrated on the project (PDF generation and mail sending) I had to change the version of the framework to 4.6.1. This change is mainly due to the mail sending system, we use SenInBlue which has just migrated its APIs to a V3 version and to be able to use the latest version we must use VS2017. When I work locally I have no problem, however when I deploy my site via VS2017 then some APIs become inaccessible and return an error 500. If I redo a delivery with VS2015 I don't have any problem with the APIs but I can't use the APIs for sending emails which are not supported by VS2015. Below is the content of my WebApiConfig.cs file and one of the APIs that is inaccessible after deployment via VS2017

WebApiConfig.cs

Api

Thanks

Answer 1

There's no information in the question itself, not even the logged exception, so one can only make some wild guesses, based on versions, dates and a common problem 6 years ago

The Visual Studio version doesn't matter, it's only the editor. The code runs on the .NET Framework runtime. .NET Framework 4.5.2 went out of support a long time ago. .NET Framework 4.6.1 also went out of support this year, simply because no supported Windows version required it. All supported Windows versions, including Windows Server versions, come with 4.6.2 at least. In fact, I think the minimum is now 4.8.

Since this is a networking problem with a new service version, I'd suspect the SendInBlue service discontinued the use of insecure SSLv3 and TLS 1.x, years after other services did.

To fix this, change the project's target to 4.6.2 (although 4.8 would be better) and make sure the relevant .NET Framework Runtime version is installed. Preferably 4.8. This version is 3 years old already and contains fixes for the bugs found in previous versions. By now it's pretty stable.

In June 2015 SSL v3 was deprecated because it was too easy to crack. By 2016 major services required TLS 1.2, with Google, Azure, Amazon etc requiring it soon after. PCI-DSS made this a requirement later than others, but right now, there shouldn't be any site or service requiring anything less than TLS 1.2.

For this reason, .NET Framework 4.6 and later disabled SSL v3. They didn't start using TLS 1.2 automatically until 4.6.2 though. Since 4.6.2, the best available protocol supported by the OS will be used. If the OS supports TLS 1.3 (Windows 11 does), then TLS 1.3 will be used.

.NET Framework 4.x versions are binary replacements, which means installing a newer version replaces older ones. Since .NET Framework Runtime is updated through Windows Update, it's likely servers already run the latest runtime.