nuget is not a recognized as an internal or external command - nuget

While running a batch file, I get the below error:
nuget is not a recognized as an internal or external command
It's not working from command prompt. Have a look at the below screenshot.

This happens when either you are not in the directory where the nuget.exe is located or your environment variables are not set for it.
Make sure you have downloaded NuGet.exe.
Navigate to it and right click, then click on properties.
Copy the location of it.
Navigate to Control Panel > System > Advanced System Settings > Environment Variables.
Windows 10
Double click the variable Path click add new, paste in the location of the nuget.exe.
Restart Command Prompt and the issue should be fixed.
Other operating Systems
Double click the variable Path, If there is no other locations simply paste it in. If there is add a semi colon to the end of it and the paste it in.
Restart Command Prompt and the issue should be fixed.

nuget is not a recognized as an internal or external command
That because NuGet is a external command, can not be recognized by Windows in an arbitrary directory, you should type the "NuGet" or "NuGet.exe" in the path where NuGet.exe exists and if you want type it in an arbitrary directory, you should download the NuGet.exe (Not VSIX) from NuGet.org and set the local path of NuGet.exe into your path environment variable.

Instead of using nuget.exe in your path, use .net version
dotnet nuget

Download the Nuget Exe, keep it in a folder you want to. For ex : D:\Software\Nuget
Open Cmd prompt with the same path.
To create this .nuspec file, execute the following command in a command prompt.
D:\Software\Nuget>Nuget.exe spec

For .NET Core / .NET 5:
Use the command dotnet pack
Instead of using a .nuspec file you set those properties in your .csproj file, for example:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<PackageId>MyCompany.Project</PackageId>
<Version>1.0.0.1</Version>
</PropertyGroup>
...
</Project>
With above config, running dotnet pack will create a file named
MyCompany.Project.1.0.0.1.nupkg
For more details and config options, see: https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#pack-target

I follow this link and it work fine with me
How to Fix “not recognized as an internal or external command” in Windows
just add the path of the nuget in the path variable

1 - Installing Package:
I followed this Microsoft documentation. Use the nuget.exe CLI in the package console
Note:- This configuration is specific to a project and this adds dependency to the projects package.config
2 - Installing exe:
You can also follow the below documentation, again from Microsoft to download and set the path to nuget.exe folder, as others in this thread has explained.
NuGet CLI reference

Related

vscode interactive notebooks nuget directory error

I was trying to include a nuget package in my C# cell, like the example below:
#r "nuget: PackageIWantToInclude"
when suddenly, I got a similar error like this:
Error: PackageManagement Error 3217 The source directory 'D:\MyLocalDirectory' not found
note that I have not made any edits on the settings pointing to any directory with the address 'D:\MyLocalDirectory'. I've also looked for a solution elsewhere without any success. Can anyone give me a hint on how to bring the source directory back into its default?
Turns out, vscode interactive notebook uses the nuget configuration included in Nuget.Config found in "C:\Users{computer name}\AppData\Roaming\NuGet".
In that current machine where the error occurs, I have some local package sources included that were already non-existent, though they were already disabled, as indicated when viewed using this command dotnet nuget list source.
What I did was to remove the non-existent package source from the Nuget.Config file--in this example that would be:
<add key="NonExistentSource" value="D:\MyLocalDirectory" />
and then I restarted the notebook kernel by:
opening Command Palette (CTRL+SHFT+P) or under View>>Command Palette..
and then selecting the restart notebook's kernel

How do I correct the output directory of a CI/CD NuGet package build using Visual Studio Team Services?

