Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

Feature Idea: .Net Code Instrumentation - To collect details about lines and methods in the application



Hi, Is it possible from newrelic to do .net code instrumentation ?
I’m looking for .net agent or api that can perform code instrmentation to collect number of lines executed and methods details from the application hosted in the server.
Let us know If there is provision from new relic ?


New Relic Edit

  • I want this too
  • I have more info to share (reply below)
  • I have a solution for this

0 voters

We take feature ideas seriously and our product managers review every one when plotting their roadmaps. However, there is no guarantee this feature will be implemented. This post ensures the idea is put on the table and discussed though. So please vote and share your extra details with our team.


Hi @ssoundarajen

As you have correctly tagged this, it would be a feature Idea . Presently we only do Instrumentation at the Transaction level.

Great Idea BTW


Hi @ssoundarajen !

First, I want to be clear that our product managers review every single one of these requests and take them very seriously. It is important to keep in mind that there are several factors that are considered when it comes to implementing specific features. The number of customers requesting a particular feature is one of the driving factors. While support can submit feature requests internally, such requests are not available for public consideration. This is the reason we always encourage posting feature ideas in the community as that helps to gauge interest in a particular feature.

In this case, I’d like to ask that you elaborate on this request. I’ll address each element of the request individually:

  • Code instrumentation to collect the number of lines executed: Are you looking for a line count as an attribute for the transaction? Where, exactly, would you like to see this data, and to what type of metric do you want to see it attributed to? It should be noted that the AddCustomParameter API method could be used to add a custom attribute to the transaction, code added that collects the number of lines executed, and the result added as the value to the custom attribute. Not only would that make this data available for transaction traces, but it could be queried in Insights for any transaction. The API method for the custom parameter would just need to be added as the very last method in a transaction so the line count could be accurate.

  • Methods details from the application: Exactly what details are you looking for and what report would you want the details to be provided in? A method has many different details, a lot of which aren’t typically important when evaluating performance. Do you want all of the modifiers for each function, i.e. public, static, void, etc.? Do you want the parameters and values? Are you looking to have the entire source code for a given method displayed? Would you want the variable values included? How and where would you want to see the data displayed?

Further details on exactly what you’d like to see and how or where you would want the data displayed will help in defining how this is approached. For the method details, it’s important to consider the kind of performance impact collecting higher levels of detail can have. One of the most delicate balances we need to maintain with performance monitoring is not to cause the agent to become a performance burden itself. The more details the agent collects, the more resources it requires to do its job. Even in an Azure Web App or AWS instance, the additional resource requirements could negatively impact the performance of the application itself. That’s something we want to avoid at all costs.


Thanks for your reply @kyle.

I’m trying to get reports like shown below to collect number of lines executed, methods and total number of lines missed during execution and finally total coverage. I’m not much concerned about the performance since planned to use this in non production environments.



Thanks for adding the clarification for your feature idea @ssoundarajen - we’ll get that added here to the feature request.