I am having problems with my visual studio 2010 where its memory consumption increases quickly while the application is open. I unistalled all plug ins and now just have the clean version. But while I have the solution open, the memory increases from ~300K to 1GB to such a point if it hasnt crashed, I need to kill the process. The version of the VS is professional and it happens for different solutions.
I feel it may down to the locking on VS2010 config files eating in to memory but thats a guess.
Anyone have similar issues or how I might go about finding what the issues is?
I was having the exact same problem working with large solutions. Give this plugin a try, Solution Load Manager, it lets you essentially "lazy load" projects in your solution, so you only have the ones you're actively working in open and consuming memory.
Worked wonders for me.
I agree with Tipx. Never seen such an issue. My studio hovers around 300MB, but the solution I have open right now has 10 class libraries and 11 web application projects in it.
I'd say open visual studio, start a brand new blank .net solution and let it sit. If it's memory jumps to 1GB, then do a complete uninstall ( http://archive.msdn.microsoft.com/vs2010uninstall ) and reinstall it from the ground up. If it continues exhibiting the behavior on a blank solution then I'd suggest wiping the OS from the machine because something else is really wrong.
If it's memory doesn't climb, then create a blank solution and slowly add your projects into it until something happens. Fix the project showing the behavior.
Of course, if you have a large number of projects OR some third party code is executing on them then 1GB of RAM might be exactly what it needs. I know Telerik's stuff will inspect each project as you click on it to determine if it has the latest version of the controls... I'm guessing others will do something similar.
Create new directory
Move project files new directory (without sln and sou files)
Open project from new location
that's all.
Related
I recently bought a new computer. After getting everything setup, I installed visual studio community 2019 and gitkraken and cloned down my project(which was building and running fine prior to changing computers) and I'm running into an issue. It's a game dev project using MonoGame.
These are the errors that I'm receiving currently. I've tried multiple versions of MonoGame including 3.0, 3.5, and 3.7. I've attempted to reinstall redistributables, I've cloned into multiple directories, I've attempted building a different project(a fork of the same project that I've worked on more recently on my previous pc). I have a friend that works on the project with me, he was able to clone into a new directory and build immediately. I've attempted building the content package in the MGCB manually and am also running into an issue where it's not finding a specific font file(that i've verified is installed on my computer, and also tried dropping in the correct directory for building, but have had no luck there. However, I feel like this is a separate issue, but it may provide some insight to someone who is more experienced than I.)
Ideally, this project should clone down and build just fine on a fresh install. It always has before, but there's something going on here that I'm not sure about. I've tried several different things and have hit a wall. There isn't much online about this specific issue that I've seen, so if anyone has any ideas I'm all ears. Thanks.
I figured out the issue. It was something simple as usual, a product of my own stupidity. When I first downloaded the font, I extracted and right click > install. So the font was installed on the PC. I spent a couple days on this issue, and at some point when trying to reinstall the font there was a new option that hadn't been there before called 'Install for all users' with the shield icon next to it. Previously, I'd only had the option to 'Install' without the shield icon. Not sure exactly what the difference is between these two options showing up, but once I clicked 'Install for all users', the issue was solved. So I guess initially the font was only installed for my specific user account. I'm not sure why this is an issue or why the option to install for everyone wasn't available previously, but this is what solved the problem.
Change the Build Action on the "Content-> Content.mgcb" file to "none" or "ignore"(I can't remember which). This will allow the game to build successfully.
Here is a temporary work around to allow you to continue development:
If the XNB files are not properly building in the Pipeline tool, you can copy them(from an older build or compile them on another machine) into the output directory, Content directory under the directory containing the .exe file, manually.
I've upgraded my Windows to 10.0.16299 (latest) and my Visual Studio to 15.5.1 (latest). Since then, I am seeing this error message when I clean or build my Xamarin solution containing an Android project:
obj\Debug\android\src\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.java:4:
error: error while writing CustomTabsClient_CustomTabsCallbackImpl:
obj\Debug\android\bin\classes\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.class
(The process cannot access the file because it is being used by
another process)
I figured that the locking process is Visual Studio itself after I tried to run and debug the app.
The issue appears no matter whether I want to run the app on an emulator or a connected real device.
There's lots of advice what to do when a process locks a file including SO such as the famous the process cannot access the file because it is being used by another process. However, all provided answers don't help as Visual Studio itself locks the file and the only workable workaround is to restart Visual Studio - that's not a solution.
What is causing this file to be locked? Any idea? Any advice?
Sometimes it helps to kill the MsBuild.exe. Also, you could find other solutions such as described here: Xamarin Android project cannot build....
Basically, it seems to be a problem with Studio 2017 Version 15.5. It will be fixed with the next versions probably.
Darn it, my suggestions won't fit in the context of a comment, so here goes:
Sounds like the process being debugged, or the emulator hosting the debugged process, itself, has not fully closed down, and is in a hung or semi-hung state. Have you checked the process manager to see if this is the case? You may want to to try adding Environment.Exit() to see if this helps come back to a good state.
Another thing to check is, whether your access levels are the same between the two machines. Check not only the PC, but also at the emulator as well. Check everything, and ensure the access levels/modes are identical.
Finally, try running VS 2017 in administrator mode, and see if the problem persists. It's entirely possible that the level of access that you used to run pre-Windows 10 is different in the Win10 world that you live in, now.
I have Windows 7/64 Pro box with Visual Studio 2012 Ultimate, revised to Update 4, with a problem.
Over the last week, I've started experiencing a problem that was originally tolerable, but now has grown worse to a matter of unusability, and I'm in need of some (any?) suggestions. It may turn out this is more appropriate over as a Microsoft issue moreso than a purely programming issue, but I thought perhaps someone might have experienced the issue, hence I'm taking a shot here.
The problem: The VS2012 IDE, moments after starting, seizes with no solution or project loaded, going into "Not Responding" mode, never to return. Worse, however, is that when this occurs, it blocks the OS from starting any 32-bit processes, and 64-bit processes aren't exactly responsive.
This had occurred only once or twice in the last week, and thus I assumed it was an odd/one-off situation and didn't think it was a chronic problem. Today became chronic. Whereas over the last few days this symptom was unusual, today it prevented me from working in VS2012 all day. The VS2012 IDE would be responsive for a brief time, then seize up.
Doing a bit of research on the nature of the issue, and observing it didn't occur until I started VS2012, I began to realize it must be associated with the native VS executable or the ancillary devenv.exe that starts along with it. The real culprit, however, was the Microsoft.VisualStudio.Web.Host.exe executable that provides the web version of the VS hosting environment that was causing the problem.
When the VS2012 IDE would seize, killing the Web.Host.exe process would immediately free the IDE for a time, and allow any "queued" 32-bit apps to start. However, the symptom would return as soon as the web hosting process restarted.
I have updated VS2012 to Update 4, and performed a repair installation of VS2012, and nothing has changed. There are no errors in the event logs that would indicate hardware issues (such as a hard drive failure) or any other lower-level/organic OS issues. There's really nothing to configure (that I know of) on the web host process side, so short of a complete reinstall of VS2012, I'm not sure what else to try.
I saw a fleeting resemblance to this error in a Microsoft Connect forum, but the symptoms were not, in fact, identical, and the prescribed fix (VS2012 up to Update 4) was to no avail.
Edit: Minor bit of additional information - the only unusual element that might prove an "x-factor" in this situation is the recent switch to TFS - within the last week - frighteningly coincident with the onset of the problem. But thinking the SCC provider would be less interested in the content than supporting things like Intellisense, debugging, and the like, I had a tough time convincing myself it would be a player. At this point, however, who knows.
Any suggestions appreciated.
Regret that I can only offer a general solution for this - after updating to Update 4, I then performed a Repair Install of Visual Studio 2012, and since that time, this lockup problem has not recurred. I can't say if a particular library was updated or reinstalled, or if some configuration setting was changed, but either way (so far) VS 2012 is happy and I'm working again. Will update with more information if I find it.
I'm working on an ASP.NET Web Forms application (.NET 4.0 VS 2010). Lately we've been experiencing problems which have halted our release process.
Specifically, we have found ourselves unable to publish our website (to precompile it). Across all of our developer environments (3 developers), the build process appears to be stalling/hanging - without any report of error. Sometimes, it appears to succeed but only a couple of the compiled DLL's and .compiled files appear (less than 10 out of ~350 files).
I've loaded in various revisions of our projects from our source repository, both latest and very old versions which previously worked. The fact that it's happening across developer environments suggested that the problem was due to some change we committed, but the fact that the problem is occurring across latest and old revisions of the application perhaps suggest otherwise.
Internet searches for this issue reveal nothing significant. Things I've tried include the following:
Building and rebuilding
Clean solution
Deleting the .suo files for the solution
Deleting the contents of the ASP.NET Temporary Files solution and deleting the target location folder prior to publishing
Tried selecting the 'Allow this precompiled site to be updateable' option (produces an object reference error without a file or line number)
Restarting Visual Studio and PC
On examination of CPU usage during the build, the CPU usage for the devenv.exe process is in the sub 0.10% area for most of it (a few spikes at the beginning just).
I appreciate any assistance anyone can provide with this
UPDATE: We have found that eventually, the publish succeeds, but sometimes we get a long series of failures before it succeeds. There's no consistency at all... it seems random.
I had this same issue with Visual Studio 2015 on Server 2016. The issue was partially resolved by running VS as administrator. However the apparent root cause was virus scan - in this case ESET- installed not as a File Security but as workstation. This I discovered when every entry of the license codes for ESET appeared to work - then ESET reported it still required verification. Uninstalled the badly chosen ESET and reinstalled the correct license product and, presto, with or without pre-completion, the publish works! Thanks to the previous virus scan tip!
The issue seems to have been caused by the McAfee virus-scanning software that we have installed.
Only with admin privileges, we were able to temporarily disable the real-time scanning, and as soon as we done that the ASP.NET Publish would complete successfully almost instantly.
For anyone else in this situation, it was McAfee's anti-virus software that was causing the problem. I checked the logs for the anti-virus software and there was no evidence that the software was blocking anything related to the Visual Studio processes or the folders that are manipulated during the build and publish processes (e.g. The ASP.NET temporary files folder).
Specifically, the csc.exe (C# compiler) and devenv.exe (Visual Studio) processes were having problems with McAfee. These processes were added as 'Low-Risk Processes' to the 'On-Access Scanner' to resolve the problem.
McAffee removes any changes to it's settings every 15 minutes, meaning that the action of adding these processes to the McAfee exception list (low-risk processes) has to be repeated every 15 minutes when you are building your code. This could happen a lot during a working day.
I see you do not have Allow this precompiled site to be updatable checked, so your Publish may be attempting to update what it thinks has changed.
Try deleting all the files (copy existing files to a new location or rename the folder, if you want), and try your Publish again.
I've encountered a problem where part way through building a solution, VS 2010 becomes locked and never returns. If I build individual projects one by one it works so the building of project is working. The solution contains XNA projects for various platforms and winforms libraries. This did work up until a point but have found no explanation for the sudden freezing.
I've uninstalled all of my plugins to see if that helps but no difference.
In task manager, VS2010 is busy doing something as it's using CPU and consuming memory >1GB.
It took a significant amount of time/removed music to sort it.