Hi everybody,

We have now tested the official release of .NET Core 3.1 and we can confirm that the fix is included. Our recommendation is all projects experiencing the issues with the debugger arrowhead to be migrated to .NET Core 3.1.

I will change the status of this item as declined as it is a duplicate of already existing one. Here is again the link.

Regards,
Mihail
Progress Telerik

Hi,

@Koushik, as you pointed out we already have this issue logged in our feedback portal. We are absolutely aware of the impact it has on JustMock and on the ability of the developers to write and debug unit tests.

This is why six months ago when we found out about the problem we contacted Microsoft and they confirmed that the problem is in the CLR. Here is a link to the bug report item in the CLR if you are interested. Please have in mind that most of the communication was in a private channel to protect our intellectual property. 

Since then we have tried to implement numerous fixes and workarounds on our side to overcome the problem. Some of them were suggested from MS. Sadly with no success. By no success, I mean that everything works as expected and by our standards for all supported features.

Happily, the problem was fixed by MS. However, the MS process of including an already confirmed fix in an official release is kinda cumbersome.
The good news is that we have confirmed that the latest .NET Core 3.1 preview includes the fix. If you are at the development phase of your application I would recommend you as a workaround at this point to use this version. Later when the official .NET Core 3.1 version is released (December 2019) you could switch to it.

Regarding older versions of .NET Core, we have tested a custom builds for 2.1(LTS) and 3.0 and we have confirmed that the issue is fixed there. However, we do not have any specificity when the fix will be included in the mentioned versions.

Regarding your question of why a profiler is needed for elevated mocking (static, private, non-virtual, etc), I will try to briefly explain it. 

To create its mock object and all arrangements related to this mock object a mocking framework has to inherit a specific class and override the required method or property.

I will first start with how the free version, JustMock Lite works. To create a mock object and all arrangements related to this mock object JustMock Lite has to inherit a specific public class or interface and override the required method or property. And what can be inherited in C# and VB roughly are public interfaces, abstract classes, and virtual methods or properties. In essence, the implemented logic for each mocked method is simply adding a conditional check and it goes like this: If there are any arrangements for this method process them, otherwise call the original code.

The approach with the inheritance is limited to what can be mocked as I already explained. And elevated mocking (static, private, non-virtual, etc) can't be performed due to this limitation. This limitation is solved by JustMock which is a paid version.

JustMock is based on JustMock Lite and uses the same approach for public interfaces, abstract classes, and virtual methods or properties. To support elevated mocking JustMock has to add the conditional check that was already mentioned to static, private, non-virtual, sealed or other third-party API. This additional code has to be added before the JIT compilation is done by the CLR and this can only be achieved through a profiler.

@Sourav I completely agree with you. A flowless debugging should be available for all development products. You should also have in mind that the position of the debugger arrowhead pointer is calculated and provided by the .NET CLR to the Visual Studio debugger. And if there is a bug in the calculations what we can do is cooperate with MS to fix it as soon as possible. This is exactly what we have done.

I hope this information answers your questions.

Regards,
Mihail
Progress Telerik