'boxes' bug after refactoring in resharper 5.0

I've got  a very annoyng resharper bug, I think I've met it for the first time somewhere even before 5.0 beta 1 (not sure about 4.5), and it's present in every EAP/beta build I've tried since (current is 5.0.1630).
Sorry, I'm not sure I'll be able to provide a test solution - I don't know how to easily reproduce it in empty project.
However as soon as this bug appears at any place due to some refactor action - it is 100% reproducable (so I can restart VS, clean resharper caches, nothing helps - the same action will always give us same bad result). And I still can't find what I need to change in code to make it work again.
So if I meet such situation during my work (usually ones per day or two) I just don't use resharper refactoring and perform these actions by hands.

Ok step by step:

1. We've got some source code. This particular file contains some #if regions, but the bug occurs in all kinds of files without them.

2. Ok, we've got error. We need to add usage for particular namespace, Resharper can help us with a quickfix.

3. Ok, we press alt-enter, and immideatly get the following:
4. Same boxes we've got instead of normal text from the begging of the file.

5. Pressing Ctrl-Z immideatly restores normal source code without these boxes (and without namespace quickfix too ).

Same problem occurs during all kinds of refactorings, like member rename, etc.
I attached this particular file, although I'm not sure it'll help.

Let me know if I can provide any kind of additional information.

Build 5.0.1630.23 on 2010-03-04T01:39:16

Comment actions Permalink

Ok, I was able to narrow down code (to demonstrate that problem) to 2 files (in 1 library) I'm able to share with you (jetbrains).
I just don't want to continue stripping my code just do demonstrate this bug (to be able to share code here at forum), so if your team needs this sample solution, please contact me using this address: brainsucker point na  at gmail point com.
I'll reply and send you source code asap.

I also posted issue RSP-170088: http://youtrack.jetbrains.net/issue/RSRP-170088

Comment actions Permalink


You're using UNIX line endings in the file. I'm not sure if ReSharper is
currently able to handle them correctly at all. Could you try changing these
to DOS line endings? If yes, see File | Advanced Save Options, CR-LF choice
in the line endings combo.

Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

Comment actions Permalink

Thanks for fast reply and precious information.
It seems VS 2008 is immune to EOLs style itself  (and we disabled mixed EOL warnings after first appearance) so we never noticed something is going wrong.
These LF eols most probably appeared after migration from CVS to SVN, so using of eol-style fixed that. It seems resharper is working fine with these files now.
Thanks again.

P.S. Anyway, some kind of warning from Resharper's side (instead of just replacing text lines with boxes) will be a good idea, from my point of view

Comment actions Permalink


I do not know any mechanism through which the boxes could appear in the files
on ReSharper's part. I'd rather think it's what Visual Studio text editor
renders on screen when it sees inconsistent line endings — it could go really
wild at times when line endings are inconsistent. VS2010 editor is much better
in this respect. Checking the file on disk could rule this out.

ReSharper would not issue a warning because it is usually pretty happy with
any kind of line endings it sees. The problem is when we insert new line
endings and they're not consistent with the existing ones. This (detection
of the prevaling line endings style in the file) is not implemented yet,
so once again ReSharper does not know when to complain.

Possible problems with inconsistent line endings include:

  • ReSharper and VS could rule out different line breaks for the same sequence.

Imagine some crazy mixture of \n\r\r\n\n\r, how many lines do these represent?
This affects screen things, but not code refactoring (the latter does not
know about VS line breaks anyway).

  • Visual Studio text editor on-screen rendering (most probably, those squares

represented a visual artifact and not some real code corruption; if not,
then it's a serious failure on our part).

Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


Please sign in to leave a comment.