Join Chander Dhall for an in-depth discussion in this video Debug an application remotely, part of Microservices and Azure Service Fabric Basics for Developers.
- [Instructor] One of the really cool features with Azure Service Fabric is that you can debug your services remotely while you're using Visual Studio, and you can debug the services that have been deployed in a cluster on Azure. So for that, we would need a tool, Cloud Explorer for Visual Studio 2015. Once you click Download and double-click the VSIX file, it should initialize the VSIX Installer. Choose the version of Visual Studio, and the installation is complete.
You will need to restart your Visual Studio in order for this to work. So in order to be able to debug our application on the cluster in Azure, we need the Cloud Explorer. So we're going to go to View, and then click Cloud Explorer. And then we'll add our subscriptions and hit Apply. Now you can see that I'm able to see everything inside my subscriptions. So I can see my Key Vaults, and I can also see my Load Balancers, my IP Address, my Service Fabric.
So the same things you were able to see via Service Fabric Explorer, you can actually see right here. Inside my Applications, I can see the LinkedIn Type, and I can see both my applications. In order to enable debugging, I need to go to Service Fabric, and then name of my cluster, right-click on it, and hit Enable Debugging. It will take a while before this is ready for debugging. So as you can see, the install process could take anywhere between three to 15 minutes depending on your internet connection.
At this point of time, we've got the installation complete. The next thing we're going to do is right-click, and then say Attach Debugger. And this will take a while too. So once we have the Attach to Process window come up, we're going to go after the process we want to attach this to, and we can do any of the tools. So in this case, we could do the StatelessApp or Stateful app. It really doesn't matter much. So I'm going to go ahead and click the StatelessApp. And once you click Attach, should be attaching to the process.
So as you can see that I came to my StatelessApp and then added a debugger here. And I can see the breakpoint worked. So my execution is here, and I can come and see if I can get any values. If I were to hover over this.Context, I can actually see the value of the Context. It happens to be a ServiceTypeName StatelessAppType, and then ServiceName, which is fabric/LinkedIn/StatelessApp. Now, one thing to keep in mind is that when you are attaching a debugger to a stateless service, all the instances of the service on all the nodes are going to be part of the debug session.
However, that's not the case when you're debugging a stateful service. In that case, only the primary replica of any partition will be active and will be caught by the debugger. So even though it's a really cool feature, I highly recommend not to use it a lot in production. But it's a really handy feature to debug an app if needed. So when you're testing and when you've launched a new app, it's perfect to use this feature, but otherwise I would stay away from actually adding debuggers on your production code.
- Reviewing microservices vs. monolithic architecture
- Reviewing microservices and Azure Service Fabric basics
- Programming model architecture
- Creating a stateless service and a stateful service
- Creating a cluster in Azure
- Adding security to a cluster
- Finalizing cluster creation
- Deploying to an Azure cluster
- Debugging an application remotely