Cannot remove Resharper from startup

Using Build 256 in VS2005. No matter what I untick in the addin manager Resharper will always load. My only solution appears to be complete uninstallation.

Why do I not want it loading always? Because its just so damn slow - you guys have traded the "slow solution load time" for "slow all the time". I appreciate some people may load up VS.Net once a day and they are less bothered by the extra seconds. For the rest of us who work on multiple projects all day long, or equally in my case also write our own add-ins which mean every time we go into debug mode we have the interminable wait while another VS.Net instance starts and we see "Resharper initializing menus". On top of that its so slow intercepting keystrokes within the IDE. This is on a three monitor system running each screen at 1920x1200 btw. Uninstall Resharper and life returns to normal acceptable performance.

Why is this? Sadly it appears you have ruined what was for me (and many others) a great product prior to 2.0. Please do yourselves a favour and get rid of the bloat - make it possible to not have loaded all the stuff many of us didnt want, ask for or are going to use (unit testing, asp.net stuff for those of us doing only winforms/backend development) etc. I've read the other threads where the answer is "throw more hardware at it" - well quite frankly for those of us working in very large companies with standard developer desktops these things dont happen overnight, nor are they going to roll out a new platform just for a badly architected addin.

If I sound bitter its because like so many others here I am so disappointed - I have sung the praises of Resharper to everyone that would listen for the 1.5 versions, convinced them to put up with that painful "loading caches" delay and the horribly slow intellisense because it was pretty solid bug wise and of the "promise" of 2.0 improving things. Instead 2.0 is just horrifically slow all the time - on top of which Resharper throws all sorts of exceptions under the covers which means if we turn on "break on exception" we get loads of Resharper exceptions popping up and asking for class files before even remotely executing my own code.

Is there any light on the horizon? Do you guys have a plan to do something about the performance? I don't think many Resharper users would argue that you have some of the most compelling features on the market, and you put to complete and utter shame the pitiful efforts by Microsoft with its code snippets, refactorings, resolve usages etc. However I really can't recommend to the guys in my and other teams at this point that they install Resharper 2.0 as it has had such a negative impact in VS2005 performance.

Anything you can tell us to give us hope? I don't want to have to start us looking at alternative products as I know we are going to have to "give up" features we know and love from Resharper 1.5.

Many thanks for a reply.

2 comments
Comment actions Permalink

The chirping crickets on this thread makes it painfully aware that the JetBrains gang doesn't realize (doesn't care?) that they are ruining the ReSharper product. It concerns me that they don't 'get it'. At the very least they ought to be acknowledging serious problems with the 2.0 product and place a warning on their downloads page, which is still putting out build 249 (aka Bug City), that version 2.0 isn't quite ready for prime-time. It's absolutely irresponsible for them to not have a message like this -- save some user frustration for pete's sake!!!

0
Comment actions Permalink

Right there with you Tim - the product has clearly gone way down in many people's opinion by the forums alone, let alone all those who don't even bother to complain. Like many people when I first saw VS2005 I wished Microsoft had just integrated the offering from JetBrains compared to Resharper 1.5 - in hindsight that would have been a big mistake. To be fair its hard to know exactly how much of the problem is JetBrains vs VS2005 which is a bloated slow pig in it's own right, let alone when you put Resharper on top of it. The VS2005 IDE has plenty of bugs which can't make it easy for these guys either.

That said, using process explorer I can see CPU usage jumping anywhere up to 40% every time I hit a keystroke in the IDE as Resharper "parses" my input - that's just complete rubbish. On top of slow load times, numerous bugs, crashes of the IDE one of every five times I exit - oh yeah, we have supposedly finished the EAP "alpha" program and are into stable releases now right?

In answer to my own original question, there is a way to force Resharper to not load using the registry - change the LoadBehaviour to 0 under Visual Studio\8.0\Addins. You get your relatively lightning fast VS.Net startup times back, and if you hit a Resharper hotkey you get (eventually) Resharper. You don't half notice the difference at startup...

At this point however like others have commented I consider the product unusable in its current state (as of build 257) and its been uninstalled and I have rolled back to 1.6.5 for VS2003. I'll keep an eye on the forums "for miracles" but given the cone of silence from JetBrains to these issues on the forums I don't see much choice but to start evaluating other alternatives for VS2005 for our teams. Perhaps I am being too harsh in expecting replies - with 4,500 "issues" on their Jira site clearly these guys are snowballed. That's what happens when you take your eye off the ball - imho from the outside they got way too greedy with new features for their "first" VS2005 version, appeared to have made some awful implementation decisions and its bitten all of us users. VS2005 has been out for nearly a year now and we STILL don't have a stable first release Resharper product! I keep thinking perhaps "some" of that blame lies with Microsoft for the "infinite developer resources but buggy, slow, cr*p result" they produced - but if thats totally the case then JetBrains had better put the message out, as right now we blame you (and our purchase orders will go elsewhere).

0

Please sign in to leave a comment.