I am facing a situation where nuget.exe is not being recognized by Powershell in Windows Server 2012. I am pretty sure that the environment variable has been correctly set. Yet I am getting the following error:
nuget : The term 'nuget' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the
path is correct and try again.
At line:1 char:1
+ nuget
+ ~~~~~
+ CategoryInfo : ObjectNotFound: (nuget:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
I am getting the same error even if I go to the directory where nuget.exe is present and execute nuget.
Windows CMD is showing nuget is not a recognized command, but it's working fine if I execute nuget inside a directory where nuget.exe is present.
Am I making a mistake in setting up environment variable for nuget? Please help :)
Note: I am new to dotnet tech ecosystem.
Like a lot of Unix systems, Powershell doesn't include current directory in the path. One needs to either use full path or explicitly include current directory.
Try .\nuget.exe in Nuget's directory.
As explained in the documentation,
As a security feature, PowerShell does not run executable (native)
commands, including PowerShell scripts, unless the command is located
in a path that is listed in the Path environment variable $env:path or
unless you specify the path to the script file.
Your path variable should be a Semi-colon separated list of paths containing your directories: On one of my Server 2012 boxes it looks like this:
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\ProgramData\chocolatey\bin;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\TShell\TShell\;C:\Program Files\dotnet\;C:\Program Files\nodejs\;C:\Program Files (x86)\dotnet\
which is a bit long and awkward. You should append your path to NuGet to this string and save it.
From Windows Explorer, right click on This PC => Properties. Locate Advanced system settings on the the left hand Panel. Choose the Advanced tab. Click on the Environment Variables button on the bottom right. Scroll the window down until you find the Path variable.
I usually copy and paste it to/from a text editor for ease of use.
Related
How is this possible?
I installed .net sdk 6.0.405: dotnet-sdk-6.0.405-win-x64.exe
I can in windows terminal and power shell run: dotnet --version: 6.0.405 ✅
I CAN ALSO IN VSCODE IN ITS BUILTIN TERMINAL, run: dotnet --version: 6.0.405 ✅✅
But in the OUTPUT tab, choosing OmniSharp Log from the dropdown, it says:
[ERROR] A .NET 6 SDK for x86_64 was not found. Please install the latest x86_64 SDK from ...
I switched vscode explorer settings to use external terminal.
And this terminal setting to command prompt:
Terminal › Integrated › Default Profile: Windows
The default profile used on Windows. This setting will currently be ignored if either terminal.integrated.shell.windows or terminal.integrated.shellArgs.windows are set.
I have dotnet in the PATH (and it works in terminals and in vscode's terminal)
I restarted vscode, AND REINSTALLED the dotnettools "C# for Visual Studio Code (powered by OmniSharp)" extension. I went to the online store and from the right column under Resources I downloaded the ms-dotnettools.csharp-1.25.2#win32-x64.vsix to make sure I get the right one. And restarted vscode.
I tried this setting:
Omnisharp: Dotnet Path
Specified the path to a dotnet installation to use when "useModernNet" is set to true, instead of the default system one. This only influences the dotnet installation to use for hosting Omnisharp itself. Example: "/home/username/mycustomdotnetdirectory".
C:/Program Files/dotnet/sdk/6.0.405
And this setting:
Omnisharp: Sdk Path
Specifies the path to a .NET SDK installation to use for project loading instead of the highest version installed. Applies when "useModernNet" is set to true. Example: /home/username/dotnet/sdks/6.0.300.
C:/Program Files/dotnet/sdk/6.0.405
And restarted vscode. And now it says:
[ERROR] Error: Command failed: dotnet.exe --version
'dotnet.exe' is not recognized as an internal or external command,
operable program or batch file.
What? W H A T? lol
What could be wrong? Why isn't it saying where it expected to find it and what to do to locate it? Is there a setting to specify the dotnet.exe path to this C# extension? Does it need always-on internet or something? Does it have DRM? Does it need Edge installed? Wtf?🙂
🙃😭 I just need intellisense; and I've wasted 2h, on only microsoft-owned products.
#Microsoft 0/5 stars
Still don't know why it happens, but here's how to solve it:
The problem was from this: I like to keep all my visual studio code extensions as .vsix files locally in folders so I can remember and get them easily & offline. Sensible enough choice, and I had the correct ms-dotnettools.csharp-1.25.2#win32-x64.vsix for my platform.
But in VSCode, when I install this particular extension via VSIX, even though it succeeds, it can't find .net. If you instead install the extension "normally", ie via vscode's own download, it seems vscode does some extra configuration steps while installing, and probably sets the .net paths correctly or something. Because now it works.
So TL;DR: don't install ms-dotnettools.csharp via vsix, it seems bugged. 😶
Would love to see an answer explaining what's wrong / how to actually do via vsix; but I don't have any more time to debug this rn.
I have a new Win 2012 64bit server on which I've installed Win 10 SDK and also copied from my development machine v8.0A and v8.1 to the dir:
C:\Program Files (x86)\Microsoft SDKs\Windows
I'm trying to use Jenkins/MSBuild to build a x64 .Net 4.0 project but I get the error:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(2428,5): error MSB3086: Task could not find "LC.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
I've tried several approaches such as :
Running MSBuild fails to read SDKToolsPath
LC.exe file not found during build for .NET 4
Without success:
I can't find WindowsSdkVer.exe anywhere.
I've added the Env Variable SdkToolsPath but it's not respected.
With powershell, run
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86"
And you should get something that looks like
ProductVersion REG_SZ 4.6.00081
ComponentName REG_SZ Microsoft .NET Framework 4.6 SDK
InstallationFolder REG_SZ C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\
But the fact that you get SdkToolsPath "" back probably means that registry doesn't exist, or InstallationFolder is an empty string as well.
I just figured this out myself, so I don't know the extents of potential failures, but I ran the reg query locally and got the value C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\ for InstallationFolder (I don't know what the path would look like for v8.0A). I then copied the folder bin\NETFX onto my server, and then added a the registry to point to that location.
Something like:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86" /d "C:\bin\NETFX 4.6 Tools\\" /t REG_SZ /v InstallationFolder
Check WOW6432Node
I added the registry to point to my local copy, but no matter what I couldn't get msbuild to use my supplied path. I saw that some people were querying against WOW6432, and so I I queried "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86"locally and saw that it existed and was populated. I then added the registry on the server, and everything just works after that.
I have setup my TeamCity to build using MsBuild a project that NuGet packages.
During the build, the following command to install packages is issued, but fails:
..\nuget.exe install "C:\TeamCity\buildAgent\work\811b6866c8757c46\Service\packages.config" -source "https://nuget.org/api/v2/" -RequireConsent -solutionDir "..\ "
Error:
Unable to connect to the remote server
with exit code 1.
Interesting to note is that when I run this exact same command on the cmd prompt (inside the same path), it succeeds without any errors.
This is what I have done so far:
Add a new Build Parameter under environment variables in TeamCity: env.EnableNuGetPackageRestore and set it to 'true'
Add a specific path to the package sources (https://nuget.org/api/v2/) inside the ..nuget\nuget.targets file (as described here)
To provide the additinal paths ways to supply a path:
Modified the nuget.config file inside the .nuget folder (..nuget\nuget.config)
Modified the nuget.config for the SYSTEM account that the build runner is executing under (C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\nuget.Config) (as described here)
What I was thinking is that this has something to do with a roaming profile of the System user (that the build agents runs with) because it all works when build agent runs with my account. But the nuget.config is the same for both profiles, and I'm out of ideas. Maybe the System user doesn't have access to the Internet on WinServer2012R2? Maybe it needs additional permissions? Which ones?
Do you have any ideas of what to try?
The error turned out to be the setting for the ISA server we have on our network (the TMG client). By default this isn't set up for new (local) users and therefore the SYSTEM account didn't have access to the web.
I've set this up for a new local user (non-domain, with password that doesn't expire), added it to Administrators group and now it works just fine.
Hey there I could really use a guru on msbuild.
Ultimate goal: Build web deployment packages with TeamCity
I'm trying to call the Package target in TeamCity on my build server and it fails as path: Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.5 doesn't exist. 10.5 doesn't exist on my dev laptop either, I am using VS 2012, yet I can call MSbuild package target on the command line of my laptop with no problem.
I could make a copy of Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0 that does exist on the build server and rename it 10.5, but this just feels wrong.
Any pointers gratefully received.
EDIIT
For now I have just:
created the path: "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.5"
Copied contents of V10.0 into it.
Copied "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\web\Microsoft.WebSite.Publishing.targets" into it.
It's a case of getting the VisualStudioVersion right, override it on the command line and all is good.
C:\>msbuild web_site.publishproj /T:Package /P:Configuration=Release;PackageLocation=C:\packages;VisualStudioVersion=11.0
I have a .net application built on .net framework 3.5, I am trying to build this application on Jenkins CI server. I've added MSBuild plugin and and have added path to the .exe file of 2.0, 3.5 and 4.0 versions of MSBuild. But my building processes are failing by showing the below error message.
Path To MSBuild.exe: msbuild.exe
Executing command: cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
[Test project] $ cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
'msbuild.exe' is not recognized as an internal or external command,
operable program or batch file.
Build step 'Build a Visual Studio project or solution using MSBuild.' marked uild as failure
Finished: FAILURE
Could anyone plz help me out..??
To make the MSBuild plugin work, you need to configure the plugin in the Jenkins management screen.
NOTE: in the newer Jenkins versions you find the MSBuild configuration in the Global Tool Configuration:
Note the "Name" field, where I've called this particular configuration v4.0.30319. You could call it anything you like, but ideally the name will somehow refer to the version.
You'll need to refer to this name later in the Jenkins PROJECT that's failing.
Note: The yellow warning implies that the Path to MSBuild field should be populated with a directory name rather than a file name. In practice you do need to enter the filename here too (ie. msbuild.exe) or the build step will fail.
In the Jenkins project that's failing, go to the MSBuild build step.
The first field in the build step is "MSBuild Version". If you created the build step before configuring any MSBuild versions, the value here will be (default).
After configuring one or more MSBuild versions, the drop down will be populated with the available configurations. Select the one you require.
You can see here that I've now selected the named configuration that matches the installation above.
Jenkins | Manage Jenkins | Configure System
scroll down to the MSBuild section and click MSBuild installations
define the full path to msbuild.exe, on my system I have 3.5 and v4.0.30319
Note - specify the path to 32-bit tools even on a 64-bit system, otherwise you might get an error message:
Building Windows Phone application using MSBuild 64 bit is not supported.
So in Jenkins - it could be for example:
Name: Version 3.5
Path: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Name: Version 4.0
Path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSbuild.exe
I think you should set an absolute path for "msbuild.exe" in your Jenkins configuration,
for example:
C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
You can also add the path where the msbuild.exe is, to the PATH system environment variable of the node (or nodes) that is running that specific job.
You could try executing the
%comspec% /k ""c:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
command, which will temporarily update your environment path variables to reflect the VS2010 build environment. Execute this before you call MSBUILD and see what happens. I use this in my own build scripts with no issues.
Side note; it's very likely counterproductive to have multiple versions of MSBUILD on your PATH. Concentrate on getting one version working and go from there.