Visual Studio hangs constantly during build - visual-studio

Probably between 25 and 50% of the times I build my solution, I see this:
"The operation you requested is taking longer than expected to complete. This dialog will close when the action completes."
I hate this window in ways I can't describe. It never resolves, the Cancel button is never enabled, and the only way to remedy it is to kill the devenv process and load up my entire solution again, knowing full well that I've fixed nothing and I'm equally liable to see the same thing when I attempt my build.
My solution is about 60 projects in total, which are mostly C# class libraries, with a few each of web applications, web services, and console applications. However, the problem persists even when building one slice of the codebase with the majority (50) of the projects unloaded.
My problem is that the output windows doesn't tell me anything at the point at which it freezes, and I don't know how else to determine the cause of this lockup. If I were to guess, I would assume that it's a deadlock in the filesystem or something, but I don't know how to go about proving this--much less how to prevent it.
What can I do to diagnose and eliminate this from my solution so that I never see it again? In general, how can I diagnose problems that occur during a build?

Had a similar issue, VS would hang for 45 or so seconds then build for 4 seconds and complete. The 45 seconds of hang would not produce any output to GUI and VS would hang.
Using ProcMon I could see 3 million+ file operations on the /packages/ folder via devenv.exe when I would build this project (and would continue for some time after)!! The first steps of the build you can see that it was checking EVERY PACKAGE to see if it needed to do a package restore (it did not).
Since I tend to blame NuGet for everything, I disabled NuGet Package Restore "allow NuGet to download missing packages" checkbox under Visual Studio -> Options -> Nuget Package Manager -> General. To my delight, the build was very fast. 5 seconds total!
Turns out that we had enable package restore on build enabled (I think this is on by default now in VS) AND we also had the packages checked into source control. It seems this causes TFS to thrash in some way... Checking for restoring packages must trigger TFS to do some source control operation checks.
FYI this was VS2013 UPDATE 4 - Nuget version: 2.8.50926.663, on a sln with NumberOfProjects = 38, but I could recreate this hang just building a single csproj with 2 dependencies.
Update:
Localhost "Rebuild All" on Sln with SccNumberOfProjects = 53 was taking 7:05 with 2 minutes of visual studio frozen / unresponsive
down to 4:14 on a 2 core i5 with no freezing
down to 2:44 on a 4 core i7
Also: This was on a machine with various file watcher security tools, likely not adding any speed to this whole process... and possibly to blame.
Update in 2021:
If you are looking for a paradigm shift, the new SDK style csproj format (see migration tool) + nuget PackageReference makes updates almost instant (< 20 SECONDS for same projects in scenarios above) - highly recommend you upgrade any legacy projects.
** Known incompatibility - website package references do not support static file references via nuget ( checkout LibMan)

I have seen this happen on large projects when MSBuild is running with the diagnostic switch turned on. In Visual Studio, go to Tools / Options / Projects & Solutions / Build And Run, then check the MSBuild project build output verbosity value. If its not set to Minimal, try setting to minimal and see if your builds are able to complete.

I did not try any of the above solution as by the time I tried my approach - all was well again.
My steps are as following:
Close VS
Delete the .vs folder
Open my solution
Clean Solution OK
Build Solution OK
Optional Rebuild OK

In my case setting "maximum number of parallel project builds" to 1 kinda helped (i.e. building a project from clean state causes 1 min freeze followed by normal build and every subsequent build works fine).
Aforementioned setting can be set in Tool -> Options -> Projects and Solutions -> Build and Run.

Seems like running Visual Studio as Administrator solved the problem for me! (For always running a program as Administrator see How to Run Visual Studio as Administrator by default)

I've found Visual Studio hanging a lot on building larger projects. Turns out it was ReSharper. After I turned it off: Tools -> Options -> ReSharper -> Suspend Now, everything built fine no issues (even on very large solutions, 100+ projects)

There was a suggestion on Microsoft Connect that Modelling project was responsible for the freezes. I removed a Modelling project from our solution and have experienced no freeze since then (about a week).

