But deploying to the Cloud ☁ is sometimes a game of Russian Roulette. We may think that all our code is in place and ready to go, but sometimes, things just don't work as expected.
Azure has a fantastic feature, Remote Debugging, which can help you, as an ASP.NET developer, to find out what is actually happening on the server, when your code runs.
This article will describe how to setup and perform a remote debugging session of an ASP.NET MVC Core website in Azure.
Configure the Web App in Azure
Firstly, login to the portal at portal.azure.com
Locate your Resource Group and find the App Service that you want to deploy your website to.
Inside your App Service, navigate to Settings > Configuration > General settings
Check the Stack settings and set it to .NET Core if necessary.
Scroll down to Debugging and select Remote debugging: On
Select the Remote Visual Studio version here.
(If you're not on VS 2019 by now, you need to upgrade!)
At the top of the page, click 💾 Save
You should see: "Any changes to applications settings and connection strings will restart your application. Are you sure you want to continue?"
If that's ok, click [Continue]
Publish your Web App in Visual Studio
Open Visual Studio and load up your solution. Locate the project you want to remotely debug in the Solution Explorer window.
Right click on this project, and select Publish...
Note: If you've done this before, you might want to delete the PublishProfiles folder within the Properties folder.
You'll get a new window, asking where you want to publish the app.
Select Azure (obviously!) and click [Next]
Select Azure App Service (Windows) and click [Next]
Select the correct Subscription, View (typically "Resource group") and locate your web app in the list with a single left click. Click [Finish].
IMPORTANT! On the new "Publish" window that appears, it is very important that you modify the Configuration to Debug.
Do this by clicking the ✏ pencil icon near to Release in the Summary section of that window.
When you've saved the settings, you'll see Configuration: Debug in the Summary section.
Hit the [Publish] button and wait for Visual Studio to do the magic.
Perfoming the remote debugging session
Now that your web app is published, check it in the browser to make sure it is live. Go back into Visual Studio and follow the next steps.
On the main menu, select View > Server Explorer
When the Server Explorer opens, you should see "Azure", and your email address.
NOTE: You need to be logged in with your Azure account in Visual Studio to see this!
Double click "Azure" to expand the menu, and double click "App Service". If you have multiple subscriptions, you may not see your apps here. Instead, click "Open Cloud Explorer".
You can also open Cloud Explorer from the main menu, but often it's necessary to "Re-enter your credentials" in the Server Explorer before doing this.
In the Cloud Explorer, navigate through your subscriptions and resource groups to find the web app where you just deployed your MVC Core project.
Right click on that project, wait for the menu to load, and click ▶ Attach Debugger
This may take a while. Visual Studio needs to find a process to attach to and then attach the debugger.
It's pretty complex, alright? 🤪
You should see that your website has loaded up in the browser, and now you're in a debug session within VS. Try putting a breakpoint in one of your controllers or middlewares and try to hit it by navigating to the page in the browser.
Works for me, man! However, remote debugging is extremely slow. Between every press of F11, control is momentarily returned to the browser, so it's a bit like strobe lighting if you're going to do this for any amount of time.
A cool feature is that you have access to your database contexts from within the remote debugging session (as you would when running locally), so it's possible to debug against real, production data.
USE RESPONSIBLY AND WITH CAUTION!
Oh, and... don't forget to modify your publishing Configuration back to Release when you want to stop remote debugging. It's also good practice to turn it off in the Portal if remote debugging is no longer necessary.