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.
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.
I found the following information about the Microsoft Visual Studio "extra" files:
What is the purpose of the vshost.exe file?
My question is, is there a way that I can NOT have the .pdb, .manifest and vshost.exe files from being made? Or are they absolutely necessary?
I just noticed that after debugging it, it's still showing up as a running process in my machine which worries me since I already closed it.
Switch to the Release configuration. Then Project + Properties, Debug tab, untick the "Enable the Visual Studio hosting process" option. Build + Clean, you can delete anything that's left and it won't come back. That this option is turned on by default for the Release build is, arguably, a bit of a flaw but defensible.
The hosting process is a custom hosted version of the CLR. Exactly what it does is not well documented but it is related to configuring the security settings of the primary AppDomain. I've never heard anybody complain about battling CAS problems without it, but then it is unusual to turn it off and your app almost always runs in full trust when debugging from the IDE. It would matter if you build to a network share on early versions of .NET. The only thing that's obvious from disabling it is that anything you write with Console.Write in a gui style app will no longer appear in the Output window. It has nothing to do with speed as claimed in the highly upvoted answer in the link, the core framework DLLs are already resident in RAM since VS and MSBuild uses them.
Best thing to do is just not worry about it too much. A Setup and Deployment project will ignore it.
Regarding vshost files, at least in VS2010:
They are not generated on build, but on selection of build configuration (it will be generated in release when we select release for the first time) and on setting "Enable the Visual Studio hosting process" to true. (As configuration debug and this option set to true are defaults, vshost.exe will be created in bin/debug on opening VS with target project by default.)
They are not cleaned on rebuilding or cleaning the project, but only manually when "Enable the Visual Studio hosting process" is false if VS with that project is open. (And it won't be generated anymore when opening this project.)
If this flag option is true and VS with target project is opened, this file cannot be deleted as being used. Once when it is unchecked, vshost.exe can be immediately deleted.
Summary: Generating and removing these files is not related to build process.
Also, I may add that option "Enable the Visual Studio hosting process" in referenced projects which are class libraries is not considered. This option is only considered for target project which generates executable file.
setup:
all development being done on virtual servers (Win Server 2003)
all compiles being done in VS 2010
all code checked into TFS 2010
We are migrating our solutions from VS 2008 to VS 2010. I created a MAIN branch folder for containing our converted VS 2010 projects. I then branched over and worked through getting projects migrated from 2008. The compiles were (eventually) successful. Another developer was working through other projects on the same branch.
We then got all of these projects compiling also through TFS Build 2010.
This is our MAIN branch. Another developer then created a DEV branch folder and branched all of the solutions from the MAIN branch to the DEV branch for ongoing development.
Much to our surprise, we found that though we could compile the code if we did a get latest on the MAIN branch, when we did a get latest on the DEV branch (supposedly the same code), some of us (we'll call them the unlucky developers) got a slew of errors having to do with a reference to a project contained in the solution. But two developers (lucky) had it compile just fine. When the two unlucky ones compile the individual project (the one causing the reference error) it builds fine, but when we build the solution or the referencing project, it fails with the reference to that project.
We tried wiping out our workspace and doing a get on the code fresh - no joy.
The lucky person who created the branch did the same (deleted their workspace, did get latest and ran a compile) and it still compiles. We then had a developer that hadn't been involved in the migration do a get latest and run a compile. Their compile ran just fine too! This led us to believe that it must be the computer.
So then we had one of the unlucky developers log into one of the lucky developer's virtuals and perform a get latest and build using their own workspace. This also failed. So this virtual has one workspace under one user that succeeds, and one under another user that fails to compile for the same get latest on the same code.
Then... we detached the working workspace from the lucky developer's virtual and one of the unlucky devs attached to it (no get, just compile what's there). That compiled fine.
So it feels like we may have some sort of characteristic attached to us unlucky devs that are causing our Gets to be different. One difference I just realized is that we two unlucky ones have shelvesets that we saved in TFS in the 2008 versions (but under TFS 2010).
OK, Then... the same unlucky developer wiped out the lucky one's workspace by deleting the files and then performed a get specific / latest / both force overwrite switches turned on. This compiled successfully!!
Then he went back to his original virtual machine. He deleted the files in his workspace, and did a get specific / latest / both force overwrite switches turned on. This compile again failed!
We're running out of ideas...
Sounds like the (unlucky) developers may have custom workspace mappings (determines which folders in TFS are checkedout where on the hard disk).
View -> Team Explorer -> Source Control -> Click the dropdown on Workspace and select Workspaces...
Delete all the workspaces there (or at least verify them).
Create a single new workspace and checkout at the root level (to keep project references intact)
Well we got bit once again. The issue had to do with the length of the path to the source code. Of course there is no indication of this in the actual error. This is probably the 8th time I have run into this. It is frustrating while trying to keep namespaces meaningful to constantly have to trim these paths.
We had dismissed this possibility, because the names of the developers who were able to compile the code were longer than the two who couldn't, and the names are in the path of the workspace by design so that multiple developers can work on the same virtual machine as needed.
I believe I found out why. I had my compile set to "Mixed Platforms" and the ones who could compile were set to "Any CPU" Maybe this was in the path.
The solution was (once again - this is getting really old) to move the project down a few folders instead of containing it where we had hoped to. This reduced the number of characters in the path and the compile ran just fine. Ugh.
I have 3 projects in a VS6 workspace.
One is the main program, which calls - depending on configuration - one or both other progams. To call the other programs a exe is executed.
If I want to debug and set breakpoints in one of the subsequent programs, I get an error that breakpoints could not be set and have been deactivated.
Are there any VS6 settings I can check?
This is a legacy tool and neither the architecture nor VS6 can be changed. To make things worse I am not very familiar with VS6.
I don't remember exactly the behavior of VC6, but i think you can start 3 instances of Visual Studio, each containing one of the projects (you'll have to create 3 different workspaces). Within each instance you can debug one program. This at least worked with later Visual Studio 2005.
A common reason for that error is if you have set one or more of the components to build in Release mode. Make sure that they're all set to build in Debug mode.
Can't remember where those settings are I'm afraid, but I think they're fairly easy to find (under some project menu?).