Open AnthonyDewhirst opened 3 months ago
Hey @AnthonyDewhirst, I'll take a look at this. Just curious, what is the reason for you to enable the Service Profiler during a test?
Hey,
If you look at the linked code, it's for a grpc test, so you link to the web project and reference the real c# Startup code. So you get the service as you normally would. As in, you are pretty much testing the real set up.
Hopefully that makes sense?
This looks like a reoccurrence of #186
To Reproduce Here is the code for a simple repo:
one tests passes then the other fails.
Expected behavior Both tests should pass
*Additional details Granted, this is not a normal usage - but we have gotten here because we are using Grpc test fixtures which boils down to doing the above using steps similar to here microsoft guide
My guess right now is that the static instance behaviour of Microsoft.ServiceProfiler.Utilities.CurrentProcessProvider in Assembly: Microsoft.ServiceProfiler.Common.Utilities, Version=2.6.2403.1501, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a captures the process once in the Lazy. And then when the services are configured for the second time, the process is no longer correct.
For now in the test code I have a dirty hack to inject a dispatch proxy in there instead which just returns 1 for the process id on all calls. Had to go this way as the interface is internal :-(
On a complete side note, Checkmarx is warning of a transitive dependency to Microsoft.IdentityModel.Tokens 6.11.1