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.
Related
I have (fairly large) C# solution in VS 2019, running with ReSharper. Since a few days - and I can't make out the trigger - the following happens:
I change code, add a breakpoint (not required, but makes the issue show nicely), click "Start" (triggering a build and a run) and the application runs, but using old code.
The breakpoint changes to "broken" after the build, which is quick. And the build log is unbelievably short, without any warnings, but also without errors. It lists that the project I made the change in was successfully rebuilt or at least that the build was started.
I thought I may have this issue, but the code executed is the old.
Is this a caching issue? Can I get better logs somewhere?
Is this (full re-install of VS) the only solution?
EDIT: It appears to be getting worse, by now I have to manually/explicitly rebuild my solution before running (almost) every time. And, if this is any hint: while trying to fix the issue, I deleted the hidden .vs folder (where the. suo files lives) - and it has not been re-created. Shouldn't it have been?
EDIT2: The link from dwcanillas below inspired me to search deeper in my solution folder for any nested .vs folders and, indeed, I found a few - not for every project, but for some. I deleted them all and today so far it appears to be better.
CURRENT SOLUTION (another visual studio voodoo recipe):
Clean top-level solution
Close Visual Studio
Delete all ".vs" folders (hidden, in every solution folder)
Open Visual Studio
Rebuild top-level solution
Observed side-effects: Previously unloaded projects will be loaded again. But there's probably more...
You may have to, though try rebuilding it first, and cleaning the solution as well.
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.
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.
Intro
I don't know if this is a bug or there is something I'm completely missing.
I have a Project (Windows Service), let's called it WINSERV. And I have 3 DLL's which it depends which come from 3 seperate Projects (Project A, B, C). However A has a dependency on C. And B has a dependency on A and C.
When Building Installer with InstallShield LE, for some reason my Project C is always a STALE version which I cannot get to change. I increment the version, "make clean && rebuild", and the installation (on a remote server) always includes the STALE version.
I set each project that has a dependency on C, to not "Copy to Local", so allowing Project WinServ to maintain the "reference" itself, and copy it across for the Installer.
Problem
But again, no matter what I do, when I install it's the stale version. After a few hours, I did manage to get around the problem, by removing "Copy to Local" on Project WINSERV, and adding in Project C as an addition to Application Data (Project C's Primary Output) to the InstallShield Install Project. This seems to work!!!!
Question
I did try "MAKE CLEAN" a thousand times. I checked Project C DLL version before building and creating the Installer and it was always STALE, old version.
Anyone can explain this? or Bug?
PS. InstallShield LE does not do Windows Services so if you reading this, don't get caught out.
It's definitely a bug in Visual Studio 2012.
I've managed to replicate in the following fashion:
While having a Project opened (referencing let's say MYSQL 5.1.4).
I then commence to uninstall the MySQL Connector and install 5.1.7.
I close Visual Studio 2012 and recompile and all works well.
However when I build with InstallShield it still references 5.1.4 despite it being uninstalled. My thoughts is that it's caching it somewhere and accessing it later during the build process.
How I solved it, is after installing a newer/older/different version of an existing DLL, I then REBOOT my machine and all is now well.
Hope this helps someone
Sounds like a similar problem I had.
For some reason InstallShield sometimes gets DLLs from the temporary ASP.NET folder (even if your project is not ASP)
Try clearing the folder: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
I have a Visual Studio 2010 Ultimate C++ project (not managed or .NET). When I press F5 (i.e., start debugging), I want it to save all the files, rebuild those that changed, link the whole thing, and then run. Instead, it appears to use the last build. Thus, when I try to step into a function or something, I get the following error:
Based on my research, I have verified these options, the first three of which are in the Options dialog (can be reached under "Debug->Options and Settings"):
"Projects and Solutions->Build and Run->Only build startup projects and dependencies on Run" is checked. Some research indicated that it should be unchecked, but in my case I actually do only want it to rebuild the startup project. For what it's worth, I've tried unchecking it, with no effect.
"Projects and Solutions->Build and Run->On Run, when projects are out of date:" is set to "Always build".
"Debugging->Edit and Continue->Enable Edit and Continue" is checked, though it's greyed out.
In the Configuration Manager ("Build->Configuration Manager"), all solution configurations and platforms have their "Build" checkbox checked.
I have also tried deleting all Debug and Release directories as well as the .sdf and ipch directory.
For completeness, I suppose I should mention that I'm using precompiled headers, though I kinda doubt it matters.
[EDIT: I should note that it only seems to be one file (a .h file) that's doing it. I tried renaming it and recompiling, and also removing it from the solution and adding it back in, but it didn't work. ]
I was able to bring my solution back into the right state after deleting all .suo and .csproj.user files. Answer led to this solution. Hope this saves someone time.
I fell into this state after installing Ultimate over Professional and running profiling tools.
Once I had similar problem with my C# project and I think I have tried every possible suggestion available on internet but none worked and then this is what I have done:
Created an empty Project
Added startup function to verify that it does not show any error
Imported all my source code manually one by one
So, Yes, it was the solution. You already have done a lot so I would say you can get lucky by trying here and there however having a new project and importing your individual source file would be faster.
Another solution could be that switching the platform. I noticed that when I when to project properties, the new project I had just created had a platform of 'win32' and my other projects in the same solution had it set at x64. After I switched my project to x64, everything worked just fine. This worked for my interop(C,C+, C#) project and hopefully works for other projects as well.
I have successfully resolved it, try the following:
remove all temporary and intellisense files
remove all project from solution and then add them back(most important)
check projects 'Frameworks and References' to ensure they are valid