For me it was something to do with npm package install that ran automatically. I went to Tools > Options > Project and Solutions > External Web Tools and unchecked all external tools and restarted VS. After that, I was able to build it again. I know I need them to be checked but I need to figure out what's triggering them and what's wrong with this solution file.

VS2019 exhibits this issue as well for me, in my case, the problem was because of dependencies stored on a network share. I have a hunch that Windows Defender Antivirus was scanning a lot of extra stuff that was in the network share, which is only accessible when connected to a fairly slow VPN.

For me the issue was witch an extension that automatically runs T4 templates on build (AutoT4). Disabling it when working with solutions with EF fixed the issue.

I moved my VS 2008 development platform from Windows 7 to Windows 10 and encountered a situation where Visual Studio would hang up every time I tried to build a large project. I had to build the project, then use the Task Manager to kill VS and then restart. Needless to say, this made debugging really difficult! Anyhow, the problem was that in moving to Win 10, VS was no longer running as administrator (and perhaps Win 10 is more particular about privileges). Changing the properties so that the program ran as administrator resolved the problem. (IngoB -- I don't have enough status to comment on your post, but thanks for pointing this out!)

Just try below command with admin mode. Before running this command make sure to close all VS instance.
devenv /resetuserdata
Note: devenv is located at C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE

In addition to the felickz's answer which solves (or almost solves) this problem for builds:
Except the problem during a build I also had problem with the Package Management Console. It took about a minute to wait for it. Using the procmon I found that the NuGet repository folder was parsed each time this window is opened (very smart, Microsoft!). There were about 1000 packages in this folder. After removing everything from the above folder the performance problem diapered.
Note that my answer relates to the VS 2015 (and may be below). I didn't tested, but suspect in VS 2017 it should be ok.

Visual Studio 2017
Removing Anaconda3 from the installation fixed it. In procmon I saw hundreds of thousands of calls looking for files in the Anaconda3 folder from hundreds of instances of powershell spawned by msbuild.

I had this problem because of an issue restoring nuget packages. There was a duplicate entry in the packages.config file. Rather than report it as an error, the build would just hang forever.
I didn't discover the problem until I tried to restore the nuget package through the "Manage Nuget Packages..." option in the menu. After removing the duplicate, the build completes properly.

Related

Visual Studio 2022 Can't Build Any Projects

Every time I go to build any project in Visual Studio 2022, all I get in the buil output is:
Build started...
1>------ Build started: Project: ConsoleApp7, Configuration: Debug Any CPU ------
The example above is a simple default template for a .NET 6 Console app.
It never progresses any further than that, the CPU sits around 0-3%, and the build has to canceled. Nothing happens, there's no errors. Same thing happens if I clean, or rebuild.
That's the full output with MSBuild project build output verbosity set to "Diagnostic"
I have VS 2015, and VS 2019 installed on the same computer, can can build projects fine.
I've tried:
Uninstall/reinstalling VS 2022
Clearing the cache (https://errorhandlinginskills.wordpress.com/2018/07/28/how-to-clear-visual-studio-cache/)
Adding/removing features from VS
Rebooting the PC
Restoring Nuget packages manually (right-click solution -> restore)
Checking for VS updates
Running the dotnet commands from Powershell (dotnet run/clean/build) all work fine
I just can't think where to go next with this. Any help or suggestions, would be greatly appreciated, maybe even some condolences at this point ;).
The problem turned out to be caused by Symantec Endpoint Protection. It's an antivirus software that seems to kill processes it doesn't trust, by injecting its own DLL and causing them to fault.
So whenever msbuild.exe was running, Symantec would kill it. To resolve it, our IT team needed to add a policy to allow msbuild.exe.
Strange VS didn't detect MSBuild.exe had died, it just say there indefinitely.
I found this in the Windows Event Viewer under Application Events:
I have the same problem as you, since February 28th, VS2022 could not build any project, until today, I uninstalled the anti-virus software (360 Security Guard) installed on my computer, it returned to normal work, I think this is due to the anti-virus software update caused by the incompatible VS2022, You can try uninstalling the anti-virus software installed on your computer, which may solve the problem

Visual Studio (Community 2019) throwing errors which should be warnings regardless of settings in one project only

A couple of weeks ago I cleared the NuGet cache in Visual Studio... this broke everything for some time as it would not automatically restore all the NuGet packages for some reason.
After a lot of effort and manually restoring stuff, I have now got most projects in my (quite large) solution working, except one.
I am in the process of moving most of my code from .NETFramework projects, to .NETStandard and the websites to .NETCore, that in itself is a headache and may/may not be related to the problem, but I don't think so.
Anyway, this one project, which is a .NETFramework (4.7.2) web application and references many other projects in my solution, will not build properly.
Each time I build it, I get thousands of stupid errors from MSBuild, see the screenshot (ignore the top 4,they are genuine!). These are all errors which should be warnings, or ignored.
In the Project settings page I do NOT have "treat all warnings as errors" checked - in fact, in an effort to fix this, I have turned warnings off altogether as well.
The weird thing is, that if I build every individual project in the solution first, usually twice, and then build this one with out touching anything else, it then will build and launch in IIS (or publish)
So the site is actually working but something is wrong in MSBuild or VS that is breaking it.
I have tried running a Visual Studio repair, but that made no difference either.
EDIT also, it only does it on one PC, if I load the same solution onto my laptop, it will all build fine.
And from some of the errors, if seems that the you should change the Assembly Name of the SAM project to Sam. It is quite strange. Not sure whether you have install some extra Code Analysis extensions on your current PC but other PCs works well.
So please try the following steps:
Steps
1) disable any third party installed vs extensions under Extensions-->Manage Extensions-->Installed
It needs a restart.
2) run update-package -reinstall under Tools-->Nuget Package Manager-->Package Manager Console
3) close VS, delete .vs hidden folder under the solution folder, every bin and obj folder of the projects under the solution.
Besides, you could use devenv /safemode to start a initial VS without any third party tools to test whether the issue happens.

