The Nuget Distribution pages states:
NuGet 4.x is included in the Visual Studio 2017 installation. Latest
NuGet releases are delivered as part of Visual Studio updates.
Batteries are included!
It seems those batteries are flat. In both Package Manager Console and extenal PS windows, when I type nuget, I get the error:
The term 'nuget' is not recognized as the name of a cmdlet, function,
script file, or operable program.
What do I have to do to fix this? If it's installed with VS 2017, surely that install should add it to the PATH variable?
I don't want to use the VS Command Console, even if it is still with 2017, as I have retired all my usage of that relic to PowerShell consoles.
All I had to do was add the location of nuget.exe to the PATH environment variable for my user and all users, The latter is up to you, but I always run VS as Administrator.
Sages of yore used to always advise against doing this, but MS in all their divine wisdom has made life as a web developer using VS so difficult under a non-admin account, I see nary a mention of said advice, even since around VD 2010 even.
You'd think that with Nuget being installed as part of Visual Studio, the least they could do is add amend that bloody variable as part of the VS installation.
Related
I am using a custom build version of the Visual Studio Code. It seems some extensions are checking the exact build name and version of the vscode before installation and if it doesn't match, vscode throws an error:
Unable to install because, the extension '....' compatible with
current version '...' of VS Code is not found.
For example, the Remote - SSH extension on my current custom build throws:
Unable to install because, the extension 'ms-vscode-remote.remote-ssh'
compatible with current version '1.32.0' of VS Code is not found.
Is there a way to bypass the version checking and force vs-code to allow the installation?
Issues
There are two issues to concern:
The first one is a legal one. The Remote - SSH extension's license is very restrictive. From its license:
You may use a copy of the software with each validly licensed copy of Microsoft Visual Studio Code. You may not use the software if you do not have a license for Microsoft Visual Studio Code.
The second one is the extension's incompatibility. It seems that your custom build is based on VS Code version 1.32.0. However, the initial release of the SSH extension requires at least VS Code 1.35.0 or above. From the release notes of VS Code 1.35.0:
The Remote Development extensions are now available for VS Code Stable [...]
Conclusion
So even if you do not care about the legal issues and are able to force install the extension for your custom build it will probably not work since the extension requires a more recent release of VS Code.
More information on this topic can be found in the VSCodium documentation (A "free version" of VSCode). If you rely on the SSH extension and consider switching your custom build, there you will find a possible workaround to get the remote extensions working with VSCodium (I haven't tested it on my own).
I have a project using the SpeechClient.dll from NuGet. The program runs fine on the development machine. So I have a Windows Setup Project that creates the installer. I run the installer and all the files show up including the SpeechClient.dll, but as soon as the program makes the first call to the Speechclient.dll, I get a
file not found
exception. This is the output from the event viewer.
Does anyone have any troubleshooting ideas? Thanks.
Seems now that I have installed visual studio on the machine that it is working. I wonder what visual studio installs? I was also trying to use Fusion Log Viewer to see what the problem was.
I had this problem as well. Installing the Visual Studio C++ Redistributable 2017 x64 cleared it up.
Is there a way to make the VS Package Manager commands available on Powershell Console? I looked over this link but I was unable to understand the NuGet philosophy.
I know that I can access it in Visual Studio but, let me explain my approach and goal.
I want to learn F# and for this use a lot its REPL. So basicaly, I open a Powershell console, change to my working folder, create a file with some code, fire the REPL, try various things.
In this kind of loop makes sense to have means to install various packages without starting VS and having to create a VS project.
Thanks!
Please refer to below screenshots:
The problem is that the PowerShell cmdlets that NuGet makes available inside Visual Studio rely heavily on Visual Studio so they are not supported outside of Visual Studio from the command line.
From the command line you have NuGet.exe which supports the following which are project related:
Downloading NuGet packages. Basically restoring the missing NuGet packages as defined in a packages.config file. NuGet.exe install or NuGet.exe restore
Updating a NuGet package in a project. This will update the reference information but not run PowerShell scripts. NuGet update
Having the NuGet PowerShell cmdlets available on the command line is something I have looked at doing using the cmdlets that SharpDevelop provides. It is possible to fully support NuGet install/update/uninstall and have the PowerShell scripts execute on the project but in this case it requires an entire IDE, in this case SharpDevelop, to be available, at least its assemblies, even though the IDE is not run. This is needed to support updating the project file using the Visual Studio project model (EnvDTE) from within any PowerShell scripts that run.
Nuget commands cannot be used outside of Visual Studio. However, if you were change to use Paket instead of Nuget, then you can use Paket from a command line outside of Visual Studio to manage your project's packages.
The getting started page is here.
OS: Windows 7 Ultimate SP1 x64.
At some point I figured I can no longer update my IDE for Powershell - PowerGUI Script Editor (latest is v3.7.0.92 at the moment of writing). I am getting this error when inside the script editor -> check for updates, as well as in a standalone installation, in both cases the installation is rolled back.
In my Programs and Features I have the following relevant entries:
(A) Quest PowerGUI 3.6 --- Version 3.6.0.21
(B) Quest PowerGUI 3.6 --- Version 3.6.0.8
When I attempt to uninstall (A), I am getting this error:
Although the current version inside the script editor is shown as 3.6.0.21.
And when trying to uninstall (B), I get a standard Modify/Repair/Remove dialog, but when I do Remove, it ends up with the first error again (#1722 above). Doing Repair works, but does not solve the problem, i.e. still unable to Update.
Is there any way I can make it work again?
P.S. One may point out this to be part of superuser, yet I think it's an inherent part of Powershell development and so deserves a place on SO.
It seems the uninstall function either doesn't complete correctly or misses some important registry settings. I had the same problem, and this resolved it for me:
download and run the microsoft uninstall utility
in the utility do the following:
select the install or upgrade software or hardware category.
find and run the fix problems with programs that can't be installed or uninstalled.
give answers to the prompts regarding the powergui instance that will not uninstall.
exit the utility.
install the powergui version of your choice.
get pint from pub
If a file is modified in Visual Studio, the files are automatically checked out from Team Foundation Server. However, sometimes there are files not modified in VS, is there command to check out those modified files only?
If you download the Team Foundation Server power tools, you can use the "tfpt online" command line.
That said, I would try and avoid this way of working. TFS much prefers to know about files that you are checking out before you start editing them and your interaction with TFS will be much happier if you can do this.
The same power tools can optionally install Windows Explorer integration for TFS which will allow you to check the files out easily outside of Visual Studio.