Brace matching and references highlight suddenly stop working (VS2013)

Question

Visual Studio 2013 brace matching, references highlight, auto detect variable/,methods name changes (need to use Refactor instead), etc... are stopping to work and only work again after a VS restart. I'm writing code in C#.

Am I the only suffering/affected with this problem?

Very very annoying VS2013 problem!! It seams to only happen in large projects.

Update 1: I've realized that it happens just after I open any WinForm in VS Designer. When I come back to code editing, the brace matching and stuff is gone and I need to restart VS!

Update 2: Visual Studio 2013 Update 4 and still... NO fix!! Hello Microsoft?

Update 3: Since my solution has few votes, I'm going to summarize it here. In my case, the problem was a Thread.Sleep been called by VS Designer. It was a code error, but anyway, Designer should not run Thread.Sleep commands freezing the entire VS.

Answer 1

FINALY I found the bug !!

Well, it seams you can hack VS IDE and put it to sleep (LOL), side effects are the problems that I was experiencing, like brace matching not working anymore.

How to reproduce it:

1. Create a WinForm project
2. Create a Control
3. Add the code bellow in the control
4. Rebuild
5. Open Form1 in Designer

You will notice the Thread.Sleep in action ! Now, go back to code editing, brace matching and stuff is gone. Only way to fix it is to restarting VS.

Code to reproduce bug:

public UserControl1()
{
    InitializeComponent();
    Application.Idle += Application_Idle;
}

void Application_Idle(object sender, EventArgs e)
{
    Thread.Sleep(200); //Yeah VS IDE will sleep for 200 ms ! LOL!
}

I think VS Designer should ignore Thread.Sleep commands, shouldn't it?

Now I just check if the code is running inside VS Designer before doing my stuff by calling:

    // Return if is inside VS Designer !
    if (System.Reflection.Assembly.GetEntryAssembly() == null)
        return;

I also tried to add this code inside Form1, it seams that VS ignores the Sleep.

Answer 2

Until fix arrives, try disabling code lens.
tools->options->text editor -> all languages ->code lens

Or just kill the ALM shared Remoting task. if it is very high CPU.

Answer 3

This is a bug in Visual Studio, and sadly one that Microsoft has decided not to fix until Visual Studio 2015 according to this ticket on Connect:

We have plans to make deeper improvements, but those won't happen until the next major release of Visual Studio because we will be taking advantage of presence of the .NET Compiler Platform. While I'm closing this issue, please be aware that we have work planned for the next release of Visual Studio to correct it.

Even so, I was able to mitigate this issue enough that CodeLens is usable again (personally, I use #3 and #4):

1. Go to Tools > Options... > Text Editor > All Languages > CodeLens and make sure only the stats you care about are checked. The fewer things checked, the faster CodeLens will be.
2. Change your Source Control plugin to None. This completely resolves the issue for me, but it means losing the author/change history info provided by CodeLens.
3. After loading a solution, open Task Manager as an administrator and right-click on the Microsoft.Alm.Shared.Remoting.RemoteContainer.dll processes (there may be more than one) and Set priority to Below Normal or Low. (You will have to do this every time you open Visual Studio)
4. If your CPU has multiple cores, after loading a solution, open Task Manager as an administrator and right-click on the Microsoft.Alm.Shared.Remoting.RemoteContainer.dll processes (there may be more than one) and click Set affinity and uncheck one or more cores. (You will have to do this every time you open Visual Studio)

I have found that only #2 can resolve the issue completely, but #3 should be enough to stop the freezing caused by the process saturating the available resources, though the process will still cause high CPU utilization until it finishes processing. Your mileage may vary with #4.

Answer 4

I came across this post because I have been plagued by this problem too, and it sounds like it might be related to this bug reported on Microsoft Connect.

Unfortunately, there doesn't seem to be a good workaround to it, and Microsoft said that they will address it in a future version of Visual Studio (whether that means a new version or an update, I don't know).

User Chris Bjugstad posted a suggestion on the bug report page that may or may not help you:

I ran sysinternals procmon and filtered for this specific process. In my case the process (Microsoft.Alm.Shared.Remoting.RemoteContainer.dll) is reading/writing dlls referenced by one of my projects to a "shadow copy" folder.

%Temp%\ALM\ShadowCopies\<some_guid>

The above folder had 2600+ empty folders. I deleted the folder and VS was faster at first.

This will probably only temporarily fix your problem (if at all), until it starts building that folder back up.

Good luck!

Answer 5

I noticed this issue as well. I also noticed I was not logged in to my Visual Studio profile and once I resolved the Visual Studio online credential issue the CPU hog went away.