I have a strange issue:
While i'm coding, my Visual Studio randomly -out of nowhere- says it cannot find the previously installed Nuget Packages. Then it marks half of my code with errors as the packets for the usings are missings.
I then have to download them again and the issue is instantly fixed. These package deletions happen completely out of the blue and since a week over and over again. I cannot track down the issue why it deletes these packages in the first place (?) (or is unable (?) to find downloaded Packages).
Is there a known fix to this?
These package deletions happen completely out of the blue and since a
week over and over again. I cannot track down the issue why it deletes
these packages in the first place
I wonder if you download the project from any code hosting platforms like TFS before you encouter this issue. And from your description, the nuget references are missing which is not a normal behavior. Also, I want to know exactly what you did to cause this issue.
To troubleshoot your issue, you can try these steps:
1) close the VS Instance, delete NuGet.Config file under C:\Users\xxx(User Name)\AppData\Roaming\NuGet\NuGet.Config, restart VS and then restore nuget packages.
2) Besides, every time you encouter this issue, Right-click on the Solution-->Restore Nuget Packages and this will restore any nuget missing nuget packages.
In addition, please make sure these two options are checked by Tools-->Options-->Nuget Package Manager-->General-->Nuget Restore. And the missing packages will be restored automatically when you execute Build.
Hope this could help you.
I'm trying to figure out a) if I'm going about this in the right way and b) how to update a solution level nuget package.
The core problem is that when a package is installed at the solution level (rather than in any particular project) and you try to update it, it doesn't remove the old reference. It just adds a new package reference, and imports both version. Which typically means (what with how powershell modules work) that the earlier powershell modules override the newer ones.
So what I have to do is uninstall the package and re-install it, which grabs the newer version. Seems inefficient.
Also, I can't seem to install or uninstall a solution level package from console. I have to do it with the Manage Nuget Packages utility, which I hate to use.
Here is some background on what I'm doing, if it helps:
I've set up a system at our company of using solution level nuget packages to add custom powershell script modules to the solution, as well as some more generalized scripted solutions I've written (like deleting TFS work items or changing a project name on the file system as well as within code).
So one project might have the DataServiceUtilities package and another would have the FrontEndUtilities package.
So, how can I update these packages without it adding two references? And can solution level operations be done in the Package Manager Console, which always defaults to targeting a project?
It appears that some of this comes from bugs in the Package Manager GUI tools, and Nuget in general
The Package Manager GUI tool doesn't handle updates properly for solution level packages. But if you run Update-Package from the package manager console it will correctly uninstall/re-install the solution-level package.
As for installing from command line, if a package has only a tools folder and no dependencies you can run install from command line and it sill install in the solution and ignore the default project.
However, as of now (Nuget 2.8) Nuget has a bug in it that causes it to treat solution-level packages with dependencies on other solution-level packages as project-level packages. It's apparently been in for about a year, and they claim it will be fixed in VS 2015. You can see the bug here: https://nuget.codeplex.com/workitem/3642
What this means is you cannot currently create a solution-level package with ANY dependencies. Please note that this is legal according to the documentation. Hopefully it will be fixed next year.
*Update
Just a quick update. It appears that in VS 2015 they have deprecated (or, more accurately, removed) solution level/tools only packages. After some out outcry they also decided to re-implement them in a future version, but it may be awhile before they do so.
Progress on re-implementing the feature can be found here: https://github.com/NuGet/Home/issues/1521
Discussion on how to work around the missing feature can be found here: https://github.com/NuGet/Home/issues/522
I am getting an error when trying to enable package restore in a new solution I just created. The error in VS2012 is:
NuGet Package Manager
An error occurred while configuring the solution to restore NuGet
packages on build
Unable to read package from path 'NuGet.Build.2.7.0.npkg'.
I tried opening the solution in VS2010 to work around the problem and I am also getting an error when trying to enable package restore, but the message is different:
NuGet Package Manager
An error occurred while configuring the solution to restore NuGet
packages on build
Archive file cannot be size 0.
I tried creating a new solution, but got the same result.
I then tried doing a repair on VS2012 update 3 and rebooting. Still getting the problem.
I also scanned the folder, project, and solution file for anything NuGet or .nupkg, but there is nothing there.
So how can I get this feature working again? The last time I used it was about a week ago, and I don't remember specifically what I changed since then. I uninstalled the VS Power Tools package that I installed about a week ago, but that didn't fix the problem either.
Update
I followed the "removal" instructions here and used a project I already have as a template to enable package restore manually. However, I am still looking for a better solution because this is a feature I use frequently.
I also tried uninstalling and reinstalling NuGet from visual studio, but I still get the same issue. If memory serves correctly, there was a recent NuGet update (is there a log for VS extension installation so I can check?).
I suspect that the NuGet.Build.2.7.0.npkg file is zero bytes due to a failed download. NuGet.Build.2.7.0.npkg is the NuGet package that Visual Studio downloads in order to enable package restore for your solution.
Take a look in your cache and see if this file is zero bytes. If so then delete the file or clearing the cache and try enabling package restore again. The cache is under your profile in a directory similar to:
C:\Users\YourUsername\AppData\Local\NuGet\Cache
You can also browse to the cache from inside Visual Studio by opening the Package Manager Settings, selecting General and clicking the Browse button.
All of the previous answers, plus this one: can you run .\nuget\nuget.exe update -self if this is a solution in which package restore was previously enabled?
check whether your nuget package manager is updated one or not.
Check this from Tools-> Extensions and Updates -> Updates
Update your Nuget Package Manager and then it will 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.
Nuget does not execute scripts when restoring packages in a project.
Here's the scenario: I have a project that has a custom NuGet package installed. This project has NuGet Package Restore enabled for the solution. This all is working flawlessly, which I tested multiple times by getting the project from TFS onto a empty folder.
I've added init.ps1 and install.ps1 to the nuGet package, and the package is still fetched and installed properly, but the scripts do not execute unless the package is installed manually.
To be exact, if I get the project from TFS for the first time, neither init.ps1, nor install.ps1 executes.
However, if I close the solution and reopen it, init.ps1 executes (as expected), but, of course, install.ps1 still doesn't since the package has already been restored/installed.
Both scripts execute normally when the package is installed/uninstalled manually (i.e. it doesn't run if the package is "restored").
My internet searched haven't turned up any references to this behavior. Am I missing something obvious, or is this normal when packages are restored?
The Package Restore feature is used so that not all the packages are checked into source control. As such the only thing that it does is pull down the NuGet packages into your ./solution/packages folder so that the assembly paths and references can be correctly resolved at build. NuGet does not do a re-install as part of restore, meaning that it will not do any xml file transforms or run the PowerShell install/uninstall scripts in restore.