IntelliSense randomly stops automatically displaying (Resharper 6)

Hi Andrey,

Have you managed to reproduce the bug?

Hello
     I'm afraid we haven't managed to reproduce this behavior yet.

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

Hello Scott
     Could you please attach a small sample solution with that specific dll which would demonstrate this behavior? Thank you!

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

If you haven't been able to repro, why haven't you asked for assistance?

I exclusively see that problem when working within an MVC3 project.

I have ReSharper 6.1.1000.82 installed

I have the following VS Extensions installed:
.NET Reflector
JScript Brace Matching Extension
JScript Editor Extensions
JScript IntelliSense Para Extension
JScript Outlining Extension
JScript Work Hightlighter
PowerCommands for Visual Studio 2010
TFS 2010 Power Tools
StyleCop 4.7 w/ReSharper integration enabled

What about the Statement Completion settings showing as unticked immediately after opening a project (fields "Auto list members" and "Parameter information" under Tools | Options | Text Editor | C#)?

For me...
When I first start any project, the statement completion will be working but if I look at the settings they show as UNTICKED.
When I close the project the settings now show as ticked.
And again after opening the project, they are unticked again.
So the cycle continues.

If I suspend ReSharper when the options are unticked, the settings will now show as ticked (after closing and reopen the Options screen).
And similarly when I resume ReSharper they are unticked again.

I can reproduce this with any project, even if I create a new C# Console project with no code other than what the template gives.
This behavior does not happen with ReSharper 6.0, only 6.1.

Unfortunately not. The dll in question is made up of a collection of proprietary types. I'm happy to run a custom resharper install if that helps.

Hello
     This behavior is normal if you have 'Use IntelliSense features of ReSharper' selected under ReSharper | Options | IntelliSense | General, because then ReSharper automatically disables the 'Auto-list members' and 'Parameter information' options inside Visual Studio (and restores them when you suspend ReSharper). Do you experience problems with IntelliSense immediately after opening a solution or it starts happening after some time? Thank you!

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

Hello Steven
     Thank you for this information! Have you noticed any certain actions or conditions which lead to problems with IntelliSense? Have you tried switching to built-in Visual Studio IntelliSense?

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

Hi,

Guys, Thanks for the help. But unfortunately I can't reproduce it on our side. Tried with the R# 6 release and the latest R# 7.0 EAP builds and VS 2010 / VS 2012. Someone, please provide us with any simple DLL or project which causes R#'s intellisense bug.
Here it is http://youtrack.jetbrains.com/issue/RSRP-306788
Great thanks in advance!

Kirill Falk
.NET Team QA Lead
JetBrains, Inc

I think I finally worked out where Resharper is failing for my case (which may be a separate problem to others as it's not intermittent).

It involves a project that generates classes from templates. In the project I have the templates. I do not have the generated cs files. Visual Studio (with Resharper suspended) handles this just fine, resolving the types from the dll that is built with the generated classes in other projects.

Resharper fails miserably, and worse it hides the fact that VS is able to resolve the types, forcing me to hit Ctrl+J to get to the valid intellisense info.

If I add the generated cs files to the project, the sea of red I am currently confronted with from the unresolved types goes away. However that is with the cs files Build Action set to 'Compile', which isn't what I want as my build rules do that directly (template -> cs -> build) in one step. If I set the Build Action to 'None' for the generated cs files, I once again am engulfed with errors. See attached VS scroll bar map to get an idea of the ugliness.

Is this expected behavior? Is there a potential workaround?

Thanks

Scott

I also tried referencing to the compiled dll for the problematic project rather than the project itself to see if that would help. That works intermittently but not consistently, so isn't a workaround.

The first time I changed from referencing the project to referencing the dll it worked and resharper was able to resolve types in that dll.

I tried on a second project and it didn't work - resharper was still unable to resolve the types.

I went back to the working location and repeated the steps and this time it didn't work.

I've tried solution rebuilds and deleting the _Resharper.* directory but can't seem to get it to consistently work.

Hopefully you can make more sense of what is happening under the covers than I can, as I would have assumed pointing it at the dll not the project would take any differences due to cs files being generated or not out of the picture.

Finally found a way to work around things. If I Unload the problematic project in the VS Solution Resharper, Resharper can once again resolve types.

Based on that I'm going to assume it's looking at the content of the csproj and not handling a mismatch between the types defined directly in the files included there, and the types that actually exist in the dll that gets built for that project.

--
Side note if anyone else has this issue: Assuming project X is 'bad/problematic' and Resharper can't resolve the types it has in its dll (lets call it X.dll), and project Y references project X (references the project itself not X.dll directly). That will mean that in project Y's code, types from project X will show up as unresolved if Resharper is on, and resolved if it is off.

1) Build the Release version of project X,
2) Unload project X,
3) Resharper should again be able to resolve the types, and you should be able to build project Y. VS seems to default to using the bin\Release directory for a project that is referenced but currently unloaded.

