Diagnostics

One of the most important things in any production environment is to track any bugs and maintain the logs. In case of some weird behavior being exhibited by the application, this comes in handy, as we can’t debug or track the issues directly. There might be a scenario like a broken external link or some external server being unavailable. ASP.NET WebHooks provides us with a way to diagnose our applications using WebHook handlers. In this chapter we will discuss logging and debugging an application.

Logging

Logging provides us an inside view of all the weird exceptions, errors, or hidden problems within our application, and is helpful in any production environment.

An application or software should be written such that it can report issues and problems effectively, and logging is the best way to report issues and problems. ASP.NET WebHooks provides inherent support for logging.

Tip: System.Diagnostics.Trace is a default method for writing a log internally by ASP.NET WebHooks.

Internally there is a TraceLogger.cs class, which implements the ILogger interface and writes the log. This has been implemented in such a manner that anyone can implement the logging system while utilizing frameworks like Log4Net or NLog.

In this book we are using an Azure app for our example applications. Let’s discuss how to implement logging in the Azure apps.

Working with logs: Azure apps

On Azure, all logs are automatically available after logging is enabled. Take any of the examples discussed in the preceding chapters where we deployed our application as an Azure web app.

Enabling diagnostic logs

In this section we will discuss the steps to enable logs by using Azure portal, and also directly from within Visual Studio.

Using Azure portal

Azure provides web server diagnostics and application diagnostics. With application diagnostics, we can see or retrieve logs that are helpful in tracking down various issues.

Let us take a look at how to enable application diagnostics:

Log in to the Azure portal using valid credentials. Go to Web Apps and click on your app (ActivityTrackerSampleAPP in our case).

Tip: If you don’t have an Azure account, you can create a free one here.

Figure 33: Web App - Azure portal

Select Diagnostics logs and enable the application diagnostics as shown in Figure 34.

Figure 34: Enabling application logging

You can select verbose to capture everything (you can also select informational, warnings, or errors level as per your choice) with the help of the Azure portal; this is an easy way to enable diagnostics logs.

Note: To know more about enabling diagnostics, refer here.

Using Visual Studio

In this section we will discuss enabling the application logging using Visual Studio. All the examples are using Visual Studio 2015.

Start Visual Studio and open your ActivityTracker application, which we created in Chapter 3. This application has already been published to Azure—if you skipped Chapter 3, you can use the sample app from the Bitbucket repository by going to Chapter 3, opening up the application, and publishing over Azure.

Tip: Using Visual Studio with elevated administrator rights is recommended.

From Visual Studio, open Server Explorer and expand the App Service node, right-click on ActivityTrackerSampleApp (we have published this app), and then click View Settings.

Note: If you are not already logged in, Visual Studio will prompt you to log in using your Azure subscription credentials.

Figure 35: Enabling application logging - Visual Studio

On the View Setting page, under the Configuration tab, you can enable logging. Select verbose from the Application Logging (File System) dropdown menu, and click Save to enable logging for all levels. The application is now ready to write logs.

Implement or redirect own logging implementation

As discussed previously, ASP.NET WebHooks internally writes logs using System.Diagnostics.Trace. But if you would like to use some other logging framework such as Log4Net or NLog, we just need to provide implementation of the ILogger interface, and simply register using any dependency injection engine.

Debugging

As we are deploying applications to Azure, we would like to debug our production or deployed code to track various issues. This requires remote debugging (where we attach our production environment and debug using Visual Studio on our local machine). This plays a very important role when you need to drill-down in your code to fix a problem.

In this section we will take sample application developed in Chapter 03. If it’s not already deployed, you can deploy the application to Azure now.

To start, open the ActivityTracker sample application (created in Chapter 3) using Visual Studio. Open the Server Explorer, expand the App Service node, right-click on ActiviTyTrackerSampleApp, and choose Attach Debugger.

Note: Set break point before attaching process to start debugging.

As soon as you select Attach Debugger, Visual Studio starts applying debugger settings and invokes a web browser using the application URL. Now, go and push some changes to the repository for which you added a WebHook receiver (refer to Chapter 3).

Figure 36: Debugging application

As soon as Bitbucket triggers a push event, the break point is hit, and you can see the value of data and the flow of logic while debugging.

Debugging directly with ASP.NET WebHooks

Directly debugging with the source code plays an important role while you are creating or customizing existing code. This allows you to directly debug the entire source code of ASP.NET WebHooks. In order to achieve this, you will have to follow few steps as mentioned in the official documentation of ASP.NET WebHooks.

Conclusion

In this chapter we have looked at diagnostics, and also discussed the importance of logging and debugging. We have debugged a live application and looked in detail at how to get application logs from Azure.