I've just started trying to configure a CI/CD process using Visual Studio Team Services, with a view to having a gated check-in process which then automatically packs and pushes the output to a private NuGet Feed. I'm successfully getting through the "Get Sources" task which exists natively in the build definition, however my package task is failing at this stage:
d:\a\_tool\NuGet\4.0.0\x64\nuget.exe pack
d:\a\1\s\Core\Core\Core.csproj -NonInteractive -
OutputDirectory d:\a\1\a -Properties Configuration=$Release;OutDir=$(OutDir)
-Symbols -version 1.0.0-CI-20170811-095629 -Verbosity Detailed
NuGet Version: 4.0.0.2283
Attempting to build package from 'Core.csproj'.
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
NuGet.CommandLine.CommandLineException: Unable to find 'd:\a\1\s\Core\Core\$(OutDir)\Core.dll'. Make sure the project has been built.
Essentially, the 2nd line of the log demonstrates that my project file is in d:\a\1\s, however the output is directed to d\a\1\a - not the same place. The instruction to NuGet to package my file then looks in the correct location (d:\a\1\s), but the file isn't here.
I understand that I can specify a Package Folder within the build definition, however I've not changed this from the default ($(Build.ArtifactStagingDirectory)) - I expect this to work natively, but for reasons I can't explain, it's not.
Is there a token or wildcard I can provide in an additional build property that will rectify this? I've taken the guidance of the first posted answer in here and changed $(Build.ArtifactStagingDirectory) to $(Build.Repository.LocalPath), which gets me much closer to the goal as the error now reads -OutputDirectory d:\a\1\s\... - I've tried manually putting a variety of sensible paths no the end of this, but the error persists.
Refer to this article. It has the build variables for the TFS/VSTS environment.
$(Build.ArtifactStagingDirectory) itself refers to the \1\a folder. You might want to try the $(Build.Repository.LocalPath) variable.
Not a 100% if it would work, but might as well try.
The issue is related to OutDir=$(OutDir) instead of OutputDirectory.
The OutputDirectory specifies the folder in which the created package is stored and the OutDir specifies the build output, but the project need to be built before NuGet pack task, so you need to add Visual Studio Build task or related to build project.
You can leave Additional build properties box blank to use default output per to configuration, because you just need to know the package stored path to push package to remote feed.
If you want to change build output, you can specify /p:OutDir msbuild argument to change build output location. For example:
Visual Studio Build task (MSBuild Arguments: /p:OutDir=$(Build.ArtifactStagingDirectory))
NuGet pack task (Additional build properties: OutDir=$(Build.ArtifactStagingDirectory))
BTW, to change package stored location, you need to specify OutputDirectory.

How to add path variable for File vault tool(VLT) AEM eclipse integration

Integrating FileVault with Eclipse usually requires setting up filevault path variable.I have described the steps below
Copy the FileVault archive file from the cq-quickstart/opt/filevault directory of your installation. Copy either filevalut.tgz or filevault.zip, depending on your operating system.NOTE: You can also download the latest version of FileVault from Package Share. Extract the archive. Add /vault-cli-/bin to your environment PATH so that the command files vlt or vlt.bat are accessed as appropriate.
Path variable setup:
1)vim ~/.bash_profile
2)PATH="/User/Documents/AEM/AEM_6.1/crx-quickstart/opt/helpers/vault-cli-
3.1.16/bin:${PATH}"
export PATH
3)source ~/.bash_profile
For example, /crx-quickstart/opt/helpers/vault-cli-2.4.8/bin. Open a command line shell and execute vlt –help. Make sure it displays the results.

Retrieve created NuGet package filename from 'nuget pack' command?

