Hello,
We're encountering the following type of error on our build servers:
X SendFile_GivenValidInformation_ShouldReturnSuccessResult [1ms]
Error Message:
Initialization method InsuranceApiLibrary.Syncronizers.<<redacted>>Tests.Setup threw exception. Telerik.JustMock.Core.ElevatedMockingException: Cannot mock '<<redacted>>SoapClient'. The profiler must be enabled to mock, arrange or execute the specified target.
Detected active third-party profilers:
* C:\Users\<<redacted-tfs-agent-service>>\.nuget\packages\microsoft.codecoverage\16.4.0\build\netstandard1.0\CodeCoverage\amd64\covrun64.dll (from process environment)
Disable the profilers or link them from the JustMock configuration utility. Restart the test runner and, if necessary, Visual Studio after linking..
Stack Trace:
at Telerik.JustMock.Core.ProfilerInterceptor.ThrowElevatedMockingException(MemberInfo member)
at Telerik.JustMock.Core.MocksRepository.Create(Type type, MockCreationSettings settings)
at Telerik.JustMock.Mock.<>c__DisplayClass47_0`1.<Create>b__0()
at Telerik.JustMock.Core.ProfilerInterceptor.GuardInternal[T](Func`1 guardedAction)
at Telerik.JustMock.Mock.Create[T](Object[] args)
at InsuranceApiLibrary.Syncronizers.<<redacted>>Tests.Setup() in E:\AzDOS\Agents\Alpha\_work\8\s\<<redacted>>\<<redacted>>Test\Syncronizers\<<redacted>>Tests.cs:line 27
When we exclude code coverage, we get very similar errors, but without the lines about detected third-party active profilers. I have directly verified that the JM profiler settings are correct (see attached images).
Our build servers have Visual Studio Enterprise 2019 16.4.2, .NET Core SDK 3.1.100, and JustMock 2020.1.113.1 installed. The C# projects in question target .NET Core 3.1. The path to the JM DLL being referenced by those projects is "C:\Program Files (x86)\Progress\Telerik JustMock\Libraries\netcoreapp2.0\Telerik.JustMock.dll". I can find no obvious alternative path or DLL for .NET Core 3.x, so I assume that DLL applies to multiple .NET Core major versions.
This problem is blocking new initiatives. Thanks in advance for any assistance you can provide.
Regards,
Tom Slavens
Platform Configuration Architect, Software Services
Veterans United Home Loans
7 Answers, 1 is accepted
Hello Tom,
I have managed to reproduce a similar behavior on the command line. I will need some additional time to take a deeper look at the issue and will come back to you with my findings in a day or two.
Regards,
Ivo
Progress Telerik
Hello Tom,
I forgot to ask you which version of TFS version you are using. Also, it would be great to share more details about the task configuration. We have discovered some issues in the integration with Microsoft Code Coverage when it is used as NuGet package and we need to investigate them further.
I look forward to your reply.
Regards,
Ivo
Progress Telerik
Rank 1
Ivo,
We're using on-prem Azure DevOps Server 2019u1 with on-prem agents v2.153.1 on Win2016 VMs.
The task which spurs the errors is the built-in "dotnet" task using the "test" command and these additional arguments:
--configuration $(BuildConfiguration) --no-restore --no-build --collect "Code coverage"
The restore and build occur (successfully) in preceding task steps in the build definition, the standard NuGet task and the standard MSBuild task, respectively.
The .csproj file in question has these references:
<p> <ItemGroup><br> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.4.0" /><br> <PackageReference Include="MSTest.TestAdapter" Version="2.0.0" /><br> <PackageReference Include="MSTest.TestFramework" Version="2.0.0" /><br> <PackageReference Include="System.Security.Permissions" Version="4.7.0" /><br> <PackageReference Include="__redacted__internal__package__" Version="0.0.0" /><br> </ItemGroup><br></p>
The AzDOS agent VMs were upgraded to .NET Core 3.1.1 this morning due to the recently announced CVEs in 3.1.0, and I have just verified that the errors still occur as originally described.
Regards,
Tom Slavens
Platform Configuration Architect, Software Services
Veterans United Home Loans
Hello Tom,
Thank you for the provided info, it helps us a lot during the investigation. Here are our findings so far, I split them into two categories, it seems there is more than one issue:
Run tests without coverage
Most probably the issue was caused by the missing environment variables required of JustMock profiler, more details can be found in this documentation article. To solve this issue, just add the following variables to the build definition:
JUSTMOCK_INSTANCE=1
CORECLR_ENABLE_PROFILING=1
CORECLR_PROFILER={B7ABE522-A68F-44F2-925B-81E7488E9EC0}
COR_ENABLE_PROFILING=1
COR_PROFILER={B7ABE522-A68F-44F2-925B-81E7488E9EC0}Run tests with coverage using DataCollector
This case is much complicated and it is hard to be explained in detail without referring VSTest internals. Briefly, the root cause of the issue is that JustMock configuration gets inapplicable if the code coverage is enabled via data collection outside Visual Studio, a special .runsettings is applied in this case instead. JustMock R1.2020 release delivers integration with Code Coverage for .NET Core inside Visual Studio, but some additional code changes are needed in order to have this functionality running standalone on the command line (or dotnet build task). We are going to release these changes in a service pack shortly, but until then I can provide you a custom build for testing purposes, let me know if you are interested in this option.
I hope the provided information helps. I will be glad to assist you further.
Regards,
Ivo
Progress Telerik
Rank 1
Ivo,
Thanks for the rapid turnaround on this issue!
I was unaware of the two CORECLR_* environment variables. Adding those two vars allowed the "dotnet Test" task to succeed without code coverage. I will test again late tomorrow or Friday after the AzDOS agent VMs are updated with the latest VS 2019 (due to the recent CVEs), but I expect no further problems there.
Regarding code coverage and a custom build of JustMock: While I am willing to run it for QA purposes if you think that would help your team, for our production use, we will wait for a proper release which includes the fix, and until then we will forego code coverage in our handful of .NET Core 3.1 projects.
Thanks again for your outstanding responsiveness!
Regards,
Tom Slavens
Platform Configuration Architect, Software Services
Veterans United Home Loans
Rank 1
Ivo,
I just looked at the article you had linked, but it has not yet been updated to include those two CORECLR_* environment variables. Thought you should know.
Regards,
Tom Slavens
Platform Configuration Architect, Software Services
Veterans United Home Loans
Hello Tom,
I am glad to hear that the provided solution works for you. Regrading documentation, I completely agree with you that our documentation is a bit outdated on this topic and requires improvement.
About the custom build, our intention was to address the potential emergency in the code coverage issue on your side and to receive some early feedback on the code changes we are going to introduce, so I am leaving the decision up to you.
It was pleasure for me to assist you. Wish you a great day.
Regards,
Ivo
Progress Telerik