Sometimes your project forces you to do something you rather wouldn’t: debug in staging or production. Although you should definitely try to avoid these situations, sometimes sh*t just happens and that’s fine. If your project is running on Service Fabric, Azure offers you the option to attach a debugger right from within Visual Studio. This is a very powerful option which creates a connection between VS and your service fabric nodes in order to communicate with the remote debugger.\u00a0<\/p>\n
To facilitate this connection, some rules are added in the load balancer which point certain ports to the machines in your VM scale sets. We have found that for each role you’re running, you’ll get 4 rules to open up 4 different ports. Best practice would be to, after you’ve finished debugging, to remove these rules again by disabling the debugger functionality (which you easily can do from Visual Studio as well). In practice we’ve found that our devs sometimes forget (or neglect, whatever you prefer) to do this. This presents us with two problems:<\/p>\n
In order to resolve these issues without having to bother the developers each time, I created two Powershell functions you can use to automate the removal of the debugger rules. These scripts rely on the AzureRM module, so you’ll need that one installed. To use these functions, first\u00a0log in<\/strong> (Connect-AzureRMAccount) and select<\/strong> the correct subscription<\/strong> (Select-AzureRMSubscription). After that, the rest is as simple as calling Remove-VMScaleSetDebuggerNatPools\u00a0<\/strong>and\u00a0Remove-LoadBalancerDebuggerNatPools<\/strong>!<\/p>\nRemove-VMScaleSetDebuggerNatPools<\/h3>\n