Is there a way to make Visual Studio kill old Azure Functions processes when I do a fresh build+run? - visual-studio

When I build and run ("Start Without Debugging" i.e. ctrl-F5) an Azure Function project, the newly built function will be unable to run if I have already have an earlier build of said function running (due to the port being in use).
Port 7071 is unavailable. Close the process using that port, or specify another port using --port [-p].
Compare ASP.NET Core builds: if I do the same thing, the old build will be automatically killed and replaced.
Is there a way to make Azure Functions replicate this behaviour?

AFAIK, I observed in my test cases that Visual Studio IDE cannot debug the two functions at a time using the same port.
Debugging is possible in Visual Studio for only one function at a time and the other function using the port 7071 needs to be close for launching the new function in the Azure Functions Context.
You can have the new port to run another function app running/debugging locally in Visual Studio.
If the 2nd function from the same function app needs to be debugged, then it will run on the same port simultaneously.
Note: We have to kill the existing process for using the same port for another function and either by stopping that function execution or by closing the func process in the Windows Task Manager.
Refer to the MS Q&A #507662 and SO 56648386.

Related

How to set up Visual Studio for debugging C#/.NET5 solution with multiple projects launching each other?

I have a .NET5 solution that is made up of several applications that communicate with each other using named pipes. In particular, there is a central service application (implemented using BackgroundService from Microsoft.Extensions.Hosting) and also an "Agent" that is responsible for launching the main service if it isn't running already, monitoring its status and relaying user commands to it. There are also a number of class libraries shared between the applications.
I've already configured the projects in the solution so they all build to the same output directory and I've set <UseCommonOutputDirectory>true</UseCommonOutputDirectory>.
After I launch the Agent in the debugger, it launches the service.exe using Process.Start() (it is not a Windows service). I can then (manually) attach to that process to debug it, too.
However, I'm wondering if this experience could be made smoother somehow:
Is there a way to set this up so the debugger would automatically attach to the child-process when it launches rather than me having to do it manually?
Is there a way to tell VS that it should also automatically rebuild the service and its dependencies when I launch the agent with F5? I keep forgetting this after making changes to the service...
I am aware that I can set up multiple startup projects so they all launch in the debugger simultaneously and that works for some debugging scenarios but I'm currently looking at a case where I really need the service to be launched by the agent and not separately before.

Enabling Profiler without reboot

Every time I want to profile an application with Visual Studio I have to run vsperfclrenv /globalsampleon as recommended here and here (I have it normally switched off because I love the "edit and continue"-feature). The command prompt then states:
Enabling VSPerf Global Profiling. Allows to 'attaching' to managed services.
You need to restart the service to detect the new settings. This may require a reboot of your machine.
So far I haven't found a way to restart the service (as mentioned in the prompt) without rebooting my computer. Is there another way?
EDIT to add some information from the comments:
I am profiling an application that I start from Visual Studio
I use another instance of Visual Studio to profile the application via "attach profiler"
You do not need to run "vsperfclrenv /globalsampleon" and reboot if an application you profile can be launched from command line. In this case you can invoke "vsperfclrenv /sampleon" from command prompt and then launch you application from the same prompt. This will set proper environment for a process being profiled.
However, if your application cannot be launched from command line (e.g. you profile a managed service) then you need to invoke "vsperfclrenv /globalsampleon" and reboot to apply proper environment changes system-wide. A reboot is recommended because without it in some cases the environment changes are not successfully broadcasted system-wide.
You can find more information here and here.
UPD: Specifically, for your scenario please invoke "vsperfclrenv /sampleon" from VS developer prompt, start VS via invoking "devenv" from that prompt and use that VS instance to start an application. So, your application should have necessary environment set. Another VS instance which you use to attach can be run as usual.

Remote debug a Windows service using VS2012

