UnitTestRunner hijacked my Debugger !!!!

I'm not sure what happened to cause this, nor I am sure how to fix it, but I thought it important to report this behavior.

I have a solution with several projects. Two are console apps.

On one app, when I hit F5 (or whatever) the console app launches in the VSS debugger just fine.

On the other, when I attempt to debug it, instead of launching my executable in the debugger, VS attempts to run:
JetBrains.ReSharper.UnitTestRunner.exe
In the debugger instead.
Of course this results in the following exception:

An unhandled exception of type 'JetBrains.ReSharper.Util.InternalErrorException' occurred in jetbrains.resharper.util.dll

Additional information: Exception logged


> jetbrains.resharper.util.dll!JetBrains.ReSharper.Util.Logger.LogExceptionInternal(System.Exception e = {"An exception has occurred" }) Line 360 C#
jetbrains.resharper.util.dll!JetBrains.ReSharper.Util.Logger.LogExceptionEx(System.Exception e = {"Could not find file \"C:
DOCUME1
eweinsch
LOCALS
1
Temp
tmp7A3.tmp\"." }, string comment = "An exception has occurred", bool includeOuterFrames = true) Line 334 C#
jetbrains.resharper.util.dll!JetBrains.ReSharper.Util.Logger.LogException(System.Exception e = {"Could not find file \"C:
DOCUME1
eweinsch
LOCALS
1
Temp
tmp7A3.tmp\"." }) Line 339 C#
jetbrains.resharper.unittestsupport.dll!JetBrains.ReSharper.UnitTestSupport.Runner.TestRunner.Run(string[] args = {Length=2}) Line 105 + 0x9 bytes C#
JetBrains.ReSharper.UnitTestRunner.exe!JetBrains.ReSharper.UnitTestSupport.Runner.MainApp.Main(string[] args = {Length=2}) Line 44 C#

Now, this is a problem because nothing I've tried so far has gotten my application launched back in the debugger.

Things I've tried so far:
Restarting VS
Switching the default startup project and switching back.
Changing which "Main" is being run in the project properties.
Rmoving the project from the sln and readding it.
Deleting all the bin/obj folders.

What I think caused it:
Resharper > Options > Unit Testing > Debugging Method
I switched from "Use the current startup project" (the default) to "Use the project being tested".
I don't remember why I switched this, but shortly after I did, this problem started happening.
I've switched this back, but it hasn't fixed the problem.


Please advise on how I can get my debugger working again. Any suggestions comments would be extremely valuable.

Thanks,
Eric

8 comments
Comment actions Permalink

Nevermind.

Somehow, Resharper modified the "Start Application" parameter of my Project properties. (and added command line args and a working directory).
Deleting this stuff fixed it.

But I have no ide how this happened to begin with.

0
Comment actions Permalink

This has happened to me more than once too.

---
Richard

"Eric" <no_reply@jetbrains.com> wrote in message
news:25111570.1162210798482.JavaMail.itn@is.intellij.net...

Nevermind.

>

Somehow, Resharper modified the "Start Application" parameter of my
Project properties. (and added command line args and a working directory).
Deleting this stuff fixed it.

>

But I have no ide how this happened to begin with.



0
Comment actions Permalink

This just happened to me too. Some kind of bug?

0
Comment actions Permalink

Thank you, this fixed my problem as well. Really seems like a bug of some sort.

0
Comment actions Permalink

Yep, same here, this is definitely still a problem as of Resharper 2.5.2 you end up with RUNNERARGS "C:\Documents and Settings\wrightm\Local Settings\Temp\tmp190.tmp" or something similar in the command line arguments of visual studio. Uncool.

0
Comment actions Permalink

Hello Matt,

This issue is addressed in new Unit Testing subsystem, which is being created
for 3.0.
I don't think, however, that this will make it way into 2.5 bugfix update.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


MW> Yep, same here, this is definitely still a problem as of Resharper
MW> 2.5.2 you end up with RUNNERARGS "C:\Documents and
MW> Settings\wrightm\Local Settings\Temp\tmp190.tmp" or something
MW> similar in the command line arguments of visual studio. Uncool.
MW>


0
Comment actions Permalink

I have to admit that as much as I love R# you guys are this -> <- close to losing me as a customer and long-time proponent of R# that has recommended the product to more business associates than I can count. Man, I don't want to sound like a whiny brat, but am I ever getting really tired of seeing bug reports being answered with text that essentially states "we're fixing this outright bug in the product you've already paid for, but you'll have to pay for the upgrade to get the fix."

I really, really, really don't want to come across as someone who just wants to drop by to complain. I really, really, really want to make sure that JetBrains is aware of the ways in which they are pissing off paid customers, and this is definitely another one of those cases that seems to be happening more and more often.

So, as a representative of some at least non-zero percentage of the usually "silent majority", I'd like to officially express the following: I'm getting close to dropping R# for a competitive product, even if it means losing some R# features I've loved over the years and use all the time. Why would I do this? Because JetBrains policy around fixing issues with the product leaves a lot to be desired.

Sincerely,

Jeremy

0
Comment actions Permalink

PS - to be clear, as a professional software developer I totally understand the desire to punt a fix to a future release. In fact, in my current project's late stages we are doing just that wherever possible.

That said, while I understand this from the perspective of a developer, I still have to rail at you guys from the perspective of a customer, just as there are people working within my enterprise railing on the behalf of our customers when we want to punt.

In the case of R#, I do completely understand the sitaution you face. I just happen to be on the other side in this instance. :)

0

Please sign in to leave a comment.