MSTest cannot find TestAdapter.dll

I'm using the built-in Visual Studio test tools (Test -> Run -> etc in the menu). I just started having a problem where I get the following error when I try to run tests
[3/29/2018 1:39:14 PM Error] System.IO.FileNotFoundException: C:\Users\brubin\AppData\Local\Temp\VisualStudioTestExplorerExtensions\MSTest.TestAdapter.1.1.18/build/_common/Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll
at Microsoft.VisualStudio.TestWindow.Controller.TestPlatformProvider.PerformShadowCopy(IEnumerable'1 testExtensions)
That's followed by some errors that say
Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
When I look at the folder C:\Users\brubin\AppData\Local\Temp\VisualStudioTestExplorerExtensions\MSTest.TestAdapter.1.1.18/build/_common/, there are no files in that folder. However, I haven't knowingly changed anything about my test setup and this was working several days ago, so I don't know why it would have stopped working.
My projects are using the MSTest.TestFramework (MSTest V2) version v1.2 NuGet package.
One thing I noticed that may have caused this problem is that if I go to Tools -> Extensions and Updates, I see that my Microsoft Visual Studio Test Platform was updated a few days ago, on 3/23 (I think that's when I installed a Visual Studio update). However, if that broke something, I have no idea where to look to see what's broken, or how to fix it.
For me, clearing the VisualStudioTestExplorerExtensions folder and restarting Visual Studio (as per this github issue) did the trick. In my case, it contained two folders for different versions of MSTest.TestAdapter, I don't know whether or not that's relevant.
For anyone else who stumbles on this question, the problem was caused because a few of my test projects didn't have the MSTest.TestAdapter NuGet package included. I added the MSTest.TestAdapter package to all of my test projects, and the problem seems to be solved permanently now.
I spent the whole last week trying to solve the same issue. Only yesterday did I realize that running tests from the console is a time saver. Much to my surprise, I've just moved all my project -which was inside a "OneDrive" folder, to a different location. Now, it works like a charm! All my tests run from the Visual Studio IDE. I don't know if moving the files had anything to do with it, but you can give it a try.
Reinstalling all solution's Nuget packages fixed this issue for me.
Please run this command on the package console:
Update-Package -reinstall
then try again, or restart VS, then try again.
Reference: https://ardalis.com/force-nuget-to-reinstall-packages-without-updating/
Its a bug in Visual Studio. Upgrade the Visual Studio to version 15.7.
https://developercommunity.visualstudio.com/content/problem/222892/filenotfoundexception-microsoftvisualstudiotestpla.html
Yes you need to update "MsTest.TestAdapter" on all testprojects. The easiest way is to rightclick on master solution and click on manage nuget-packages. Then select " installed " tab and see if there is installed TestAdapter on each testprojects. If necessary you can update TestAdapter to newest version. Then restart Visual Studio and it should work.

Cannot compile solution in VS due "Attempted to access an unloaded AppDomain" -- how to pin it down?

I have a C#/ASP.Net solution in VS (2008) with several projects within it. When I try to compile it I get one error only:
Attempted to access an unloaded AppDomain
No line code, no project name, nothing. Just such error.
How can I pin down this error -- i.e. the cause, or even better -- how can I solve it and continue compilation?
Thank you in advance.
Shut down Visual Studio and reopen it. Then clean the Temp folder.
For that press Windows+R and type %Temp% and click Ok, then delete everything.
If this error comes with VS follow these steps
Just restart your VS.
Start VS again
Clean the solution (Build> Clean Solution)
Rebuild your project again
If this error comes with IIS
Restart (recycle) the IIS Application Pools in IIS Manager, After restarting check run the solution again!
There are many possibilities:
Try resetting your Visual Studio's
Setting.
Or check all dlls which are
referenced.
Check all the namespaces which are
being used in your application, Do
they exist?
I am experiencing the same in Visual Studio 2012 - but ONLY on websites hosted on UNC share. My solution (when it occur) is to unload the web project and reload it again. Then in works for some time again.
The problem as I recall it is, that the hosted UNC share (or the workstation trying to access it) is running an x86 version of Windows, which does not allow to many open network connections.
In my experience these sort of problems disappear on true x64 environments.
Cheers.
it means, there is something in WebConfig/AppConfig not compatible and cannot load.
For ex.
İf you published project, check app_data/publish profiles, delete them.
Check your .sln file first if it is conflicted then delete it and update your svn folder and rebuild your solution.
Rebuild your solution
It's also possible that your unit test started up a thread but didn't close it. Ensure your threads are all closed before completion.
It might be a good idea to verify all your unit tests are running and passing correctly.
Exit the local webserver(IIS express) from the system tray and delete asp.net temp files from temporary folder & then try clean,rebuild and run your application
Following are the steps i followed to get rid of such error-
Press Windows+R , write %Temp% and hit enter. Now,delete all the temporary files from the directory.
Restart your visual studio.
Clean your project solution from Solution explorer in Visual studio List item.
Rebuild the project & Run .
It should work expected.

How to determine why visual studio might be skipping projects when building a solution

I am debugging someone else's work and the solution is quite large. When I try to build the entire thing, several projects within the solution don't build and just skip. Viewing the output window during the build process says:
1>------ Skipped Rebuild All: Project: pr1lib ------
How can I determine why these builds were skipped? I am unable to find additional output.
This is with VS2008 and the solution is comprised of c# and c++ code.
Right click the solution, choose Properties and then Configuration Properties. Here you can choose which projects to build.
[edit]:
See Kdt's comment: ... when I looked in configuration properties ... the project build target was configured for "Mixed Platforms" while the solution was set to build "Any CPU".
*When this problem happened to me, The main project only had 'Any CPU' and it set the child dll to 'any CPU' too, however, I'd deleted that profile and left only 'x86'. Picking x86 for just the dll make it start working
[/edit]
Build, rebuild, and clean operations were being skipped. Unloading and reloading didn't help, and neither did restarting Visual Studio.
Once I removed the project from the solution and added it back, it is no longer skipped. To remove it, in Solution Explorer, right-click the project > Remove > OK. To add it back, in Solution Explorer, right-click the solution > Add > Existing Project and select your project
I just had the same problem- "unload project" and "reload project" solved the issue !
Restarting Visual Studio did the trick
If the confixguration is x64 and the x64 compiler isn't installed it will skip the project.
My solution is the same as mentioned previously: Delete -> Add existing project
But this solution implies that references between projects get gone
To avoid re-adding references: and in case if you use version-control system like GIT or TFS or whatever, it is possible to acheve goal with the following steps:
Make shure that all the changes are commited / checked-in before the operation
Go through all projects deletting them from solution and adding-existing them
Notice that the .sln file has changed
Keep the new .sln file, but undo the changes to all the .cspoj files with the version-control system
I had a weird one that may be worth documenting amongst the other possibilities here..
I'd added a Shared Project to my solution, with code that was used in two or three of the other projects. As you're aware - Shared Projects are just code, and not really a project in the traditional sense.. You can't 'build' a shared project, it's just code that is embedded into the other projects, and then built there.
But somehow my solution file had been updated as if the shared project was it's own thing that needed building. I'm guessing then that any time I was trying to build and I hadn't changed the code in the shared project, then it figured 'nothing has changed, skip those builds'
I found the shared project in the solution.sln file like:
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "Api.Common", "Api.Common\Api.Common.shproj", "{EC580471-D78A-4509-AC46-BD565553AD60}"
..which is fine. What isn't fine is that this project also appeared in the GlobalSection(ProjectConfigurationPlatforms) = postSolution like:
{EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.Build.0 = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.ActiveCfg = Release|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.Build.0 = Release|Any CPU
I removed those four lines from my .sln file, and now things seem happy again
The visual studio 2008 , it can be because 64 bit compiler wouldn't have installed.
Control Panel --> Programs and Features -> Microsoft Visual Studio 2008 professional --> [double click]
On Visual Studio Dialog
Next --> Add/ remove Features --> (Under) Visual C++ --> (select) x64 compiler and Tools
The first thing you need to do is diagnose why the build is skipping projects. So to get a detailed build output change the verbosity to detailed in the following place in Visual Studio.
Problem exists in VS 2010 as well; of the proposed solutions: editing build config, cleaning, changing/re-changing target framework, do NOT work. But unloading and reloading the project does.
I've just had this issue, and was able to resolve it by removing the hidden .vs folder in the topmost folder. After restarting Visual Studio everything worked again.
Hey, just fixed this one. Thought it might help. You most likely didn't install corresponding compilers along with the visual studio. This happened to me today - by default, VS 2008 installer doesn't install x64 C++ compiler.
If you have SP1, uninstall it before changing VS installation. When done, install SP1 again.
Close visual studio
Open the sln file with notepad
delete all of the things like this :
{B546C55D-9321-4FC0-B25C-46844222BEBE}.Debug with
Fakes|x86.ActiveCfg = Debug with Fakes|x86 (there will be a bunch of
them)
4.save the file
5.open visual studio and all better
Go to the build menu and choose "configuration manager". This will show which projects are configured to build in your selected configuration.
I had a similar thing just happen to me. I'm not sure what the problem was, but it would not Clean, Build, Rebuild, etc. I am operating in Visual Studio 2017 and wanted a netstandard2.0 assembly. The issue for me was that somehow the project type was incorrect, maybe I started from a netcoreapp class library, something like that, stuck in the Solution file, I do not recall. Anyway, I backed up the project, created a new netstandard class library project, and factored in the backed up bits, and that fixed it for me. HTH someone.
i updated to 15.9.11 , ... after some builds, same problem:most projects are skipped (which build a second ago without problems). Unloading/reloading the solution helps always in my case, but it will happen again soon.
I have no idea why... except a big bug in VS2017
I checked configuration manager , all checkmarks are set to build.
Maybe, it has something to do with nuget packages, but that is just a guess
The solution has only c++/vcxproj, no csproj. 64 and 32 are installed both
This happened to me in VS 2019, and the solution was to simply restart visual studio.
My build configuration was never modified.
I checked-in my project to source control from one computer and downloaded it to another and it will not build properly there. It will skip building projects and didn't even create the master \Debug folder for outputs.
The solution (VS2019) is to right click on solution and select Configuration Manager.
I saw the build checkbox was not checked for two projects that I was building (shown below). I don't know why they were unchecked but checking them and building project worked!
Right click on solution ->Remove then Add the existing project, this worked for me.
Had the same problem, found out that the project setting was for Itanium CPU, changing it to Intel fixed it.
Was running into the same problem with VS2005, all the configurations were correct .
It was even skipping the Clean project command.
Finally Unloading /Reloading did the magic.
Right click on Solution at at your solution explorer, then, click on Property at bottom of the menu. In the property windows, click on Configuration Properties -> Configuration on the left pane, you will see the list of projects on right pane, make sure Build check box is checked in the popup window.
If your solution contains a NuGet project (*.nuproj) file, try unloading it and then rebuilding your solution.
This worked for me after none of the above worked.
I had similar problem, I had one project which could not load in solution explorer due to some reason. When I loaded that project it worked like a charm.
I find that sometimes when you have target platform as set to lets say x86 in your solution and in your projects the project does not actually always had it selected.
To double check go to the project properties and see if you can select that platform in the Build->Platform setting if you can not then you will need to go to the configuration manager and create that configuration.
I had this problem with some Windows CE projects on a new PC. "Unload project" and "Reload project" appeared to fix the problem, but actually Visual Studio had simply switched to a different platform and built that.
It turned out that although my WinCE platform was shown as the active platform, Visual Studio didn't "really" see it. The solution was to reinstall the WinCE SDK with administrator priveleges:
Make sure Visual Studio 2008 is not running.
Open a “Visual Studio 2008 Command Prompt” as Administrator. On Windows 7 just right click the short cut and pick the “Run as administrator” option.
Enter the following command: msiexec /log SDKInstallLog.txt /package <the path to your .msi file>
When asked if you wish to do a custom or complete install pick custom, and instruct the installer to omit the installation of the documentation (this step was not necessary in my case; in fact I just asked it to "repair" the existing installation.)
Install
VS 2008 will skip x64 targets if you don't have the x64 compiler installed. VS 2008 does not by default. Kind of a duh, thing.
I had a very similar issue after generating a project from a decompiler from Telerik, then trying to recompile it. The project was skipped whenever I tried to rebuild it. Tried a lot of the suggestions above, but for me, it was the .NET Framework selected in the project properties.
Right-click project in solution file, select properties, application tab, change target framework from 4.0 to 3.5.
Then, rebuild, and I got a bunch of assembly reference missing errors, which makes sense since I haven't added references to them yet.
I update one small update of Visual Studio 2017 and then the installer reminds me to restart my computer,but I did not restart.When I build my project or solution in Visual Studio 2017,I meet the same above problem.I guess the update maybe the key,so I restart my computer,I did it.:>
I had this problem in Visual Studio 2017 15.9.4 and after some searching and putting some time I found out that in my solution the .csproj file of one of projects got corrupted after merging in TFS. (I could build other projects by unloading the problematic project from solution).
How I resolved my problem was that I compared the .csproj file before and after the merge and do fix that. And by fix I mean since my own project's type was .netStandard I removed unnecessary lines including Configuration PropertyGroup, all and others in the new .csproj file to make it similar to previous .netstandard-style version.

Resources