Building a solution fails from time to time after upgrade to R# 8.2.0.2160

Hello,

VS 2012 v11.0.61030.0
R# 8.2.0.2160

At my company we have a large solution (circa 80 projects) which are a mixture of C# and F#.
We have started upgrading to R# 8.2 and are seeing some problems from time to time when building the solution.  This does not happen at all for developers that are still using R# at earlier versions, upto and including 8.1.

This is what happens:
The developer is making changes to a C# project, and building, debugging and running unit tests.  Everything is ok.
The developer makes an inconsequential change to a C# source file and attempts to run the unit tests again.
The environment attempts to re-build the solution and it fails with a couple of errors.  The error message concerns a failure to find an F# assembly in a particular location.  Note that the particular location is COMPLETELY WRONG, being way too close to the root of the relevant drive (e.g. the F# assembly lives in C:\a\b\c\d\e and the environment is looking for it in C:\a\b)
Trying to build again produces a greater number of errors.  As each attempt is made, the number of errors spirals (I've seen over 1000 eventually).

Here's the strange thing, and the reason I'm raising this issue on this forum:
The only way found to resolve the issue so far is to disable and then re-enable R#.  Usually after doing this the solution builds fine, until it randomly fails again sometime later.  I say "usually" because on one occasion I have also had to stop and restart VS after disabling and re-enabling R#.

I have also noticed that when I come to commit changes sometime later that sometimes there are temporary files (2x .TMP files) that have been produced by R# that suggest that it has managed to corrupt its user settings file for the solution at some point.

Might this issue be connected with the issue "ReSharper 8.2.0.2160 Breaks Solutions" elsewhere on this forum?

I haven't yet managed to come up with a consistent way to reproduce the issue yet, so cannot post them here.

10 comments
Comment actions Permalink

More information:

As per one of the replies in "ReSharper 8.2.0.2160 Breaks Solutions", I too now have Debug folders randomly scattered throughout my source tree.  All of our projects are setup to output to a single Debug folder.  Following the upgrade to R#8.2 I now have at least three erroneous Debug folders.  Fellow developers using earlier versions of R# do not have these folders.

Regarding the failure to compile after an apparently minor change to the source code that I originally reported:
Every now and then after a build, VS2012 remains busy (CPU usage).  I suspect that R# is performing some background work.
My subsequent build attempts fail whilst this background work is being performed.  If I wait the three or four minutes that it takes for the CPU usage to cease, my builds succeed again.  Pausing and Resuming R# via the VS2012 Tools | Options route aborts this background work and is a quicker way to get back to successful builds.

I have attached an image of the two failures that I get the first time a build fails.  The "ThirdPartyBinariesCommon" folder is actually located at C:\AaaProjects\Arieso\Malachite\ThirdPartyBinariesCommon on the file-system.  Repeated build attempts whilst the background processing is active see the number of errors escalate exponentially.

Often when the build is failing during the background work, R# corrupts my solution user file.  I have attached the Backup and Description files that are produced when this occurs.  After this I get all sorts of screwy behaviour until I close down and re-start VS2012.

I may soon revert to R# 8.1 if these issues cannot be sorted out quickly.



Attachment(s):
Infrastructure.sln.DotSettings.user.Corrupted.2014-04-07T16-06-15.Description.Tmp.zip
Infrastructure.sln.DotSettings.user.Corrupted.2014-04-07T16-06-15.Backup.Tmp.zip
VS2012TwoErrors.png
0
Comment actions Permalink

Could you please try the private build from here http://download.jetbrains.com/resharper/ReSharperSetup.8.2.0.2681.msi? After installing this build, please turn OFF R#->Options->VS Integration-> Use msbuild to obtain project references. Then remove all folders which were created by failed builds (also remove something like C:\Program Files (x86)\Microsoft Visual Studio {VS version}\Common7\IDE\obj\{x86/x64} if exists), clean the solution and run build.

0
Comment actions Permalink

Have done as you instructed.  No obvious problems following the upgrade.  Will monitor the performance of R# and VS2012 for a few days and report back any issues that arise.

0
Comment actions Permalink

F# project compilations still fail from time to time to time, reporting failure to find files in locations where the location is clearly wrong.  Rogue Debug output folders are still being created when a build fails with R# enabled.  The problem goes away with R# disabled.  I now disable R# prior to working on F# projects and re-enable it again for C# work.

0
Comment actions Permalink

There 4 developers at our facility experiencing the same problem: Visual Studio 2010 Premium SP1 (Yes we know) 10.0.40219.1 SP1 & R# 8.2.0.2160.  Further after Installing 8.2.0.2681, we lost the use of the Database Project (dataDude) - the Installer removed it. Would like to try a new build including the 8.2.0.2681 fixes, but with an installer that doesn't remove the Database project.

The fix for the lost Databse project required the removal of the Patched build and Repairing Base VS2010 Premium and re-applying the VS2010 SP1 service pack.

We have:

One solution 98 Projects Mixed between C# and VB, Including Web. All building to the same directory. similar to David R.  We are experiencing EXACTLY the same problems. Broken builds pointing to impossible locations. Files that cannot be removed.

So my question is you gave us a patch that you felt fixed something. If you give more insight as to what Resharper is doing at build time. We can try some stuff. But it is not easily reproduced but once the builds fail the only way to get a clean one is to Delete the build folder via the explorer.

I'm running an number of extension. but tried removing them, cleaning up all bogus paths (that I could find) and still no dice.

Downgrading to 8.1 removes all problems.

0
Comment actions Permalink

I am experiencing the same issue with a large solution. When the Rebuild fails it seems to have files in the wrong obj\Debug file.
For project A there will be files for Project B in the project A's obj\Debug file. It appears to happen if you Rebuild immediately after building. If I leave visual studio alone for a while after Rebuilding and then Rebuild again everything is ok. Once I have this failure I have to delete all the obj folders for each project. After that everything is fine as long as I don't rebuild right after another build.


It appears to be a timing issue.

I also have noticed that after the visual studio says its done Rebuilding the devenv.exe process is consuming 80% of my processor cycles for a minute or two. Not sure if its related or not, I am going to test if waiting for the devenv.exe process to finish and then Rebuilding works without errors and if you Rebuild while the devenv.exe process is working if it corrupts the files.

I'll let you know what I find.

Thanks,
Damien

0
Comment actions Permalink

OK, so after doing some testing! I think I may have found some more information regarding this issue. When building the solution using R# 8.1 the devenv.exe process stops when the output window in Visual Studio says its complete. But after installing R# 8.2 the output window states that the build is complete but the devenv.exe process still consumes processor time for about 2 minutes on my machine. I I build or rebuild while the devenv.exe process is still working I get failures. If I wait until the devenv.exe process is not using any processor time I can then build/rebuild without any errors.

So why does R# 8.2 cause the devenv.exe process to continue even after visual studio says its complete?

Is anyone else experience the same thing or is it just me?

Thanks,

0
Comment actions Permalink

So after discovering that there was a R# 8.2.1 release candidate, I decided to give it a try. After installing it the issue seems to have gone away.

0
Comment actions Permalink

No, it's not just you.  You are describing the same symptoms that I described in the second post on this thread.  I am still using 8.2.  I simply disable it and then re-enable it when I run into issues.

0
Comment actions Permalink

Hi

My issue is trivial by comparison.

I have a small test app with2 C# Forms, I am getting "Do Not Recognise Symbol" Form2 where Form2 clearly exists, BUT Form2 has an error , but than normal wouldn't stop it showing ,

I call form2 from a button on form1 , and Form2 shows red in form1's code , BUT compiles and runs

Also I simply lose intellesence every now and again, restarting VS cures it BUT.

Also File structure shows blank occasionally.

None of the above are predictable , It seems that any non compilable error causes it.

This is with 8.2.0.2160 in VS 2013

I too am reverting to 8.1 for the time being.

Mike

0

Please sign in to leave a comment.