-1

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

enter image description here

Api

enter image description here

Thanks

Space
  • 124
  • 1
  • 13
  • when you encounter a 500 error, what is being logged? – TZHX Jul 13 '22 at 10:35
  • APIs are inaccessible because they're inaccessible from your production server, not because VS2017 was used for deployment. Perhaps some ports are blocked, perhaps your IP isn't whitelisted, perhaps the credentials are wrong. You can log the entire exception easily with `ex.ToString()`, you don't need to log individual properties. For example, your code doesn't log any inner exceptions. `Exception.ToString()` would include that. – Panagiotis Kanavos Jul 13 '22 at 10:37
  • @TZHX When I call the API I have no log, despite the try and catch – Space Jul 13 '22 at 12:14
  • @PanagiotisKanavos I don't think the problem is with the server or the configuration, because when deploying via VS2015 I have no problem accessing the project APIs. I think when deploying via VS2017 a configuration of the project changes but I don't know what. – Space Jul 13 '22 at 12:14
  • Forget the editor. Your code is neither compiled by nor runs on the IDE. **What do the exceptions say?** Using VS 2015 means you probably targeted a very old runtime. In fact, even 4.6.1 [reached End Of Life](https://devblogs.microsoft.com/dotnet/net-framework-4-5-2-4-6-4-6-1-will-reach-end-of-support-on-april-26-2022/) back in April 2022 because no supported operating system is using them any more. Unless you use an unsupported server, your application is probably running on 4.8 already. 7 years ago SSLv3 was still used. It's now disabled by default both in .NET and *the OS* – Panagiotis Kanavos Jul 13 '22 at 12:29
  • 2
    The minimum supported .NET Framework version is 4.6.2, which uses the best available SSL algorithm by default. You should upgrade your project to 4.6.2 at least. Better yet, check what the actual .NET Framework is on the production server and target that. 4.x runtimes are binary replacements, which means that installing a newer version replaced older ones. If the server uses 4.8 so does your application. – Panagiotis Kanavos Jul 13 '22 at 12:35
  • @PanagiotisKanavos Thanks for your answer, it seems that the problem comes from the version of the framework I was using. I upgraded to 4.8 on the project and installed the SDK on the server and now the API call works perfectly. Thanks a lot for the help. – Space Jul 13 '22 at 13:45
  • @PanagiotisKanavos If you have time please post it as an answer so that more people can solve similar problems. – Jiale Xue - MSFT Jul 14 '22 at 07:05
  • @JialeXue-MSFT what would that answer be? We still don't know what the problem is. The question simply says "doesn't work", it doesn't even have an error message. I made a guess based on what used to be a common question 6 years ago and one of the main changes from 4.6.1 to 4.6.2. And the fact the OP had to install 4.8 means they're using an outdated Windows Server. – Panagiotis Kanavos Jul 14 '22 at 07:12

1 Answers1

0

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.

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236