Visual Studio 2017 : "We've noticed that extension 'Oxygene Editor Extensions' is slowing typing performance"

Carlo,
I’ve opened the solution, defined the new control, certainly compiled the project with the controls.
Then, I’ve opened the generic.xaml file to register the new control and the delay was while I entered the reference to the new control.

To reference the new control, I’ve duplicated a line with another control and the delay was when I was editing the path of the control template. When the delay comes, the path was not correct, as it’s impossible to have a correct path while editing.

I also sometimes have VS freeze when opening an XAML file. As there are others that have the same problem (and not working with the elements compiler), I don’t know whether the problem is VS, the Telerik controls or the Elements compiler.

Additional notes about slow downs:

  1. When switching from debug to release (or the other side), VS often freeze for about 30-40s.
  2. At the end of a compile, VS freezes for some seconds.
  3. Sometimes when I publish the web service, VS freeze for about 10 seconds after I press the “Publish” button.
  4. After long sessions in VS, it seems that it slows down, sometimes with CC no more working (memory usage?).
1 Like

Thanks; this will help us narrow it down a bit.

This morning: opened the web service solution, just rebuilt it. At the end:
image

Does disabling the Welcome dialog, if you have that enabled, are this emessagerror go away?

I have a feeling (we’re investigating) that VS is counting the time that that dialog shows as “blocked main thread” (because its a model dialog), even if its not really a delay…

Marc,
As I directly open the solution with a right clic on the VS icon, the Welcome dialog is not displayed. But the last message is at the end of a compile, not when loading the solution.

Ok, thanx. I assume there’s an actual period when VS hangs during/after compile (that said, I don’t recall VS ever not being unresponsive during compile, whether using Elements out VC#. one of the things I hate about it… :wink:

the “pause after build” thing is on my list, but probably won’t make it for the build tomorrow. I don’t dare doing fundamental changes like this on build day.

2 Likes

Just now, VS has freezed when compiling (first compile after switching from release to debug, ASP.NET web site). I had to kill it and restart VS.

Next time this happens, can you attach a second copy of VS as debugger and see what its stuck on? This is a web project that compiles to a .dll I assume, not a web “site”?

No its a “web site”, started in 2009, and never had the time to convert it…

Ok, so it’s should not actually be compiled inside VS then, but deployed as standalone files?

Marc,
it’s an ASP.NET web site working as a web service. Development started before ASP.NET web application, MVC, … exists. It consists mainly of 3 entry points and two aspx page. So about 99.9% is compiled in assemblies.

Ok, those assemblies are regular “library” projects then, used by the .aspx?

Exactly

1 Like

Just returning to this topic after a few months as we’re still seeing freezes and slow downs in VS while editing (using build 10.0.0.2461). Some of them are significant :-

Others less so.

If I had to generalise, it seems to be the bigger the unit the bigger the opportunity for delay. Some of the delays appear linked to the intellisense or editor trying to make sense of things, particularly when there are a lot of case statements, potentially nested and no matching “end” on case or block of code. In such cases, keyboard strokes can be delayed appearing in the editor by several seconds. Even a single work will appear a-s-i-n-n-g-l-e character at a time, very slowly. Once the code block is completed, editing speed generally returns to “normal”.

Unfortunately, I don’t have any test code to show this, just production code.