Category Archives: Visual Studio

Remote Debugging Azure Functions from Visual Studio Stops Working

…and what you can learn from it

“The first thing you must keep in mind when you start using a serverless computing platform like Azure Functions is that everything is different, especially when things are obviously the same.”
–Abraham Lincoln, 1863

If you develop Azure Functions with Visual Studio it is easy to debug a function app running in the cloud. All you have to do is right-click the function app in Server Explorer and you are in business.

Although it is possible (and ultimately easier in many cases) to debug locally, remote debugging works well and is most convenient. If you choose a consumption plan to make it basically free (you totally did, you know you did!), eventually you may see the dreaded message “The breakpoint will not currently be hit. No symbols have been loaded for this document.”

You and I both know that your first reaction to this problem will be to open your favorite search engine which might lead you to a site named Stack Overflow where you might find the following article: visual studio 2017 remote debugging azure api app: “The breakpoint will not currently be hit. No symbols have been loaded for this document.”

You will try the suggestion and it might work. You will also be see that it was a bug, but it’s been fixed until you check and realize you have that or some later update and think “this is a bug and they broke it again!”

It isn’t a bug and it probably won’t be fixed!

A slightly different problem that might happen for the same reason is that the breakpoint will light up in the Visual Studio editor, but execution won’t stop, or it will stop some of the time but not other times. Maybe you’ll restart the function app and it will work for awhile.

“Ah-hah! I have found a bug,” you will think, and head to github to enter an issue such as this one: Remote debugging woes #538.

The Cause and the Lessons Learned

My experience with my first ‘development’ function app came from the fact that I started with one function and kept adding them. Back then the tools were pretty limited and it was (again) an easy thing to do. I had a variety of triggers in that app and the one I was working on was long running and used much more capacity than a short running web service. If during my development testing I put it under load by sending more than a few messages into the queue at a time, Azure Functions would very helpfully scale my function and helpfully create more instances automatically. Once this happens there is no way to attach to the right instance other than by shear luck because there is no way in a default configuration to steer all requests to a single instance. Furthermore, there is isn’t any way for the Azure Functions host to identify that a particular random message you sent should be treated uniquely and routed to the one instance out of however many there for debugging.

There are a few lessons I learned as a result if this experience that I can share. Here are my top 5.

  1. Never forget that in the default state of a consumption plan, there can (and probably will) be multiple instances.
  2. If you have more than one function in a function app, one of them might be causing the app to scale even if the one you want to debug has no or very little traffic.
  3. Good logging plus Application Insights are things use should strongly consider using throughout your application lifecycle. Logging, because you can’t assume you will be able to remotely debug all scenarios in development or even locally. And Application Insights because it makes it possible to understand and visualize complex and heavy load runtime behaviors.
  4. There are a number of configuration ‘knobs’ you can turn that affect scaling behavior and the number of instances for a given function. I will be writing about this in more depth in a future post.
  5. There are a lot of things to consider when combining functions in a single app. I will also be writing about this in more depth in a future post.

Thanks for reading!

–Doug Ware

P.S. Application Insights makes it easy to see how many instances are active. However, if you are not using Application Insights and prefer to bang rocks together, you can use Process Explorer from the Platform Features tab of the function app in the portal. If you click it and it takes a very long time to load, that is a good sign that there are a bunch of instances, but eventually it will usually display a list.

 

 

Task Runner Explorer is the Best Visual Studio Feature You Probably Aren’t Using

TL;DR – There is a handy feature in VS 2015 called Task Runner Explorer that you can use to run PowerShell or batch commands to do just about anything. You can also bind these to build events.

A task runner is a program that runs tasks. If you’ve been doing much web development these past couple of years you are probably familiar with this concept and popular task runners like Grunt and Gulp. In fact one or both of these might be essential to your development workflow. And, since many web developers consider these to be essential tools, the Visual Studio team released the Task Runner Explorer extension for Visual Studio 2013 and later made Task Runner Explorer an out of box feature in Visual Studio 2015.

If you aren’t aware that this feature exists, you aren’t alone! I took a poll on twitter.

<sarcasm>I was a bit surprised by this as the feature is prominently available by going to View | Other Windows | Task Runner Explorer.</sarcasm>

JavaScript Task Runner? No Thanks!

If your work isn’t mostly JavaScript, using a JavaScript based task runner probably sounds pretty unappealing. Happily there is an extension that supports .exe, .cmd, .bat, .ps1 and .psm1 files called Command Task Runner.

We use this in the Azure Functions for SharePoint project to automate deployment at build time by binding the script to the build event.

The deploy script is complicated, but there are a couple others that are pretty simple and are not bound to any events. We run them manually and I think they illustrate best why this tool is something that belongs in your everyday toolkit.

For example, each Azure Function for SharePoint relies on a config.json file. It would be an error-prone pain to create them by hand or by copying an existing configuration and so we have a script that creates a new config and puts it on the clipboard:

$scriptdir = $PSScriptRoot
[Reflection.Assembly]::LoadFrom("$scriptdir\AzureFunctionsForSharePoint.Core\bin\Debug\AzureFunctionsForSharePoint.Core.dll")
$config = New-Object AzureFunctionsForSharePoint.Core.ClientConfiguration

#Pretty print output to the PowerShell host window
ConvertTo-Json -InputObject $config -Depth 4

#Send to clipboard
ConvertTo-Json -InputObject $config -Depth 4 -Compress | clip
														

When a new client config.json is needed, all one must do is run the command from Task Runner Explorer.

Pretty cool eh?

–Doug Ware