Beginner here.
I get this build error when trying to build a project in visual studio code:
Executing Gradle tasks as part of a build without a settings file is not supported. Make sure you are executing Gradle from a directory within your Gradle project. Your project should have a 'settings.gradle(.kts) file in the root directory.
The thing is, is that there is already one there.
I believe it is because it is VSCode is using Gradle 7.x.x when I should be using 6.5.0.
Does anyone know how to change gradle version on visual studio code?
If you're using the Gradle for Java extension in VSCode and you have the Gradle wrapper in your project, the extension should use the version the wrapper is using by default, so specify the correct version there.
You can do that by manually updating the distributionUrl property in <your-project>/gradle/wrapper/gradle-wrapper.properties or by running the below command:
./gradlew wrapper --gradle-version <your-desired-version>
If you don't yet have a Gradle wrapper in your project, I would suggest you add it as it is the recommended way to execute Gradle builds. You can add it to your project with the following command
gradle wrapper --gradle-version <your-desired-version>
All listed commands are meant to be executed in the root folder of your project.
Documentation on the wrapper: https://docs.gradle.org/current/userguide/gradle_wrapper.html
I just managed to set the gradle version in VS code explicitly by performing the following steps:
Open the user settings (press F1, type "Preferences: Open User Settings (JSON)"
Add the following two settings to the file (settings.json):
"java.import.gradle.wrapper.enabled": false,
"java.import.gradle.version": "4.4.1"
Reopen your gradle project
Before doing this, VS code wanted to use gradle 7.3. It created the folder projectroot/.gradle/7.3, and failed to build my rather old project.
After performing the above changes I noticed the folder projectroot/.gradle/4.4.1 appearing and my legacy project was able to build from inside VS code.
I use CMake as a build manager for a C++ project. All my sources are in a src subdirectory, and I created a sibling build directory. Following the directions from https://cmake.org/Wiki/Eclipse_CDT4_Generator, the build commands I use are:
cd build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ../src
This creates the .project and .cproject files used to import an existing project in Eclipse. In the IDE, everything seems to work perfectly, except that the make target does not work.
When I click on a build target, the CDT build console opens, but nothing occurs. Also when I click on Project / Clean in the Eclipse dropdown menus, nothing occurs. I checked the commands invoked by the targets, and they are of the form /usr/bin/make -j8, which should work.
Can anyone help me get the make target work ?
An automatic update to CDT just occurred and everything works now. So check for updates I guess.
Hope this is followed to create target....
The docs for eclipse says:
Your project name should be different from your executable name and different from your build folder name. Otherwise, Eclipse will NOT pick up your executable as you build them. Since my build folder name is certi_build, a CMakeLists.txt file like below should work (notice the difference in project name and executable name)
PROJECT(AwesomeProject)
ADD_EXECUTABLE(AwesomeProjectMain
main.cpp
util.h
util.cpp
)
I could not use git push for my ionic app due to the node modules folder being too long.
I used .gitignore to ignore the node_modules, platforms and the plugins folder as a solution.
My comp broke and now I have a loaner comp that I'd like to continue developing on.
When I git pull from this new computer, I know how to add back the platforms and plugins with command line tools, but I'm at a loss on how to add the node modules folder.
I saved app in a zip before my comp broke, but I can't even unzip this in my new comp because the node modules folder is too long when unzipping...
How do I get back the node modules folder into this cloned directory? (Side question, can I just copy the platforms and plugins folder from my zip into this cloned folder, or do I need to use command line tools with ionic platforms add ... and ionic plugin add ...?)
You'll need to open the command line and navigate to the project folder. Then you can run the following command to redownload the node packages. The node_modules folder is only necessary if you use the gulp tasks (such as sass).
npm install
The other two commands, ionic platforms add [platform] and ionic plugin add [plugin] setup the project for a particular platform and plugin. You can copy these two folders back in. When you create a platform, such as ios, you generate a set of files that you may modify for deployment. You'll want to retain the changes to the project configuration, so I would keep them in your git repository.
I checked in a project on one computer, checked out on another, and find that the binaries installed by NuGet are missing. I could check them in to source control as well, but it looks like there's a better solution:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
I followed those instructions, now have a .nuget folder where one should be, have the following entries in my .csproj file:
<RestorePackages>true</RestorePackages>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
and yet when I rebuild my solution, the missing packages are not restored.
What am I missing? How can I diagnose this problem?
Note you can force package restore to execute by running the following commands in the nuget package manager console
Update-Package -Reinstall
Forces re-installation of everything in the solution.
Update-Package -Reinstall -ProjectName myProj
Forces re-installation of everything in the myProj project.
Note: This is the nuclear option. When using this command you may not get the same versions of the packages you have installed and that could be lead to issues. This is less likely to occur at a project level as opposed to the solution level.
You can use the -safe commandline parameter option to constrain upgrades to newer versions with the same Major and Minor version component. This option was added later and resolves some of the issues mentioned in the comments.
Update-Package -Reinstall -Safe
For others who stumble onto this post, read this.
NuGet 2.7+ introduced us to Automatic Package Restore. This is considered to be a much better approach for most applications as it does not tamper with the MSBuild process. Less headaches.
Some links to get you started:
The right way to restore NuGet packages
Migrate away from MSBuild-based NuGet package restore
Migrating MSBuild-Integrated solutions to use Automatic Package Restore
You have to choose one way of the following :
Re-installing a package by it's name in all solution's projects:
Update-Package –reinstall <packageName>
Re-installing a package by it's name and ignoring it's dependencies in all solution's projects:
Update-Package –reinstall <packageName> -ignoreDependencies
Re-installing a package by it's name in a project:
Update-Package –reinstall <packageName> <projectName>
Re-installing all packages in a specific project:
Update-Package -reinstall -ProjectName <projectName>
Re-installing all packages in a solution:
Update-Package -reinstall
Did you enable package restore mode in the project that has the missing packages/binaries ? There's a known issue that requires the packages to be correctly installed when enabling the restore mode :
http://nuget.codeplex.com/workitem/1879
Original link is dead; this might be a replacement: https://github.com/NuGet/Home/issues/1968
VS 2017
Tools>NuGet Package Manager>Package Manager Settings>General
Click on "Clear All NuGet Cache(s)"
I have run into this problem in two scenarios.
First, when I attempt to build my solution from the command line using msbuild.exe.
Secondly, when I attempt to build the sln and the containing projects on my build server using TFS and CI.
I get errors claiming that references are missing. When inspecting both my local build directory and the TFS server's I see that the /packages folder is not created, and the nuget packages are not copied over. Following the instructions listed in Alexandre's answer http://nuget.codeplex.com/workitem/1879 also did not work for me.
I've enabled Restore Packages via VS2010 and I have seen builds only work from within VS2010. Again, using msbuild fails.My workaround is probably totally invalid, but for my environment this got everything working from a command line build locally, as well as from a CI build in TFS.
I went into .\nuget and changed this line in the .nuget\NuGet.targets file:
from:
<RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)" -o "$(PackagesDir)"</RestoreCommand>
to: (notice, without the quotes around the variables)
<RestoreCommand>$(NuGetCommand) install $(PackagesConfig) -source $(PackageSources) -o $(PackagesDir)</RestoreCommand>
I understand that if my directories have spaces in them, this will fail, but I don't have spaces in my directories and so this workaround got my builds to complete successfully...for the time being.
I will say that turning on diagnostic level logging in your build will help show what commands are being executed by msbuild. This is what led me to hacking the targets file temporarily.
If anything else didn't work, try:
Close Project.
Delete packages folder in your solution folder.
Open Project again and restore Nugget Packages again.
Worked for me and it's easy to try.
If none of the other answers work for you then try the following which was the only thing that worked for me:
Find your .csproj file and edit it in a text editor.
Find the <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild"> tag in your .csproj file and delete the whole block.
Re-install all packages in the solution:
Update-Package -reinstall
After this your nuget packages should be restored, i think this might be a fringe case that only occurs when you move your project to a different location.
Just for others that might run into this problem, I was able to resolve the issue by closing Visual Studio and reopening the project. When the project was loaded the packages were restored during the initialization phase.
For me, I had an empty tag NuGetPackageImportStamp in .csproj
<NuGetPackageImportStamp>
</NuGetPackageImportStamp>
It should ideally contain some valid GUID.
Removing this tag and then "Restore Nugets" worked for me.
In VS2017, right-click on the solution => Open CommandLine => Developer Command Line.
Once thats open, type in (and press enter after)
dotnet restore
That will restore any/all packages, and you get a nice console output of whats been done...
None of the other solutions worked in my situation:
AspNetCore dependencies had been installed/uninstalled and were being cached. 'AspNetCore.All' would refuse to properly update/reinstall/remove. And regardless of what i did, it would use the cached dependencies (that it was not compatible with), because they were a higher version.
Backup Everything. Note the list of Dependencies you'll need to reinstall, Exit VisualStudio
Open up all .proj files in a text editor and remove all PackageReference
In each project, delete the bin, obj folders
Delete any "packages" folders you find in the solution.
Open solution, go into Tools > Nuget Package Manager > Package Manager
Settings and Clear all Nuget caches. Check the console because it may
fail to remove some items - copy the folder path and exit visual
studio.
Delete anything from that folder Reopen solution and start
installing nuget packages again from scratch.
If that still doesn't work, repeat but also search your drive in windows explorer for nuget and delete anything cachey looking.
Sometimes something strange happens and using Visual Studio to automatically restore doesn't work. In that case you can use the NuGet Package Manager Console. That is opened within Visual Studio from Tools -> NuGet Package Manager -> Package Manager Console. The commands within the console are simple. And to get context help while typing a command just press the button and it will give you all options that start with the letters you're typing. So if a package isn't installed, for example log4net, type the following command:
Install-Package log4net
You can do a whole lot more, like specify the version to install, update a package, uninstall a package, etc.
I had to use the console to help me when Visual Studio was acting like a weirdo.
Automatic Package Restore will fail for any of the following reasons:
You did not remove the NuGet.exe and NuGet.targets files from the solution's .nuget folder (which can be found in your solution root folder)
You did not enable automatic package restore from the Tools >> Options >> Nuget Package Manager >> General settings.
You forgot to manually remove references in all your projects to the Nuget.targets file
You need to restart Visual Studio (make sure the process is killed from your task manager before starting up again).
The following article outlines in more detail how to go about points 1-3:
https://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore
I had NuGet packages breaking after I did a System Restore on my system, backing it up about two days. (The NuGet packages had been installed in the meantime.) To fix it, I had to go to the .nuget\packages folder in my user profile, find the packages, and delete them. Only then would Visual Studio pull the packages down fresh and properly add them as references.
The best workaround that I found creating a new Project from scratch,
then import all the source files with the code.
My project was not so complicated so I had no problem from there.
I experienced this problem recently as well. The usual 'dotnet restore' and 'Update-Package -reinstall' didn't help.
I looked at the .csproj file and found that the values for these packages were inconsistent. Some were pointing to <solutiondir>\packages and some were <projectdir>\packages.
I made them all point to the same place (I believe that was to <projectdir>\packages) and then I was able to restore the NuGet packages.
I'm not sure how the .csproj file ended up pointing to two different places. Maybe from starting out in Visual Studio 2017 (or earlier) and then moving to Visual Studio 2019? Or different settings used by different programmers? I really don't know.
vs2015 no enable nuget restore problem.
My solution:
add folder .nuget, add file NuGet.Config and NuGet.targets in Directory .nuget
each project file add:
build
<RestorePackages>true</RestorePackages>
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
If the error you are facing is "unable to connect to remote server" as was mine, then it would benefit you to have this check as well in addition to the checks provided in the above comments.
I saw that there were 2 NUGET Package Sources from which the packages could be downloaded (within Tools->Nuget Package Manager->Packager Manager Settings). One of the Package Source's was not functioning and Nuget was trying to download from that source only.
Things fell into place once I changed the package source to download from: https://www.nuget.org/api/v2/ EXPLICTLY in the settings
In my case, an aborted Nuget restore-attempt had corrupted one of the packages.configfiles in the solution. I did not discover this before checking my git working tree. After reverting the changes in the file, Nuget restore was working again.
There is a shortcut to make Nuget restore work.
Make sure internet connection or Nuget urls are proper in VS Tools options menu
Look at .nuget or nuget folder in the solution, else - copy from any to get nuget.exe
DELETE packages folders, if exists
Open the Package manager console execute this command
paste full path of nuget.exe RESTORE full path of .sln file!
use Install-pacakge command, if build did not get through for any missing references.
The same problem I encountered but what solved my problem was to go to Nuget Package Manager (rightclick to the prj > select Manage Nugget Packages) and uninstall and install again the packages that are having issues.
BUT there are some packages having dependencies to other packages, so what I did was to uninstall the dependencies first and then followed by the nuget package that I wanted to uninstall and re-install.
You can find out if the nuget has dependencies when you tried to uninstall it and then visit the Output window, there will be a line saying that the nuget failed to uninstall because of its dependencies, and those dependencies are also listed there.
I know this is an old thread but it was the first search result today (in 2022) for "nuget package restore canceled". This is the message I got in VS when trying to rebuild a solution at my new job.
I've been in the new job for a few weeks and the build worked up to now.
The package source used by my solution is xxxxPackages, where xxxx is the name of my employer. So the package source is not nuget.org, which I normally use.
Occasionally, a message was appearing in VS saying:
"TF30063: You are not authorized to access xxxxdev.visualstudio.com."
Despite this, I had xxxxdev.visualstudio.com open in my browser and was able to work in it.
I tried many of the suggestions here. Then, chatting to a colleague, it turned out that my VS login had gone stale. In Visual Studio, I clicked on my icon in the top right and selected 'account settings'. There was an exclamation mark indicating that I had to refresh the login to my work account on visualstudio.com, using my xxxx email address.
Once I had done this the problem went away.
I hope this saves others the hassle I had this morning.