使用 MSTest 和 ANTS Performance Profiler 丢失源代码

Question

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 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:

• Path to .NET executable: C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\TestAgent\\Common7\\IDE\\MSTest.exe
• Command line arguments: /testcontainer:Projeto.dll /test:Projeto.Features._001_UsuarioFeature._001_A_1_1* /testsettings:"C:\\Users\\Documents\\projeto\\TestSettings1.testsettings"
• Working directory: C:\\Users\\Documents\\projeto\\bin\\Debug

Additional info:

• We are running ANTS Performance Profiler version 10.1.5.1275

• Operating System: Windows 10 Enterprise

Answer 1

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.