For a long time, our team was trying to migrate an ASP.NET Full Framework project to ASP.NET Core. But, the process failed because a dependency on SOAP web services. As a result, I decided to stop the process and wait for .NET 5, hoping it will help the situation.
The migration process started with a branch of latest version of the code. I changed the project file structure, enabled and configured the DI in whole project. Moved static files to the www directory. Changed the startup and made the EF to code first as the base project was using EF database first. Then changed signature of all API methods in controllers. Everything was working good till now.
However, the project was heavily dependent on old school SOAP web services. This part created a long pause in the progress. .Net Core, in contrast with .Net full framework, does not work with configuration based WCF communication. As a result, I used code base configuration. In spite of the fact that I tested many use cases, I did not find a way to call the web services correctly. .Net core 3.x does not have support for WsHttp2007. Extensions does not have a good support too. I encountered many errors, so I asked a question on the StackOverflow to find a solution. Unfortunately, I did not received a correct answer after 18 days. Finally, I gave up, and decided to find another solution.
The new solution happened to be ASP.NET Core based on .Net Full framework instead of .Net Core. This way, I could move the web part to ASP.NET Core despite its root in Full Framework. Then I can be hopeful that I will change the framework from Full Framework to .Net Core in a later time. But, soon, I realized that ASP.NET Core 3.x can not be used based on Full Framework. On the other hand, using Full Framework, you are restricted to ASP.NET Core 2.x. This is not what we mean as being up-to-date.
So far, so good. As .Net 5 release is scheduled for just next 2 months, I decided to abandon the migration process till its release. Hoping that .Net 5 has a better support of legacy SOAP web services. As a plan B, I consider creating a proxy application behind IIS. I mean creating a regular .Net Full Framework application which can work with legacy SOAP web service, expose this functionality with something more modern, like web API. Then put it behind IIS and force the migrated ASP.NET Core (on .Net Core) to communicate with this proxy application instead of SOAP web services.
Top comments (0)