My VS2010 solution is a large scale one, with 100+ source/header files, and several external library being included. I use VAssistX plugin. Yesterday I added a new .cc file and it started getting slow when editing. Very lag when typing.
I tried to rebuild VS2010 intellisense database (Project > Rescan Solution), and rebuild VAssistX symbol database. Is there any other thing I can try in order to fix this issue? Or any way I can find out what's the root cause.
PS: I am guessing this lag is due to symbol parsing. Whenever I type in that new file, VS2010/VAssistX is looking up or updating the symbol database. Somehow this operation is cause lagging.
I know it's an old question but for those that still work with it, Visual Studio 2010 doesn't cope well with a lot of files being open. This might be the problem here. Try right clicking your current file and selecting Close All But This and see if that works for you.
Related
I am getting an inconsistent error with Visual Studio 2015 that is severely hampering my productivity.
I am working on a very large application that I have pulled down from TFS. Sometimes when working I will try and save the file that I was working on, and have the asterix not go away and the file not save. This is despite running the application in Administrator.
Sometimes the solution is simply to rebuild the project and then try to save, however when this doesn't work I need close down visual studio and start up again, losing all my saves anyways.
This isn't too bad when I am working on .net files because the problem happens a lot less, and the solution is almost always to just rebuild, which is much better than having to re boot vs. However recently I have been working on javascript files within visual studio, and with them I get about one save, then the problems comes up, and rebuilding doesn't fix issue, causing me to have to reboot visual studio every save I make...
I have tried searching online for people who have faced a similar issue, or asked around my work, and no one seems to have ever had a similar problem. So hopefully, for my sanity's sake, someone knows what the heck is going on with my visual studio. Thanks!
I am currently running VS2019 16.7.2 and sometimes it just refuses to save no matter what I do. I try Ctrl + S, File -> "Save all", closing the window (which causes the changes to be lost) but nothing works.
Though for some reason when first I press the File -> "Save ... as" option in the menu and then cancel it, that releases the "save lock" and suddenly I am able to save again. Not really a satisfactory solution but at least all changes aren't lost. Maybe it will work on other versions as well?
I will give an answer to a problem which might not be exactly the same as the one reported by the author, but it is fairly close, and people searching for a solution to this problem are likely to arrive to this question.
In my case, in my entire solution containing thousands of files, there was only one particular file that Visual Studio was consistently failing to save when needed. As a result, after each commit, the "Git Changes" tab would not appear completely empty. All files would be committed, except this one file, which would appear as still uncommitted. So, I would have to manually save it and then amend the last commit in order to arrive at a completely empty "Git Changes" tab.
I thought that the problem might be due to some discrepancy between the letter case of the filename on disk (which is what the "Git Changes" view reports) and the letter case of the filename in the visual studio project file (which is what the "Solution Explorer" view reports) but it turns out that this was not it.
After much troubleshooting, I discovered that the following sequence of magical incantations solves the problem, I have no idea why:
In "Solution Explorer" locate the problematic file.
Rename the problematic file to something else.
Commit (with amend if you wish) the file.
Rename the file back to its original name.
Commit (with amend) the file again.
Restart Visual Studio.
The last step of restarting Visual studio is not strictly speaking necessary, but it is useful in case you have a letter case mismatch, because Visual Studio seems to be somehow caching filenames, (or at any rate not detecting that the capitalization of a filename has changed,) and restarting it makes it come to its senses.
I realize this is an old question but I had a similar problem with a solution file I had upgraded from Visual Studio 2015 to Visual Studio 2022. I was unable to save any changes to the solution, although the file was writable in notepad.
Deleting the section in the solution file as suggested by Richard Stanton's workaround fixed it for me!
developercommunity.visualstudio.com Workaround
Delete the following section from the solution file:
ProjectSection(FolderStartupServices) = postProject
{B4F97281-0DBD-4835-9ED8-7DFB966E87FF} = {B4F97281-0DBD-4835-9ED8-7DFB966E87FF}
EndProjectSection
I don't know when this started, but I discovered that Visual Studio 2013 Update 5 aborts when attempting to open properties for a project within a solution. It seems to only happen when we have more than one project in the solution.
I've been able to reproduce it in two circumstances:
The first project is C++ and the second project is Fortran. Right-clicking on the first project and selecting Properties crashes Visual Studio without a crash dump or any kind of pop-up notification. Visual Studio just ceases to exist. Right-clicking on the Fortran project brings up the property sheet without any problem.
The second circumstance is with two projects, both C++. In this case, I'm able to open properties successfully for the first project, but not for the second one.
In every case I've tried where there's a one-to-one solution and project, it's working fine. A colleague who's working with VS 2013 Update 4 verified that the crash occurs for him as well.
We don't know when this started, but historically, we've opened these property sheets many, many times. However, it's probably been a few months since I've worked on a mixed-language process, and same with my colleague.
I've turned on logging and there was a complaint in the log about two versions of the Desktop SDK having the same internal ID. I removed one of those altogether, but that didn't seem to affect anything. It's also not clear if that error has any relationship to the crash.
I've also done a repair on Visual Studio, and that did not correct the problem.
I've also tried deleting the .suo and .user files. Again, no luck.
I've done quite a bit of googling but haven't found anything that matches this specific problem.
Any ideas?
Thank you,
Doug
We have recently upgraded an MFC solution from Visual Studio 2005 to Visual Studio 2013 (Update 4), at last. I think the solution originates in Visual Studio 6 and was upgraded to VS2003, then VS2005. It is a Multibyte (i.e. non Unicode) solution.
We haven't had many problems, so far. In fact it seemed like we had sorted pretty much everything out.
One of the errors we were getting was in the rc file, where the compiler said it couldn't find "l.esp\afxres.rc". Upon investigating the issue, we found that in VS2013 (I guess 2012 and 2010 too) the path is "l.esn\afxres.rc" so we changed it, and it all worked fine again.
Now, after "finishing" the port, we've continued the development, and we've found that, every time we make a change to the resources (add new controls, change the properties of existing ones) the path returns to the old one ("l.esp\afxres.rc"). It changes it when saving the resource file (make change, click save, it's already changed).
I guess there is some property, or something, that it's still telling the IDE it is a Visual Studio 2005 project, but I can't find it. I've tried removing the UpgradeFromVC71 property page, but to no avail.
Any ideas?
Ok, I've found it! Leaving an answer for future reference.
It's in the Resource include files. Go to Resource View, right click on the .rc file and select "Rsource Include Files". There are the offending includes. Change the path, and done!
https://support.microsoft.com/en-us/kb/198536 (old, but good enough)
I've been developing a project for a while, and we have started a "documentation" folder in the Visual Studio 2008 solution so that we can keep the developer documentation (and a few other useful files) in there (it's one of Visual Studio's solution folders, rather than a project). We're also using the AnkhSVN plugin so these files get copied to Subversion.
However, every time I save any of the files, Visual Studio automatically removes it from the solution, so I have to add it back in,and then close Word again without saving.
I'd have thought this was a fairly easy problem to solve, but the past three weeks (and reading many spurious results on Google for almost every search query I can think of that might be relevant) seem to have proved me wrong.
Does anyone have any ideas how to stop this behaviour?
I don't know if this still happens with VS2013, but for VS2010 here is a detailed explanation on the cause and a work-around:
Word files disappear from "Solution Items" in VS2010
Are you sure the files are removed and not just hidden? I had a similar thing with non-code files.
Showing and Hiding Hidden Files in Visual Studio 2008
when loading up a solution in VS2008 I get:
An error was encountered while
opening associated documents the last
time this solution was loaded.
Document load is being skipped during
this solution load in order to avoid
that error.
How can I find which document is causing the problem?
I can't say I've seen this particular error, but I'm wondering if that might be stored in the .suo file associated with your solution. The .suo is where VS tracks which files you had open previously, so maybe it tracks failed ones as well. You might try renaming or deleting that file and then reloading the solution to see if the error goes away. Unfortunately, those files aren't entirely human-readable, so if that proves to be the location, it may not be trivial to determine which file was at fault.
I cleaned my solution via Build->Clean Solution.
Then I rebuilded my solution. Seems to work for me.
edit: i use VS 2010
I've been shut down by this problem all morning, so I've been doing some forced research. here's a tidbit that may help, along with some links I've found (but IO haven't read them all yet).
First of all, the tidbit. It seems that if I can get the solution to open at all (which I can, the second time, when VS.NET skips the "Document loading" step), and then immediately do a Rebuild All, that might "fix" the problem (meaning, the problem will go away for a while and show up a few days later, but at least I can get some work done).
Of course, that may turn out to be a red herring, but it appears to hold true right now.
Next, here are some links I've found. I haven't read all of them, but they are about this problem or very similar ones, and they may help somebody.
http://social.msdn.microsoft.com/forums/en-US/vssetup/thread/cb73c8d6-077f-4220-aaf8-463039ee1d5f
Why does Visual Studio crash opening ASPX with MVC RC1
Resharper (R#) 4.5 and MVC (1.0) solutions cause Visual Studio 2008 SP1 to crash on solution load
http://www.lostechies.com/blogs/hex/archive/2009/03/02/hot-fix-available-for-visual-studio-2008-sp1-crashing-when-opening-up-aspx-files-views-on-vista-sp1-x64.aspx
http://www.chowamigo.co.uk/2009/10/fix-visual-studio-hangs-crashes-and.html
http://forums.asp.net/p/1384470/2942121.aspx#2942121
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=471570
http://blogs.msdn.com/jnak/archive/2009/02/26/fix-available-asp-net-mvc-rc-crash-in-a-windows-azure-cloud-service-project.aspx
I'm using VS2010 and had the same fault.
I removed the 2 SUO files associated to the solution and it worked fine.
It may not be possible to definitely determine which file is causing the issue. Similar errors have been reported with widely varying circumstances, except for the condition where there is at least 1 file that was still open for editing at the last time the solution was successfully opened and closed.
I've looked at this myself with WinDbg active, and the call stack is filled with a chain of DLLs in thread/module unload state. Most likely this is being caused by a race condition or other faulty multi-threading behavior in visual studio.
Here are other references you can view, in case others update them with additional information.
IDE Reports Error ... # Microsoft Connect
Error Loading Solution 100% of the time ... # Microsoft Connect
Error opening associated documents ... # Stack Overflow
Edit:
I should add that my conclusion of this being a race condition is based upon clues gathered while trying to create a minidump of the crash in Visual Studio with WinDbg; and prior history with similar unexplained bugs in older versions of Visual Studio.
In my exploration, WinDbg consistently reports that a minidump cannot be created for this crash because ReadProcessMemory has failed. The stack trace contains a trail of DllUnloads called for various reasons. There are no reports of this bug happening when there are no document views that were open at the last time the solution was closed. In combining these clues, my guess is that there are bugs in the order of instantiation; perhaps as two views of the same type are opened, one completes ahead of the other and causes the cleanup of a resource that is shared by both actions.
It is possible that this isn't a race condition or threading bug, though the symptoms strongly suggest it. Fortunately for myself and others who have chimed in with answers, when I've encountered this bug, deleting the .SUO file (and .NCB file in older versions of Visual Studio) fixes the problem.
I had this issue as well. I deleted the *.suo file associated with the solution. When I attempted to load the solution again I was prompted with the same error except that this time Visual Studio didn't crash instantly. When I clicked "ok" on the error dialog the solution seemed to load just fine.
Received this "document load skipped" error, then an "object reference not set to an instance of an object" error when I tried to close VS. I fixed both by deleting:
C:\Users{user}\AppData\Local\Microsoft\VisualStudio\ComponentModelCache and
C:\Users{user}\AppData\Local\Microsoft\VisualStudio\devenv.exe.config
C:\Users{user}\AppData\Local\Microsoft\VisualStudio.NETFramework,Version=v4.0,Set=Extensions,Hash=6D09DECC.dat
C:\Users{user}\AppData\Local\Microsoft\VisualStudio.NETFramework,Version=v4.0,Set=Extensions,Hash=9951BC03.dat
C:\Users{user}\AppData\Local\Microsoft\VisualStudio.NETFramework,Version=v4.5.2,Set=RecentAssemblies,Hash=0.dat
I found those first two were causing other errors related to missing packages when I'd load up my project, and the "object reference not set to an instance of an object" when trying to close VS, and was receiving errors from the JavaScript Language Service, complaining of missing js files from those last .NETFramework files (which I do not get if I do not add them back in):
01:10:11.7550: Referenced file 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\JavaScript\References\libhelp.js' not found.
01:10:11.7550: Referenced file 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\JavaScript\References\sitetypesWeb.js' not found.
01:10:11.7550: Referenced file 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\JavaScript\References\domWeb.js' not found.
01:10:11.7550: Referenced file 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\JavaScript\References\underscorefilter.js' not found.
01:10:11.7550: Referenced file 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\JavaScript\References\showPlainComments.js' not found.
I might just need to re-install/repair the JavaScript Language Service plug-in, and it's possible those were the files getting "skipped". But I would try getting rid of all of the files I listed above and restarting Visual Studio. They should get re-created, except for the .NETFramework files. If you like, you can back the .NETFramework files up, then delete them, and then paste them back in one at a time and relaunch VS between each file copy-back that you do, to narrow things down, as I did.
Posted my process I used to figure this out at Visual Studio 2015 error "Object reference not set to an instance of an object" after install of ASP.NET and Web Tools 2015 (RC1 Update 1)
I received this error today in Visual Studio 2019. I solved it in 2 steps
Build | Clean Solution
Rebuild Solution
I'm uncertain which of the 2 steps above did the trick, but I am certain that it is fixed. I would be nothing without Stack. Thank you everyone for posting on this site.