Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Breakpoints Not Hit in Azure Function

I am learning how to use Azure Functions to process and respond to SMS messages submitted via a Twilio phone number. This is using the preview v2 of Microsoft.Azure.WebJobs.Extensions.Twilio (3.0.0-beta5).

I use ngrok to forward an http trigger from Twilio thru to the local server that fires up when I launch the Azure Function in debug mode from within Visual Studio (2017).

The code I'm using is very simple, just returning a text message in response to anything it receives:

public static class Function1
{
    [ FunctionName( "BikeSMS" ) ]
    public static IActionResult Run(
        [ HttpTrigger( AuthorizationLevel.Function, "get", "post", Route = null ) ]
        HttpRequest req,
        TraceWriter log
    )
    {
        log.Info( "C# HTTP trigger function processed a request." );

        var twiResp = new MessagingResponse();
        twiResp.Append( new Message( "This is Muddlehead. Thanx for your message" ) );

        return new ContentResult()
        {
            Content = twiResp.ToString(),
            ContentType = "application/xml"
        };
    }
}

This works fine. My problem is that I cannot get the debugger to break on anything within the function; the breakpoint just gets ignored, and the specified text is returned.

How do I configure things so that when the Azure Function is called, the debugger gets involved? Is there some setting I need to pass to the local server that gets fired up by VS 2017 to host/run the Azure Function?

Update

I was able to get the VS debugger to stop on breakpoints, but only after manually attaching VS to the console app that was running the local Azure Function server that starts up when you hit F5.

So something is wrong in the configuration or tooling, because whatever the VS debugger is attaching to when you hit F5, it isn't the right app.

I'm not submitting this as an answer because it isn't. I shouldn't have to re-attach manually the debugger.

Here are the steps I used to get the debugger to start working the way it should:

1) Launch the Azure Function app via F5 in debug mode. Console window opens for the Azure Function host.

2) Debug -> Stop Debugging. Console window opened in #1 closes, and a new console window running the Azure Function host appears.

3) Attach VS debugger to the console app that opened in #2 (called "func.exe" in my case).

Debugging now works as you expect.

Additional info: I use ConEMU as my default console shell within VS. I don't know if it means anything, but the console that opens in #1 is a ConEMU shell, but the console that opens in #2 is a plain old cmd.exe shell.

like image 720
Mark Olbert Avatar asked Jul 02 '18 02:07

Mark Olbert


People also ask

Why are my breakpoints not hitting?

If a source file has changed and the source no longer matches the code you're debugging, the debugger won't set breakpoints in the code by default. Normally, this problem happens when a source file is changed, but the source code wasn't rebuilt. To fix this issue, rebuild the project.

How do I activate breakpoints?

To set a breakpoint in source code, click in the far left margin next to a line of code. You can also select the line and press F9, select Debug > Toggle Breakpoint, or right-click and select Breakpoint > Insert breakpoint.


2 Answers

I did not have ConEMU but I had the same problem - function breakpoints had just stopped working. Furthermore the function runtime console didn't close when I stopped the process, it had done so earlier. Running in Visual Studio.

The solution was rather unintuitive: go to "Tools -> Options -> Debugging" and uncheck "Automatically close the console when debugging stops". After that breakpoints started working again even if the window still doesn't close automatically.

like image 198
Lauri Peltonen Avatar answered Sep 20 '22 17:09

Lauri Peltonen


There is apparently a problem with how ConEMU takes over Window's opening of default console windows in this situation (you can read about this feature of ConEMU at https://conemu.github.io/en/DefaultTerminal.html).

Disabling this ConEMU feature -- which lets VS open a normal Windows console -- solved the problem; breakpoints were hit as per normal, without having to attach to the console running the Azure Functions local host manually. Of course, that means I lose the value of ConEMU shells opening within VS, but I can live with that. I will report the problem to the ConEMU team.

like image 31
Mark Olbert Avatar answered Sep 20 '22 17:09

Mark Olbert