I've tried to find an answer to this before posting this question. I've got a windows service running on another machine. I've written the service in C# and the directory from which the service executable runs holds both executable and debug files (.pdb). I'm attempting to remote debug the service for the first time using VS 2012 Remote debugging. I'm able to attach to the service process successfully. However, as this is my first time I'm not sure what I can do next. I've clicked the pause button and that pauses the service on the line ServiceBase.Run(ServicesToRun) which isnt much use to me. The service has a timer which sets off every 30 seconds and will run the code in the timer event.
My question is ... is there a way of stepping through the code using the debugger in such a scenario.
Do I need to have some debug specific code already in my codebase so that when a debugger attaches it will take me to a place in the code from where i can step through the code?
Thanks,
Andrew.
There are several ways to debug your developed remote application or windows service. If you were in your machine(local) that would be simple to debug.
System.Diagnostics.Debugger.Launch();
But as you are in different machine it depends how your both Machines are connected. Which means you have some limitations on debugging remote application/services.
A Quick search gave me the following result that seemed helpful to me for you,
You can use Remote Debugging Monitor that visual studio use for connecting to remote device and debugging. You can have a clear instruction here on How to: Run the Remote Debugging Monitor.
There's another tool which lets you debug remote application's after a proper setup. But it has some limitations or conditions that you must abide by.
Here is the tool named Remote Tool, you can find a detailed setup process from MSDN here on How to: Set Up Remote Debugging.
It has been clearly quoted there about the prerequisites for using this tool. But still I'm rephrasing those again for quick reviewers.
Prerequisites to use Remote Tool for Visual Studio
To debug on a remote device:
The remote device and the Visual Studio computer must be connected over a network or connected directly through an Ethernet cable. Debugging over the internet is not supported.
The remote device must be running the Remote Tools for Visual Studio 2012.
You must be an administrator to install the remote tools on the remote device. To communicate with the remote tools, you must have user access to the remote device.
Feel free to share if you get to a better and working solution.
Thanks for your response. It reminded me to post my solution here for others like me.
The solution is simple (It always is once you know it).
Ensure that you are running the same code on the target machine as you have open in Visual Studio. It has to be the same assembly and version else the debugger will not hit your breakpoints. Ensure you have your breakpoints setup where you want the debugger to break execution. Then attach to the target machine process and wait for the timer to kick in and run the process where you breakpoint is set.
Hope this helps.
Andrew.

Confused about remote debugging in Visual Studio 2010

I have a console app that I am trying to debug using remote debugger.
Clearly it seems you need to first run the application on the remote server, then attach to process.
My question is, whats the preferred method to catch the code at the start of execution, so it won't run away by the time you've managed to hookup the debugger.
Is there an industry standard best practice way to hook in and pause execution at a certain point till the debugger is attached?
There is a way to launch the remote app from Visual Studio.
Go to the Debug tab in project properties window.
Select Start external program and specify the exe path. (e.g. C:\MyTestApp\MyTestApp.exe)
Check Use remote machine and enter the name of the remote machine.
Detailed explanation here.
I couldn't think of a way to attach to a process in remote machine before the process starts. But , have you considered using Intellitrace to see the events and state of your program?
There is a way to attach a debugger to a Application automatically when the application launches. But I am not sure if it would work on remote debugging.
Similarly the System.Diagnostics.Debugger.Launch() would launch a process and start a Debugger attached to it. Again it doesn't support Remote launching and debugging.

Run multiple copies of an app from Visual Studio

How can I run multiple copies of the same app in Debug with Visual Studio? For instance, how do I run app.exe /option1 and app.exe /option2 and still debug both? I know I can run them manually and then attach, but I want an automated solution.
I have tried writing a small console app just to run 2 processes, but obviously they are not being run under debugger. Any ideas?
The debugger sometimes seems to lock out other apps a bit so I'd be wary of running two debugging instances at the same time on the same machine in case they affect each other. Instead, unless the apps need to run on the same machine, I'd suggest installing some kind of VM software and then running each debugger in a separate Virtual Machine or similar.
I ended up creating a separate project and calling application's Program.Main() from there :)

Resources