Please, STOP adding new features
ReSharper is a great product overall, but there are quite a few annoying bugs to put up with. Please seriously consider spending A LOT of time on a release that ONLY fixes bugs - no new features. Sure, it would be an unconventional approach and your marketing department will hate you, since you can't exactly put "has less bugs" as a bullet point on the brochure, but I think your customers (developers) will appreciate it.
It has enough features already. Quite honestly, I hardly ever find myself thinking "I wish ReSharper did X" (some fancy new refactoring or whatever). On the other hand, I find myself thinking all the time "argh, I WISH ReSharper didn't leak memory so badly, I wish those damn tool windows would stay where I put them, I wish it Unit Test Runner would build the solution when needed and not build it when not needed, I wish I could switch between Debug and Release configurations, I wish IntelliSense would work first time when I type 'override'", etc., etc.
I think it's worth noting that the JetBrains support staff are great and genuinely do their best to help with problem. At the end of the day, however, there's only so much they can do to keep a customer happy when all these bugs still exists.
By the way, I would say the same thing to Microsoft about Visual Studio itself. Of course, they probably realise that if they ever released a version of VS.NET that JUST WORKS nobody would ever upgrade again. :)
Please sign in to leave a comment.
full ack :)
evgeny0 wrote:
+ 1 for that
--
Peter Sulek
terrorix@centrum.sk
XanaNews ver. 1.18.1.6
Ditto.
More speed and less memory.
"evgeny0" <no_reply@jetbrains.com> wrote in message
news:26335896.1176251977577.JavaMail.itn@is.intellij.net...
>
>
>
+1
+1
I agree with this. Please stop adding cool new features just for the features. Please, please, please fix the bugs, get R# to run fast (even on big source files) and with little memory, leave the memory to the developer to debug and run.
As said many times before, R# is great but it's come to the stage now that a lot of us can't use it anymore due to the size it takes up. It's time for a diet for R#.
Patrick
I agree with this! Please invest in bug fixing of v2.5 !!
- CamelHumps navigation (Ctrl-Arrows) has never worked
- Inserting from clipboard destroys code formatting of braces
- support for generics is buggy (Ctrl-Space on generic method inserts
brackets but not the "<...>")
Sincerely,
Stefan Lieser
Fix the bugs, pls
How many votes do I get to cast for those TWO NEW features ??
I just installed EAP build 376 and R# takes MORE memory than build 337 !
Fellas, I hate to break it to you, but that's a big step BACKwards.
In the phrasing of my people......Oy Vey
"john" <xx@xx.xx> wrote in message news:evia0n$4lq$1@is.intellij.net...
>
>
+1
Stop crying you all and buy more memory!(ow yes and stop using typed
datasets) ;-p
I enjoy all new R# features I never knew I missed :)
evgeny0 schreef:
For the record it doesn't matter. R# currently falls over WELL before most of us are out of physical memory. :(
+1 to Jeremy's comment.....
"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:32381808.1176488158216.JavaMail.itn@is.intellij.net...
>> Stop crying you all and buy more memory!
>
Hello everyone,
I'd like to clarify what is going here in ReSharper team on features, bugs
and such. I'm going to talk about version 3.0, just because 2.5 release was
all about performance and memory optimizations as well as general UI cleanup
and better VS integration. Yeah, we couldn't resist to add few nice features,
like value analysis and go to file member. These new features saved a lot
of time and prevented lots of bugs, and I hope not only for ReSharper project.
Anyway, 2.5.2 bugfix update is about to be released next week. Did you try
Release Candidate?
Version 3.0 gives many of the ReSharper features available for C# developers
to VB.NET community. Does it mean we've stopped C# bugfix and development?
Not at all. Many subsystems inside ReSharper are improved and fixed, while
we are working on VB.NET support. We also work hard to improve VS integration
and this includes commands, tool windows, menus, solution load time and so
on. We are working on refactorings for VB.NET, but this also means that many
issues with them in C# are revisited and fixed, or eliminated during engine
improvement process. We are working on search and navigation features for
VB.NET, and it also means problems in this area for C# are analysed, fixed
or improved. So, is this bug fixing or is this feature building?
It is often hard to say if particular issue is a bug or a feature. For example,
many people who tries ReSharper for the first time complain that ReSharper
"breaks intellisense". Does it? It behaves different to Microsoft style,
and often is much better. Once you learn ReSharper intellisense, you can't
use VS native one - it is way too limiting. However, we understand that people
do like their habbits and are going to implement VS-style-ReSharper-power
intellisense in 3.0. Once again, is it about fixing bugs or about new features?
I admit, ReSharper has a number of nasty problems, pursuing us from version
to version. They include OutOfMemory exceptions, naughty tool windows, solution
synchronization problems and some others. They are still there, does it mean
we don't spend time with them? No! Each release, each EAP build, each milestone
we fight them. Sometimes we have results, sometimes the problem beats us.
Why is so? Because we can't reliably reproduce most of them.
If it were something like "open this project and you get OOM", we would have
spend time - any time needed - and find the source of the problem. Rarely
we get OOM with ReSharper solution itself, but next time you open it, armed
with memory profiler, debugger or whatever - it just doesn't happen. We have
a lot of information about why it could happen, but nothing about why it
happens. And we do know, that it has nothing to do with real memory, it is
more likely to be something about COM/Native interop. Several people informed
us, that they have project which always causes OOM, but they can't send it
to us due to various reasons, be it top-secret commercial research or just
management in the way. Do you have such project, which you can send us for
investigation?
I'm not going to explain the current situation with all such bugs, it would
take a lot of time but not add any value to the reader - they are mostly
technical details about Visual Studio integration. I just want to assure
you, we spend a lot of time on bugs, on speed, on memory usage. Unfortunately,
results are not always immediate improvements, but instead a small step on
the way to a better tool. Every great journey starts with a small step, you
know :)
After all, if we stop making new features, who will lead productivity tools
camp to make developer's live better? :)
PS: You are welcome to open separate topic for each problem that causes you
to loose productivity with ReSharper, we will discuss it thoroughly.
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Hi Ilya
Let me start by stating that I love you product. But I am very troubled by
the OOM problem. I am also limited by coporate policy and cannot send our
bits to you guys. Having all these things in mind I still would like to help
you guys on fixing these issues. So ... what can I do?
Which kind of analysis would you like? Can you provide / recommend some
kind of analysis that you guys can use?
Sincerely yours
Torkil @ IBM
"Ilya Ryzhenkov" <orangy@netix.ru> wrote in message
news:9f6b3e291375168c94cba0c95c9df@news.intellij.net...
>
>
>
>
>
>
>
>
>
>
Hello Torkil,
Thank you for supporting us in our battle against OOM. We think that it is
not real low memory condition, but rather some unmanaged component (COM or
native), which raises STATUS_NO_MEMORY SEH exception, which is then converted
to OOM by CLR. It also can be E_OUTOFMEMORY returned as HRESULT. It seems,
that STATUS_NO_MEMORY is raised during some CLR housekeeping, or during native
call or COM interop on other thread, and then somehow marshalled as OOM to
different thread by CLR.
The only idea I have is that you run VS with debugger attached (e.g. another
DevEnv instance), enable first chance exception catching (Debug | Exceptions...)
for just OutOfMemoryException (put checkmark near System.OutOfMemoryException
in Common Language Runtime exceptions | System) and try to load your solution.
As soon as you hit OOM, open Threads window, go through each thread and copy
every stack trace you happen to see. Send this stack traces to me by email.
May be we can see faulting interop call on the other thread...
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Ilya, thanks for your long and detailed reply. To some degree, I understand exactly what you mean, but to some degree I also think you're avoiding the issue. It's hard to believe that ALL the annoying ReSharper bugs haven't been fixed simply because they couldn't be reproduced. I'm sure that many of them haven't been fixed because there is no time to fix them, which is because the developers are busy adding new features. That was the whole reason for this thread.
If being unable to reproduce bugs is really the main problem then I have two suggestions:
1. Post a list (in some highly visible place, not this thread) of the top-priority bugs that you cannot reproduce for users to see, so that people know exactly which bugs are not being fixed for this reason and can help with them. JIRA comments often don't mention this, so I simply assume nobody has gotten around to looking at that bug.
2. Accept that not all bugs can be reproduced "in the lab" and some will have to be debugged "in the field". That means investing a lot of developer time into building a lot more diagnostics into ReSharper. It already submits unhandled exceptions to JIRA, which is great, but obviously it only helps with some types of bugs and not others. For example, you could build a small EXE that automatically attaches to VS.NET as a debugger on start-up (when running in "troubleshooting mode") and writes a memory dump on first-chance OOM. It's a bit too much to expect customers to run VS.NET under the debugger all the time if that debugger needs to be started manually, takes a lot of memory and slows down their development, but they may well do it if it's as simple as supplying a command-line parameter and there's no noticeable performance loss. If unmanaged memory leaks are a problem then build code into the unmanaged parts of ReSharper that reports its detailed memory usage on demand. And so on... Sure, none of this is simple, but you've already fixed the stuff that's simple. Now it's time to fix the difficult bugs and really make ReShaper a solid product.
Ilya, if the faulting project cannot be sent to you, perhaps you should visit the faulting project instead? That means, fly to a developer's shop in person, armed with whatever debugging tools you need, and debug the project there? Of course, you would have to spend on an airline ticket and perhaps a hotel stay, but it might well be worth the effort. Of course you should only do this with a customer who regularly and reliably has OOM or other problems not reproducable in your lab. Often, with this technique, you are much faster than trying to reproduce bugs for weeks with no real result.
Many shops who cannot send you their source code for security reasons will happily assist you with this approach.
Best regards,
Urs
Hello,
For some reason my previous email address was used in newsgroups, please
don't send emails to it. This post should have correct email address, please
use it if you are going to send any stacktraces. Thanks.
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Just a thought - another option be for the good folks at JetBrains to create some option we could turn on to force ReSharper into a "diagnostic" or "verbose debugging" mode that could capture the metrics and any other useful info to tackle problems like this memory issue.
The "dump" of this could then be uploaded to JetBrains for their analysis without any of the content that users may not be willing/able to share.
Kirk
I have to second this.
A long time ago, in another life, our company decided to adopt a development
tool and was experiencing a weird issue/problem. It was killer for us, but
the developers of the product couldn't reproduce it. They send someone to
our place of business and waited around for the problem to occur, and when
it did, they jumped on it, saw immediately what the problem was, and had us
a fix in just a few days. It was amazing how much time was saved. It
seemed 'expensive' up front, but it probably saved tons of money in the long
run, compared to either having us reject the product because of the problem,
or spending weeks and weeks trying to get them to reproduce the problem.
"Urs Eichmann" <no_reply@jetbrains.com> wrote in message
news:14062753.1176704526885.JavaMail.itn@is.intellij.net...
>
>