Scott, thank you very much for such deepest investigation. I'll try to reproduce it on our side, but by the way, is it possible to send us your working solution or strip it down to a smaller one ? It will be very helpful for us.
Thanks in advance!

Kirill Falk
.NET Team QA Lead

Easy to repro.

Assuming project X has a number of files, and project Y references project X. Both are library projects (i.e. build a dll)

1) Build project X release version (so that the dll can be found when you do #2 below as VS looks for the Release output in that case)
2) Exclude one of the cs files from project X. Now the types defined in that file should not resolve in project Y.
3) Unload project X. Now the types should resolve as they will be coming from the dll built in step 1

Scott, it works for me in such case. Tested with the latest R# 7.0 EAP build. Could you please try it and let me know.

Where would I get that from? We have a R# 6 license, and I don't see any mention of R# 7.0 on http://www.jetbrains.com/resharper/

Hi,

Here it is http://confluence.jetbrains.net/display/ReSharper/ReSharper+7+EAP

Kirill Falk

Before I go through the back and forth required to install a totally new R# version, test this, revert to old version, hope settings for old version weren't screwed up by installing new version fun, have you been able to repro on 6.1 or not?

I have created a VS solution for you that simulates my failing setup.

Solution has 2 projects.

InputLibrary contains a custom build rule that simply copies InputClass.input to $(IntermediateOutputPath)\InputClass_generated.cs and adds that to the files to compile (this simulates code generation of a cs file from an input file), and builds a dll from that.

UseInputLibrary also builds a dll and just has one cs file (TestUserClass.cs) that uses the class in InputClass.input, and references the InputLibrary project.

In TestUserClass.cs the types defined in InputLibrary do not resolve unless you do one of three things (any of them will work).
  - suspend resharper
  - unload the InputLibrary project
  - add the generated file (e.g. obj\Debug\InputClass_generated.cs)

Same behavior with R# 6.1 or 7.

I tested using R# 6.1 on 64-bit Windows 7, and R# 7 on 64-bit Windows Server 2008

Zip of this setup is attached.

Scott,
the scenario you're using is not supported by ReSharper. The problem is that the file you are generation never appears in Visual Studio's solution explorer and it is the only place where we are obtaining project structure from. The workaround could be if you add generated file to the project and alter .csproj file to generated its content while pre-build step. Thus ReSharper will pick up the file properly. Anoter option would be to unload the project with generated file after build - in the case ReSharper with use classes from .dll and will work properly (but you won't be able to refactor classes from the unloaded project.

It seems pretty wrong (to my thinking) that R# makes things worse in this situation. It actively hides types that VS can find (as demonstrated by turning R# off). I can understand that this isn't an expected setup, but I don't understand why R# doesn't let the VS resolution of the types be seen by the user?

Alternatively, why can't R# look in both the csproj and the produced dll for types? Why does it have to be one or the other?

I care more about not seeing incorrect errors (without resorting to workarounds to hide R#'s bad behavior) than about whether R# gets all the types though.

Scott,

I completely understand your concern but due to architectural reasons currently we cannot support the scenario.
Sorry for inconvinience.

I have not found any specific actions that cause ReSharper to stop working. Currently, I am suspending/resuming R# at least 4 times a day.

Removing VS extensions made no difference in having to suspend/resume R#.

One nice thing I have found is that if you click "Ok" too quick after clicking "Resume", VS will hang and you have to kill the process. Awesome! So either be patient when resuming R# and wait for it to finish before clicking "Ok", or make sure all your files have been saved beforehand.

I have been using R# since 1.x, and this is the first time it has ever failed me so significantly.

If we talk about projects that reference the one of the kind, you may build the project and unload it. At the moment ReSharper switches to the project's output and the symbols in other project become resolved. But there is no workaround for unresolved symbols within such project.