I'm writing a script that will automatically pack and publish Nuget files to my private repository (a fileshare) and a private symbol server (on localhost).
When I run nuget pack in Powershell I get a string output that contains the file location of both the nuget and symbol package, but as far as I can tell there's no way to programmatically get those paths without parsing the string. The package version is determined by the .csproj itself, so I don't necessarily know which version will be placed in the filename.
Here's the output from the pack command:
Attempting to build package from 'MyProject.csproj'.
Building project 'C:\Users\me\prg\MyProject.csproj' for target framework '.NETFramework,Version=v4.0'.
Packing files from 'C:\Users\me\prg\bin\Release'.
Using 'Myproject.nuspec' for metadata.
Successfully created package 'C:\nuget\MyProject.1.0.0.0.nupkg'.
Attempting to build symbols package for 'MyProject.csproj'.
Building project 'C:\Users\me\prg\MyProject.csproj' for target framework '.NETFramework,Version=v4.0'.
Packing files from 'C:\Users\me\prg\bin\Release'.
Using 'MyProject.nuspec' for metadata.
Successfully created package 'C:\nuget\Myproject.1.0.0.0.symbols.nupkg'.
Should I just bite the bullet and write some regex to parse out the "successfully created package" lines?
By default nuget pack will output the created packages to the current directory. You can override this by specifying the OutputDirectory option. It is not clear to me from where you run the nuget command (be it from within C:\Users\me\prg\, C:\nuget\, or somewhere else), so you might already know this, but it can offer you an alternative option:
You can create yourself a temporary directory (e.g. C:\nuget\temp\), which you can specify as your OutputDirectory option. If you then in your script make sure that this directory is empty before you run nuget pack, your can simply copy *.nupkg to your fileshare (and then afterwards move it to C:\nuget\, if that is required).
Parsing the output in powershell is not too hard.
$a = nuget pack .\Exceptional.csproj -Prop Configuration=Release | Select-String nupkg
$a -Replace "^[^']'", "" -Replace "'[^']$", ""
gives
C:\Users\phelan\workspace\Exceptional\Exceptional\Weingartner.Exceptional.1.2.6011.19372.nupkg
I made a slight change to the answer provided by #bradgonesurfing as his partly worked for me.
$pack = . $nugetPath pack rest of command........ | Select-String nupkg
$pack -match "'(?<nupkg>.*)'"
$packageFile = $Matches["nupkg"]
To get it in a post build event, I would use the powershell.exe to shell out to a powershell script. I have an example here that I used to automate running editbin that can be modified for nuget: https://gist.github.com/tcartwright/cc1bd4dc98349579630c43283c5f1fe9

How to make .nuget\NuGet.Config file attached to VS solution to be not ignored?

I've created new solution in Visual Studio, enable nuget package restore and got in soluition root .nuget folder which contains the following files needed to make package restore work: NuGet.exe, NuGet.config, NuGet.targets.
But I can't make nuget(as Nuget Visual Studio add-in and \.nuget\NuGet.exe as well) read setting from .\nuget\NuGet.config file - settings are still read from default %appdata%\NuGet\NuGet.config.
What have I tried.
I've tried to look where the path to NuGet.config is specified and haven't found anything like that, and nuget.exe install command that runs during build doesn't have any parameter saying like "take this nuget.config file".
Also I've removed \.nuget\NuGet.config and everything works - packages are restored during Visual Studio build and CI one.
Question.
I've got an impression that \.nuget\NuGet.config isn't used at all.
So essentially the question is: How to make .nuget\NuGet.Config file to be not ignored?
What am I doing wrong and how to do it write?
Thanks and have a nice %time_of_day% :)
Disclaimer
Everything that I've mentioned above is not a problem/issue - current nuget behavior is completely acceptable for me - I'm asking just because I'm curious and confused at the same time
I haven't tried this personally, but here is what the official Nuget 2.1 release notes say:
NuGet.config files are searched for in the following order:
.nuget\nuget.config
Recursive walk from project folder to root
Global nuget.config (%appdata%\NuGet\nuget.config)
The configurations are than applied in the reverse order, meaning that
based on the above ordering, the global nuget.config would be applied
first, followed by the discovered nuget.config files from root to
project folder, followed by .nuget
If this doesn't help I'd suggest you write more specifically what you're trying to achieve and which config settings you're changing - knowing more details about the problem may clarify the situation.
Did you point the config file that you want to use as ?
In nuget page example;
nuget config -set repositoryPath=c:\packages -configfile c:\my.config
nuget config -set repositoryPath=c:\packages -configfile .\myApp\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\Config\VisualStudio\14.0\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\NuGetDefaults.Config