I installed VS2013 (v12.0.21005.1) and added ReSharper 8 (v8.0.2000.2660) a day or two ago. That day it was fine. Now I'm lucky if I can get it to open one solution in a whole day. It opens OK by itself, but when I try and open a solution from within - via the menu - it hangs, badly. If I right-click a solution in Windows Explorer and 'open with VS 2013', it opens then hangs, in exactly the same way. Every now and again, for hours, I get a little notice that it's busy with something.
Anyone know what could be wrong, before I endure a reinstall that doesn't fix the problem?
Sometimes it's enough to simply delete the ".v12.suo" file and try to open the solution again. Helped me many times when VS2013 was freezing on loading a project.
Deleting all ".suo" files worked for me. There were several copies due to opening the solution in multiple versions of Visual Studio.
Edit:
Possible path could be:
PathToSolution\.vs\ProjectName\v14\
.vs may be a hidden folder.
.suo is filename.
Basically it could be anything, but you can try a few things:
Turning it off and on again.
Clear the ReSharper cache, it's in %LOCALAPPDATA%\JetBrains\ReSharper\<CurrentVersion>\SolutionCaches, where you should find a folder matching the solution you are trying to open. Just close all instances of VS2013, delete the folder and try again.
turn off ReSharper: Tools > Options > ReSharper > General > Suspend
uninstall ReSharper completely and see if problems persists.
Repair Visual Studio through Programs and Features.
I found the following to be the better approach to debugging VS based on MS Connect instructions
Please help to confirm if your captured dump file is a 32-bit dump file. If it is a 64-bit dump file, please use the following step to capture a new dump file.
Start Visual Studio.
Start another instance of VS.
In the second instance click Tools | Attach to Process...
In the list of processes locate devenv.exe.
Click Select... and explicitly choose 'Native' and 'Managed' code.
Click OK and OK to close Select dialog and Attach to Process dialog.
Go back to the first instance of VS and repro the hang.
Upon the hang, control should go to the second instance of VS. If not please go back to the second instance of VS manually, and hit "Break All".
In the second instance click Debug | Save Dump As Minidump with heap.
If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
Select Tools -> Customize
Select the Commands tab
Select Debug from the Menu bar dropdown
Click Add Command...
Select Debug from the Categories list.
Find the Save Dump As entry in the Commands window.
Click OK (the Save Dump As... command is added to the top of the Debug menu).
Click Close
You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx
If you find the problem is with Resharper Addin you can then report the issue via - http://youtrack.jetbrains.com/issues/RSRP
Suspending Resharper Worked for me.
Goto
Tools -> Options -> ReSharper -> General -> Suspend Now
Now your solution will load very fast.
After your solution fully loaded, you can change the Resharper settings to Resume Now.
Are you using any node modules in your project? Or can you identify that it is a ReSharper specific issue?
If you've got NPM modules (eg. for Grunt), mark your 'node_modules' folder as 'hidden' (no need to make child folders hidden though), and try again.
Visual Studio was hanging on open for me, turned out it was trying to scan deeply nested node modules with file paths longer than the Windows maximum (260 characters), and this was preventing me from opening the solution in VS, but marking the folder as hidden solved the problem.
I had this issue recently as well, and found that disconnecting my computer from the internet when loading the project fixed it. With this, I managed to cut loading times from several hours down to seconds. Since my network cable is not particularly accessible, I simply disabled my network adapter before loading the project (in Control Panel).
This soon became frustrating, however, and I recently looked into the problem again. It seems that logging on to my Microsoft account in Visual Studio ultimately fixed the problem, and I now have no more issues loading projects.
This may work for you as well (if you haven't yet fixed it - but since there is no accepted answer here, I assume that the problem is persisting), so I suggest that you at least try disconnecting from the internet, even if you would rather not enter your Microsoft credentials.
I went into the %LOCALAPPDATA%\JetBrains\ReSharper\
and opened all the directories looking for the SolutionCaches, and emptied all of them. Problem solved. The application was quite large, so this helped.
Check for Windows updates
I had this problem too. Furthermore, I couldn't open my Windows firewall settings (trying to block VS's internet connection).
When opening update settings (Windows 8), I saw there was a pending update ("found today"), so I rebooted my computer, letting Windows update. After that, VS and the firewall worked fine again.
Check your hardware
I've had the problem a second time; even Windows 8's update page would keep loading forever. It was an issue with my (non-OS) hard drive: https://superuser.com/questions/756261/various-parts-of-windows-8-and-visual-studio-2013-get-blocked-by-possibly-comm?noredirect=1#comment978074_756261
I get this issue now and again - VS 2013 Update 2, Win 8.1, IE 11.
Try this - Open task manger, kill the VS app hanging, and then close any IE sessions that are running in the Background Process list - there may be one or more hanging around.
Restart VS
Seems to clear it for me, without a reboot.
The problem I had was the Perforce connection.
When opening the solution, it would ask if I wanted it to connect to Perforce. Allowing it to try would make it hang and allocate 1.5 GB of RAM.
Not allowing the P4 connection let it load properly (allocating 1 GB RAM). Then I could tell it to connect to P4 after, and it is now fine.
For me , whether computer crashes with power outage, or sometimes with mandatory reboots in the middle of the night. What does WORK for me
DELETE ALL FILES IN THIS DIRECTORY:
C:\Users\yourusername\AppData\Local\Microsoft\WebsiteCache\
For anyone still referring this helped me:
I had to always delete .vs12.suo file to load the project.
I came across this thread from Microsoft and following that I created registry entry which fixed my issue with Solution load.
https://connect.microsoft.com/VisualStudio/feedback/details/860685/visual-studio-hangs-after-10s-when-loading-solution-corrupt-suo
I had similar issue, when i checked the solution file it was created by VS.Net 2012. To resolve the issue, I created dummy solution file and reloaded the projects from vs.net 2012.
Also observed when nuget package update got screwed up, while you reload the solution, Visual Studio might get hang.
The Visual Studio might go hang, when there was a problem in loading the nuget packages.
In my case, VS 2013 Professional was hanging on every startup, even without opening a solution because the license was no longer valid.
Last item in the log file:
<entry>
<record>367</record>
<time>2015/07/13 20:11:05.051</time>
<type>Information</type>
<source>UserConnection</source>
<description>myemailaddrs#gmail.com signed in for IDE user</description>
</entry>
And on the msdn.microsoft.com subscription page: "Your subscription is no longer active, contact your administrator."
I had to get an updated subscription from my employer.
Deleting Test Results from my TestResults folder actually did the trick for me. Just another thing to try.
VS2012 hangs on me e.g. when opening a csproj file on a network share (in fact on a share that was on the VirtualBox host, connected as a smb share using a VirtualBox feature).
Copying the project over to a local drive fixed it for me. Not sure if assigning a drive letter would do the trick.
Also not sure why it does not work via network share, if it is a VS limitation or perhaps some plugin (I use resharper, of course).
For me this appears to have something to do with the project having the MVC 4 project type guid (E3E379DF-F4C6-4180-9B81-6769533ABE47). Removing this guid from the .csproj resolved the hanging for me. (An additional wiping of the .vs folder was required after removing the guid.)
I just removed "packages" folder from root of solution and it helped for me (Visual Studio Express 2015)
Sorry for having to create a new post instead of commenting on the selected answer .. I do not have enough rep to comment at this time.
My issue was was temporarily resolved by the "...delete the .suo file ..." solution, and as other folks pointed out, I had to delete the file every single time.
Since it (apparently) is impossible to stop the creation of the file I started to dig a little more into what the file did. In addition to saving user settings, I believe it is also saving session settings, like which files you have open when VS is closed. I suspected that my project is attempting to open a file that no longer exists and that is what is causing the hang. What fixed things on my end was to delete the .suo, open VS, open a file within my solution, build and close the solution. After doing this I have had no hangs.
tl:dr
In my case, a user setting file(.suo) was attempting to open a file in my solution that no longer existed. I resolved the issue by performing the following steps.
Delete the .suo file (for me this was in /[projectfolder]/.vs/[projectname]/v14
Open Visual Studio
Open your project
Open a file (I simply opened a random .cs file)
Build and save your solution (Simply saving may do the trick, I built by habit)
Close Visual Studio
Hope this helps someone ... we spent way too many hours on this issue :)
Lots of suggestions here and elsewhere but the only thing that permanently worked for me had to do with the start-up project I'd set. This is what I did:
Delete the .suo file as suggested elsewhere.
Start VS and open the solution. All should be well at this point.
Leave the start-up project as-is, even if it's not what you want.
Save the solution. (Possibly do as someone else suggests and open a file, clean, build/re-build, etc, but I didn't have to do any of that.)
Close the solution and exit VS.
Re-start VS and open the solution.
Change the start-up project to whatever it should be
Save the solution. (Possibly again do the open file, clean, build/re-build, etc.)
Close the solution and exit VS.
Restart VS and re-open the solution and all should be well.
This might or might not work for you but I'd tried everything I could find - registry changes, debugging VS from a second VS session, you name it - but nothing else worked for more than a single start/open.
Try to uninstall extensions with "Control Panel" or disable any add-in in [Tools]=>[Add-in Manager] then try to reopen the solution.
My problem was fixed by uninstall "Visual Localizer".
In my case the Fusion log has been enabled. Log files has been growing for months as I forgot to turn it off after investigation. This way the antivirus software started to check these big log files several times during opening the solution, and "Preparing solution..." message is visible for long-long time. When I noticed this, I turned off the fusion log, and problem solved. Solution loads in 10 seconds instead of 20 minutes.
I've had this issue multiple times, in pretty much all versions of VS. The one solution that seems to work most of the times is to delete the .vs folder located in the solution folder. Sometimes it's enough to delete the .sou file located in .vs///
The folder is hidden by the way, so you will have to enable "Show hidden files and folders"
For me the solution was to disable source control (Set plugin to None in Tools->Source Countrol). I think it was trying to sync some huge Git repo for some reason (have a couple of massive repos, but not in the tree I was trying to open).
I have fixed the issue by uninstalling these two plugins:
Productivity Power Tool
Web Essentials
I restored a previous version of the .vbproj file and it solved it.
I don't know what was in the newer version but the problem was something inside the .bvproj file itself.
What does Visual Studio's unbind | bind operation do to projects in a solution.suo file?
Microsoft provides instructions on How to: Bind or Unbind a Solution or Project, which happens to remedy the dreaded "Unspecified Error" that occurs at solution opening. This MSDN forum posting has a user stating they unbound and then re-bound their projects in order to solve that problem.
As I was experiencing the same "Unspecified Error" problem, I did some additional digging and found that the solution.suo file was the only likely candidate that had changed after I had resolved the issue.
I read this answer to an SO question about .suo files being effectively disposable and happened to be able to recreate the UE problem through a stale workspace I had laying around. So I went ahead and deleted the solution.suo file and opened the solution.sln file. Magically, my UE problem had gone away with that workspace too.
That led me to conclude unbind | bind has some sort of effect on the .suo file, but because of the files binary, proprietary structure I wasn't able to identify what's going on.
My Questions:
1. So what exactly does Visual Studio's unbind | bind operation do to projects in a solution.suo file?
2. Can anyone surmise what's causing these "Unspecified Errors" now that I've find the linkage to the .suo file?
Footnote 1: This MSDN article explains a little bit about .suo files, but doesn't really go into details.
Footnote 2: "Unspecified Error" on project / solution opening appears to be quite the bête noire as evidenced by here, various searches, and this old MS KB
Sure, the .suo file is where Visual Studio stores the state of the IDE. So that when you open a solution again later, everything restores the way you left it off. The most obviously visible effect is that windows restore in their original position and size. And yes, the binding of the solution to the specific source control server where you want the changes to be checked in could well be stored there as well, it is the logical place for it.
"Unspecified error" is a very generic COM error code named E_FAIL. Visual Studio uses a lot of COM code, the add-in system is entirely COM based. It is a lousy error because it doesn't mean anything more than "it didn't work, don't know why". Similar to returning false from a function. There's a programmer at Microsoft somewhere that could have done a better job reporting the problem. Maybe that wasn't so easy.
VS project binding stores which projects are managed by source control. It is saved in the .SLN file.
Unfortunately, the format in which it's save is hard for source control systems to merge. Therefore, the bindings often get corrupted, leading to erroneous "Projects have been added to source control" messages when loading the solution. The procedure to fix this is to delete that entire section from the .sln file, open in VS, and then re-bind the solution, which will create the section correctly.
BTW, the whole solution file format is quite awful for merging. It smells like VS6, and the source control section smells like SourceSafe. I wish they'd move to some MSBuild-based format, like they did with (almost all) project files.
This is driving me crazy and has resulted in lost work (not much, at least).
Normally, when I edit a file in Visual Studio, it's supposed to automatically check that file out in source safe. On multi-project solutions (e.g., web app with class libraries), sometimes none of the files in one project would automatically get checked out, though exiting & reloading visual studio may fix that problem temporarily. Furthermore, project files are never automatically checked out. Whenever I add/remove code files, I have to remember to explicitly check out the project file as well (otherwise we'll have issues with code files not showing up in the solution explorer, or trying to load non-existing files).
We're using VS-2008 and VSS 2005. Do you have any idea how I might fix this? There are no more visual-studio updates/fixes on Microsoft Update.
You need to ensure the files are read-only, or VS won't be able to tell that they are version controlled (or, at least that's what it uses to determine it). You can tell VSS to set itself up so getting the latest version places the files RW on disk.
There may be other problems here, but that's what comes to mind first. My advice (that I took myself) is to migrate to SVN or an alternative. Losing work is unacceptable.
I have a VS2005 solution which contains a variety of projects (C++ DLLs, C++ static libraries, C# assemblies, C++ windows executables) that are combined in various ways to produce several executables. For some reason, every time I open the solution, VS2005 wants to check out one of the projects for editing. The project is not modified in any way, it's just checked out. If I configure VS2005 to prompt before checking out, I can cancel the auto-checkout during load with no ill effect that I can see. It may or may not be relevant, but the project it keeps checking out is cppunit version 1.12.0 (the static lib version). How can I stop this annoying behavior?
Other potentially relevant (or not) details:
Source control is Team Foundation Server (not Visual SourceSafe)
no .suo or .ncb files are checked in
the .vcproj and .vspscc files are being checked out
When I close the solution or shut down Visual Studio, I'm asked whether I want to save changes to the project. Answering yes results in no changes to the file (Kdiff3 compares my local file to the server version and reports"files are binary equal")
Attempting to check in the "modified" files results in a Visual Studio message saying "No Changes to Check In. All of the changes were either unmodified files or locks. The changes have been undone by the server"
As Charles and Graeme have hinted at, Visual Studio constantly make changes to user option files and such on the backed even if you don't make changes to the project directly.
I'm not sure what information is being stored but I do know that it happens. Common remedies is to not include the *.suo files. I also don't stored anything in the bin or obj folders in sauce control as this can have a similar effect as your talking about (if you build). (Checks out the project upon a build. Thought this does take an action to happen).
Overall it is unavoidable. It is just how VS2005, 2008 work.
Does this answer your question?
Regards,
Frank
There are two reasons I've encountered that cause this behavior.
The first is old source control bindings. If you have a project that used to be managed by another source control tool, it might have leftover bindings in the project file. Open the project file, and change the following settings from something like this:
SccProjectName="$/Team/Platform/Projects/MyProject"
SccAuxPath="http://teamFoundationServer.example.com:8080"
SccLocalPath="."
SccProvider="{88888888-4444-4444-4444-BBBBBBBBBBBB}"
to this:
SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK"
Different project types are defined in different ways. The above example is from a .vcproj, C# projects are in XML, VB looks like something else, but the meanings are the same. Simply set all four values to the constant string "SAK" and Visual Studio will automatically handle source control. See Alin Constantin's blog for details.
I haven't yet discovered the root of the other reason, but the project that is giving me trouble is also CppUnit 1.12.0! I'll keep digging and post my findings.
John
Have you put a .suo or .ncb file into source control perhaps?
Have you tried closing VS2005 after it checks out cppunit and then seeing if any changes were made?
I often encountered something like this with Web App solutions where the project file wasn't actually saved until you closed studio down and reopened it.
Just to clarify, I'm assuming that you mean Visual SourceSafe2005 is causing the problem, not Visual Studio. (FYI, Visual SourceSafe is usually abbreviated VSS.)
I've experienced this issue with VSS before. I think the limitation is really fundamental to Visual SourceSafe: it's just not that good of a product and I would move to something else if it's a decision you can influence.
If you can move to something else, I recommend Subversion for a small or medium-sized project. It's free, and does not use the pessimistic locking mechanism that Visual SourceSafe uses by default. There's an excellent Visual Studio add-on called VisualSVN that will give you the same functionality in the IDE (seeing what files have changed, etc.) that you get out of the box with VSS.
If you cannot change source control systems, I believe Visual SourceSafe has a mode called "non-exclusive checkouts" or something like that that uses the optimistic locking that Subversion and other source control systems use. Try setting that option at least for the files that are obviously not being changed and see if that resolves the issue.
I get this a lot when one of the projects in the the solution has source control information with path information that is not the same in source control as on your workstation. When VS opens the project it will automatically attempt to check out the project in question and
To fix it, you're best off having everyone who uses the project remove their local copies and do "get latest version..." to grab what is in your source control database.
you can also check the .sln file and look in the GlobalScxtion(SourceCodeControl) area for each project's information and see if the relative path is not how you have the projects stored on your workstation - though manually changing this file vs. doing a "Get Latest Version..." is much more likely to cause problems for the other developers who use the solution as well.
Your cppunit project is probably automatically creating one or more additional files when the project first loads, and then adding those files to the project. Or else one of the project's properties is being changed or incremented on load.
If you go ahead and check the project in, does it check itself out again next time you load it? Or does checking it in fix the problem for awhile?
Very often this sort of behavior is caused by VS trying to update source control bindings.
Graeme is correct, VS will not save project or solution files until you close VS.
I would let VS check the files out, then close VS, then diff them.
I just wonder what the best approach is to have multiple users work on a Project in Visual Studio 2005 Professional.
We got a Solution with multiple Class Libraries, but when everyone opens the solution, we keep getting the "X was modified, Reload/Discard?" prompt all the time. Just opening one project is an obvious alternative, but I find it harder to use as you can't just see some of the other classes in other projects that way.
Are there any Guidelines for Team Development with VS2005 Pro?
Edit: Thanks. The current environment is a bit limited in the sense there is only 1 PC with RDP Connection, but that will change in the future. Marking the first answer as Accepted, but they are all good :)
What you need is source control.
You should definitely not open the same files over the network on multiple machines. For one thing, Visual Studio has safeguards in place to prevent you from modifying certain files during a build, but it has none of that that will prevent others from modifying the same files over the network.
By setting up source control, each developer will have a separate copy of the files locally on his or her developer machine, and periodically communicate with the source control system to check in/commit changes. After that, other developers can ask for the latest updates when they're ready to retrieve them.
Use source control to keep a central repository of all your code. Then each user checks out their own copy of the source code and works locally. Then submits only the code that changed.
https://en.wikipedia.org/wiki/Version_control
A number of people have recommended using source control and I totally agree. However you also need do the following.
Exclude your personal options files from the repository (eg your .suo files)
Exclude your App.config files from the repository. - Not entirely but you need to have a Template.App.config. You commit that instead, and only copy your App.config into the Template.App.config when you make structural changes. That was each user has their own individual config for testing.
There are probably some other files worth excluding (obj directories and so forth) but thats all I can think of right now.
Peter
This might sound snide, but if you're opening up the solution from a shared location then you're doing something wrong. If that's the case then you should start using source control (something like Subversion) and have everyone check out a copy of the project to work on.
However if you're already using source control, then it might be a symptom of having the wrong things checked in. I find that you only need the sln, and the vcproj under source control.
Otherwise I don't know...
You should definitely, definitely be working with source control!
This will help stop the collisions that are occurring. Also, if you are making changes to the shared projects this often that it is a problem, then also ensure that all code is tested before getting checked in (otherwise they may bust someone else's build), but make sure they check in often (or time gained from not dealing with prompts will be lost in merging conflicts) :)