Reputation: 109
We're working on a project for a customer that uses ASP.NET C# with EF 6 and .Net Framework 4.6.1. We have some Integration Tests and Unit Tests which are running a bit slow, so we decided to run a profiler. In our searches, we came across ANTS Performance Profiler and decided to give it a go.
We created a profiling session with a .NET executable and configured the profiling mode as line-level & method-level timings - All methods inc. framework
. However, when running the profiler we don't see any of our methods and are faced with the error message
The profiler did not find any methods with the source code. To see all profiled methods, in Display Options below select 'All methods.
How can I solve this?
We initially experienced this problem using VSTest and then decided to change to MSTest, since it seems to have a better documentation (1). It also didn't work.
We did some investigation and tried a few links (2) (3), but none of them helped.
We found out that a possible problem was ANTS Profiler not locating the .pdb
file. However, we verified that the .pdb
file exists in the same folder and has the same name as the assembly's DLL. We also ran Process Monitor and confirmed the process MSTest.exe
is reading the correct .pdb
file
Here are the startup options:
C:\Program Files (x86)\Microsoft Visual Studio\2017\TestAgent\Common7\IDE\MSTest.exe
/testcontainer:Projeto.dll /test:Projeto.Features._001_UsuarioFeature._001_A_1_1* /testsettings:"C:\Users\Documents\projeto\TestSettings1.testsettings"
C:\Users\Documents\projeto\bin\Debug
Additional info:
We are running ANTS Performance Profiler version 10.1.5.1275
Operating System: Windows 10 Enterprise
Upvotes: 1
Views: 284
Reputation: 109
We got in touch with RedGate Support and they solved our problem.
Running the profiler with the /testcontainer
command line argument by itself worked! Turns out the /testsettings parameter was the one causing the malfunction and then, once I removed it, the profiler was able to see the source code.
Obs: The /testsettings
argument was required after we changed our testing tool to MSTest. It was responsible for referencing some of our dependencies. After removing the parameter, the solution was to hardcode the path of our dependencies, just for the sake of the test.
Upvotes: 1