Find usage of one implementation

Hello,

It looks like code analysis did not work well, which can cause the wrong counter. Please check in the bottom left corner if the analysis completed, otherwise please try to restart Rider and let me know if that helps. I am not aware of such an option, if you can link where you have seen such information, that would help. 

It looks like this:

The usage on the function (at the right top part of the second image) is how many invocation of this implementation, which I think is correct.

But the find usage function will give me all implementations of IDispose.Dispose, without being catogoried by implementations.

So I cannot find which codes tried to dispose this instance, unless I remove the IDispose interface from it.

This happens on both left clicking on the usage label (like in the first picture) and shift + f12.

I think it's more about some old functions are missing in the newer versions, instead of some sort of bugs.

Edit: I cannot switch place of the 2 attaments :)

It looks a bit similar to the following issue: RSRP-474656, does it work if you try using Inspect this -> Incoming calls?

I have the exact same problem without any solution since I owned a JetBrain rider licence. (C# wpf projects)

There is only 3 usage of this Type properties for this class.

But whatever find usage option i use, it will look for every single named "Type" statement in whatever file types, witch is a lot, and take a while.
Exact same thing with rename, it will first scan the whole solution for nothing witch take hours.

Beleave me, this screen is not done yet loading ^^'
Any ideas ?

Hello Quentin,

The fix for RSRP-474656 was declined as we decided that Find Usages for references will behave extremely unpredictable if we implement it, see this comment. Please try using Alt-Enter -> Inspect This -> Incoming calls on the Type property?

Hi Julia,

Thx for your answer, it works a bit better, but still take a minute to compute. Better than nothing but compare to VisualStudio Find Usage that goes instant, it is not that great.

Is there an incomming improvement for this foncitonnality ?

Sure, we'd be happy to improve it! It would be really helpful if you could collect a performance snapshot for us. Please note that it is possible only on Windows at the moment.

1. Start Rider;
2. Call "Help -> Diagnostic Tools -> Profile Backend with Sampling";
3. Wait until you see "Profiling in progress: stop it manually" message at the bottom; 
4. Perform actions which are slow in Rider (find usages on `Type` in your case);
5. To stop profiling, call "Diagnostic Tools -> Backend: Stop Profiling";
6. At the bottom-right corner, you will get a popup with a performance snapshot file name and "Show in Explorer" link to open a folder;
7. Share the file with us via https://uploads.jetbrains.com/ form.

Thank you!

Hi julia,

I had no popup to found the folder and files, so i searched myself the diagnostic log folder.
Is it this one ? Do you need only Backend.log ?

Hi Quentin,

No, the snapshot must be saved somewhere in your %HOMEPATH%. Here is mine as an example:

Hi julia, here is the upload link for my Profile Backend with Sampling for both :
- Alt-Enter -> Inspect This -> Incoming Calls

- Clik on the above property "Usages"

Upload id: 2021_04_03_MGrEQ8spBHpp17nx (files: AltEnter_InspectThis_IncomingCalls.zip, AboveProperty_Usages.zip)

Thank you for your time.

Quentin,

Please accept my apologies for the late reply. The update on your problem is the following: `false` positive usages issue is known, see RIDER-2728. We're evaluating demand for the issue. Please leave a vote or comment if you think it should be prioritized.

If one does not specify type for a DataContext, Rider cannot understand which concrete member is specified in Path= binding. That's the reason for the problem, and I would not say that it's a bug.

__________________

What look suspicious in your performance snapshots is search in C# and XAML files takes almost the same time. There might be particular files in your solution that slows down search. If you feel like helping us to investigate it, please collect Rider trace logs:

- Navigate to `Help | Diagnostic tools | Choose Trace Scenarios` and enable Trace scenario for `SearchAndNavigation`;
- Reproduce the issue, collect the full log bundle via `Help | Collect logs`, disable the Trace scenario;
- Upload the resulting log bundle to https://uploads.jetbrains.com/.

___________________

What can improve performance in your case is excluding XAML files from navigation (if you don't need them). You can add a <solutionName>.sln.DotSettings.user file to the root of your solution folder with the following content:

<wpf:ResourceDictionary xml:space="preserve" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:s="clr-namespace:System;assembly=mscorlib" xmlns:ss="urn:shemas-jetbrains-com:settings-storage-xaml" xmlns:wpf="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
    <s:Boolean x:Key="/Default/Environment/SearchAndNavigation/FileMasksToSkip/=_002A_002Examl/@EntryIndexedValue">True</s:Boolean>
</wpf:ResourceDictionary>

I'm sorry for not getting back to you earlier with the workaround.

Please let me know if you have any questions.

Hi Julia, glad to see you again.

If you need time, then take your time. Excuses won't change much. We are looking for awnser and solutions only. Almost 3 months doesn't look that huge to me.

I am a bit disapointe to be redirected to a 5 years old back subject for something that work perfectly fine in VS since years.
I am hearing your arguments, but there is a part that is a bug for sure. You can't display "3 usages" and then when clicking on it take a minute to compute and display hundreds of them. You will probably agree that if you ask for a bread that cost 3 złote, if I finnaly ask for 400 złotych saying that "it is not a bug to me" you will throw that bread back to my face, like a deserved exception ^^
Now that we should be agree on that part, we can focus on the patern himself.

If it comes from the no DataContext files, fine, we have a reason. Now we need to be logic, what is the point to compute no DataContext files to look for properties references ? On small project or with specifc member name, it will work fine, sometime slow but with a usable result. But on big project, if we can't choose to compute or not those files, there is no point of '3 usages' preview that will turn into hundreds results.

I won't say there is legion of solutions to improve this basic feature, but there is some for sure. Like for exemple your third point <solutionName>.sln.DotSettings.user, see below.

---------------

I am always glad to try helping. We all know that it is easy to complain to support, but hard to step forward without giving him keys to work on it.
Can't complain about my customers feedback, if I am not helping you more than they are on my own software's feedback.

I tried to do it on a new openned rider instance. Logs name match as previsously.

Upload id: 2021_05_26_PQRw9ct6ZEZgZ17P (files: AboveProperty_Usages (2).zip, AltEnter_InspectThis_IncomingCalls (2).zip)

---------------

I just set it on, it seems to be working better for at least 'above property usage'. Can't speak more about it, I need more test, and can't realize fully yet what will be impacted. Also my team will have to try it too and share feedbacks.

Thanks again for your time.

(Additionnal information, prewiew usage results and final result is still not accurate. 3 for 4)

Quentin,

Thanks for the explanation, I like the comparison with złote a lot.

Thinking about all around this preview-result problems, I agree that there definitely is a bug from a user perspective. Perhaps it's rather a usability problem, I'll explain why.

In Rider, the code lenses (including the preview for usages) are calculated during Solution-Wide Analysis. When you click on a preview for usages, Rider calls a completely different feature named Find Usages. The latter tries to be as smart in finding tricky usages as it can, while Solution-Wide Analysis doesn't go this deep. As a result, preview is not always in line with the list of usages. This is how Code Vision feature in Rider has been implemented from the very start of it, and it is by design.

The first problem: one doesn't expect to see a list of 400 items when preview says there are 3. I believe it will be fixed when Find Usages list can send these 397 results to a special "more" section at the bottom of the list. I've created a new issue because the old one is about Find Usages tool window. Here it is: https://youtrack.jetbrains.com/issue/RIDER-63326. Add an option to filter out these usages completely is also a solution. Let's see what developers will say in the issue.

The second problem: you have to wait until Rider calculates all the usages. The logs shows that there might be a performance problem in Rider. I'll follow up on that in DM. We'd be happy to fix it!

The third problem is on your last screenshot (3/4 results). Sometimes virtual methods can cause this. Is it your case?

Julia,

None of my 4 methods is virtual. If it can help, they come from same namespace, all included in regions, 4 differents classes, 2/4 are sealed, 4/4 are inheriting, 1/4 is inheriting with template. Here come the witch hunting.

Quentin,

I'm afraid I won't be able to reproduce the issue based on this information. If you could reduce this case to minimal repro project, it would be great. With the repro project we can reach out to the developers team and ask to align the preview and the resulting list.

Julia,

I did multiple tests, wasn't hard to know from which file it was comming from, but wasn't able to understand what was the difference between those 4 files. But I finnaly founed it. Looks like it come from "No analysis has been performed (Document size has exceeded the threshold)".

Quentin,

Great! Indeed, Solution-Wide analyses skips large files for performance reasons. Does it help if you turn on highlighting on that file as described here?

Julia,

I had some strange behaviors but proably due to the analyse time. After some more test, I am now on '4 usages' preview, and 4 real usages.

Quentin,

You didn't turned on highlighting for the large file, do you? Do you mean that the issue isn't reproducible anymore?

Julie,

I did turned on "hightlight: All problems".
Even if strange behaviors appear at first, the issue looks no longer reproducible.

I'd say we can close this thread. The first two problems are tracked on YouTrack, the third is kind of solved. What do you think?

I do agree