Welcome to today’s post.
In today’s post I will explain how to upgrade a.NET Core 2.x Web API application hosted on IIS to .NET Core 3.1.
In previous posts I showed how to upgrade a .NET Core 2.x Web API to .NET Core 3.1. This was quite a comprehensive upgrade which I explained in three posts.
The focus of today’s post is with to deal with the following tasks:
- Updating Web Deploy setting to upgrade to .NET Core 3.1.
- Web Deployment within Visual Studio 2019.
- Basic testing of IIS hosted Web API using POSTMAN.
- Dealing with common issues that can occur after deployment.
- Configuring IIS settings for our Web API.
Updating Web Deploy Settings to Upgrade to .NET Core 3.1
The first action we take before we can deploy our .NET Core 2.x Web API application is to change the target framework from 2.x to 3.1.
This is done by selecting the Publish.. context menu in the project.
When the publishing Wizard opens select the release edit as shown:
In the Publish | Settings that show, select the Target Framework as shown and change it to the 3.1 target framework:
Save the changes.
In the Publish screen the Target Framework will display the updated target framework.
In the next section, I will show how the binaries are upgraded from one version of the framework to the next.
Web Deployment within Visual Studio 2019
In the Publish Wizard, click on Publish and if successful the updated .NET Core 3.1 binaries from your API application will be deployed across to the IIS application. The destination folder will be in the inetpub/wwwroot subfolder.
If you get persistent file retries when the binaries are being copied across, open IIS and restart the IIS site the API applications are hosted under. In many cases this might be the Default Web Site. Then retry publishing the API application.
In your Visual Studio output console, you can tell which binaries are .NET Core 2.1 dependencies and those which are .NET Core 3.1 dependencies. Where you see Adding file… in the output the binaries are for the newly upgraded .NET Core 3.1 binaries:
Adding file (Default Web Site/BookLoan.Loan.API\Azure.Core.dll).
Adding file (Default Web Site/BookLoan.Loan.API\Azure.Storage.Common.dll).
Adding file (Default Web Site/BookLoan.Loan.API\Azure.Storage.Queues.dll).
Where you see Updating file… in the output the binaries are for existing.NET Core 3.x binaries that are being replaced:
Updating file (Default Web Site/BookLoan.Loan.API\Microsoft.IdentityModel.Logging.dll).
Updating file (Default Web Site/BookLoan.Loan.API\Microsoft.IdentityModel.Protocols.dll).
Updating file (Default Web Site/BookLoan.Loan.API\Microsoft.IdentityModel.Protocols.OpenIdConnect.dll).
Updating file (Default Web Site/BookLoan.Loan.API\Microsoft.IdentityModel.Tokens.dll).
In the next section, I will show how to re-test the upgraded web API using POSTMAN.
Basic Testing of IIS Hosted Web API using POSTMAN
To test our Web API applications, we can use one of the following tools:
- Use CURL command line utility.
- Using the POSTMAN API testing utility.
As I have showed in previous posts, I will show how we test using POSTMAN.
In IIS our Web API methods are of the form:
To run a HTTP API request we specify the URL, headers and if we are using POST, the body.
If our API runs successfully, then a response of 200 will be returned:
In the next section, I will show some common issues that can occur post deployment.
Dealing with common issues that can occur after deployment
There are times when the API testing uncovers other problems that we didn’t anticipate.
Below is a common 500.x error that can occur when we run a HTTP request on one of our API applications:
HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
In POSTMAN we can view a more detailed error in the body of the response:
<h1> HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process </h1>
<h2> Common solutions to this issue: </h2>Select a different application pool to create another in-process application.
<h2> Troubleshooting steps: </h2>
<li> Check the system event log for error messages </li>
<li> Enable logging the application process' stdout messages </li>
<li> Attach a debugger to the application process and inspect </li>
For more information visit:
<cite> https://go.microsoft.com/fwlink/?LinkID=2028526 </cite>
Here are some recommendations that we can use to diagnose the issue:
- Check the event log.
- Enable application logging through web.config.
- Attach a debugger and step through the process.
Configuring IIS settings for our Web API
There is one recommended fix to resolve the issue and that is to create or assign a different IIS Application Pool to the Web API application.
This requires opening IIS manager and applying the following configuration tasks:
- Creating a new IIS application pool
- Assign the application pool of the affected Web API application to either a different application pool or to a new application pool.
- Stop and start the new application pool.
To create a new application pool, we set the .NET CLR version to v4.0 and save.
To associate the new application pool to the affected Web API application, select the Advanced Settings.. and amend the Application Pool drop down with the new application pool:
Commit the change.
Retry the API in POSTMAN.
Repeat the above tasks for each Web API.
As a best practice, keep each Web API application in separate application pool.
In what can seem like a straightforward update to a new framework and deployment can be drama filled if we do not give time to deploy and smoke test our upgraded API. By rehearsing an upgrade in a development environment can prepare us for deployment when we finally configure our deployment for production using either manual methods or through a continuous deployment tool.
That is all for today’s post.
I hope you found this post useful and informative.
Andrew Halil is a blogger, author and software developer with expertise of many areas in the information technology industry including full-stack web and native cloud based development, test driven development and Devops.