This question already has answers here:
How can I use PowerShell with the Visual Studio Command Prompt?
(15 answers)
Closed 1 year ago.
I have Visual Studio 9.0 installed but I want to use it manually from PowerShell. It comes with two setup scripts: vcvars32.bat for the 32-bit compiler and vcvars64.bat for the 64-bit compiler. When I open cmd.exe and run one of the scripts, it sets up everything just fine and I can run cl.exe without any problems. When I run one of those setup scripts from PowerShell, though, it doesn't work. The scripts run through fine but trying to run cl.exe afterwards yields a "cl.exe could not be found" error! And looking at the contents of the PATH environment variable after running one of the setup scripts I can see that PATH hasn't actually been modified at all.
So it seems as if the batch files ran from PowerShell maintain their own environment variables state which goes away as soon as the batch file terminates. So is there a way to run batch files from PowerShell and have those batch files affect the actual environment variables of the current PowerShell session? Because that is what I need. All that is done by vcvars32.bit and vcvars64.bit is setting up environment variables after all but it only seems to work from cmd.exe, not from PowerShell.
You should use InvokeEnvironment script to do that. Check its man page:
Invoke-Environment <path_to_>vsvars32.bat
You can furhter generalize this by determining OS bits and crafting the vsvars<OsBits>.bat.
Example:
PS C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools> $env:INCLUDE -eq $null
PS C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools> $true
PS C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools> Invoke-Environment .\vsvars32.bat
PS C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools> $env:INCLUDE
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\ucrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\winrt;
I don't have Visual Studio at hand, but the batch scripts most likely just set variables for the current session. Running them from PowerShell won't do you any good, because they'll be launched in a child CMD process and change the process environment of that process, but not of the parent (PowerShell) process.
I suspect you need to translate the variable definitions to PowerShell, e.g.
set PATH=%PATH%;C:\some\where
set FOO=bar
becomes
$env:Path += ';C:\some\where'
$env:FOO = 'bar'
Write the translated definitions to a .ps1 file and dot-source that file in your PowerShell session:
. C:\path\to\vcvars.ps1
Related
We have configured a windows virtual machine and deployed an agent there to build our code and run scripts.
In our VM we two different flavors of PowerShell command prompt:
Windows PowerShell
Developer PowerShell for VS 2019.
How can we start "Developer PowerShell for VS 2019" from our pipeline YAML script and execute our checked out .ps1 file there?
There are several flavors of PowerShell tasks that can be initiated from the pipeline though and not sure which one of them will serve the purpose. They are the following:
Azure PowerShell
PowerShell
PowerShell on Target Machine
Service Fabric PowerShell.
Which of the above represent "Developer PowerShell for VS 2019"?
The reason behind this specific flavor of PowerShell is:
Need to have some of the .NET Framework Tools (CorFlags.exe) which are only accessible in the "Developer PowerShell for VS 2019" and not in the other one.
The Developer PowerShell for VS 2019 is a regular PowerShell with a module imported, you can see exactly what in this way:
Go the Start menu and search for Developer PowerShell for VS 2019.
Right-click on it and Open file location - you will get this:
Now right-click again on the Developer PowerShell for VS 2019 shortcut and Properties.
You will see in the location that is run the regular PowerShell with some command:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -noe -c "&{Import-Module """C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"""; Enter-VsDevShell bc97b47b}"
Now, if you open a PowerShell and run the script there:
&{Import-Module "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"; Enter-VsDevShell bc97b47b}
You will get the Developer PowerShell for VS 2019 and CoreFlags.exe will work:
So, you need to use the regular PowerShell task (your option 2) and run the above command at the begging of the script.
Note: you should copy exactly the command you see in the Properties, in each machine it could be different.
Not sure how to do this... I work mostly on OSX and linux systems, so when I install an app or use for example G++ or xcodebuild, I just call it from terminal.
On Windows, I did install msbuild with VS2015, but if I am in powershell or regular command prompt, typing msbuild result in an error. I have to specify the whole path to make it work.
What is the equivalent in Windows world, of setting console so when I type msbuild, it gets the correct path?
You can set your path like so in:
PowerShell
$Env:Path = "<Path_to_msbuild>;${Env:Path}"
Batch/Cmd
set "PATH=<Path_to_msbuild>;%PATH%"
Note: The <path_to_msbuild> is the folder where msbuild.exe exists, and NOT the direct path to the executable itself
How it works
This will add the msbuild binary to your path, so you can invoke it from anywhere!
To verify which location msbuild is running from you can simply run (in both languages!):
where.exe msbuild
If you create just a link to msbuild you still won't be able to call for example the compiler from the command line. Which is why VS provides a convenient (pretty much canonical) way to do this by supplying a batch file which sets up the PATH and all the other build-related environment variables.
Example if you are on cmd.exe:
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat"
> msbuild
Microsoft (R) Build Engine version 14.0.25420.1
...
> cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24213.1 for x86
...
You can invoke this from the Start menu as well: hit start, type pro vs to look for matches, select Developer Command Prompt for VS2015.
For PowerShell (which I'd recommend spending time on instead of cmd) you'll need an extra function like presented here: https://stackoverflow.com/a/21652729/128384
I am trying to rum my test cases through Visual Studio test in PowerShell but it's giving me an error. It's working fine with CMD - why?
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" C:\DLL\Automation_2.dll /Tests:AccessToWire
You have to prefix your invoke with an ampersand. Also use quotes for your parameters:
& "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" "C:\DLL\Automation_2.dll" "/Tests:AccessToWire"
I was trying to use my favorite source control from the Package Manager console in Visual Studio 2010. I had issues described in another topic. For now the best answer is to move all command-line stuff from Visual Studio to bare PowerShell.
But this case the Visual Studio related commandlets are not working. For example, most crucial one — I cannot run Update-Database command from Entity Framework.
Is it possible to register somehow Visual Studio specific commandlets for the current project in PowerShell? Or make PowerShell automatically take current project context from the packages subfolder?
The NuGet PowerShell commands rely on being run from within Visual Studio so will not work outside in the normal PowerShell running from the command line.
You can however use migrate.exe which ships with the EntityFramework NuGet package and use that from the command line to update your database.
As a prototype I put together a way to use NuGet PowerShell commands from the normal PowerShell command line using SharpDevelop. Unfortunately at the moment the EntityFramework NuGet package does not work with SharpDevelop.
Another interesting project is StudioShell which provides a new DTE: drive inside Visual Studio but can also be used outside from the command line. I do not believe it supports NuGet PowerShell commands being run from the normal PowerShell command line.
I can find the NuGet.psd1 file at:
C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\IDE\Extensions\5ttpefif.3mk\Modules\NuGet\NuGet.psd1.
However, when you try to load it:
PS> Import-Module $pathToNuGetPsd1 -Force -NoClobber -Scope Global
Import-Module : The name of the current Windows PowerShell host is: 'ConsoleHost'.
The module 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\
Extensions\5ttpefif.3mk\Modules\NuGet\NuGet.psd1' requires the following Windows
PowerShell host: 'Package Manager Host'.
I think we're out of luck. It has to be run from the Package Manager Host and requires things from Visual Studio as stated by Matt.
To solve my problem I used Chocolatey to install NuGet.CommandLine and then used NuGet.bat to do what I needed. It is a little more work and may not work in all cases depending on what you're trying to do.
Chocolatey: https://github.com/chocolatey/chocolatey/wiki/Installation
NuGet.CommandLine:
PS> cinst NuGet.CommandLine
I'm not terribly familiar with the Visual Studio cmdlets, but you can import a module into your PowerShell session by using Import-Module -Name <ModuleName>. You can list the available (aka. "installed") PowerShell modules by using `Get-Module -ListAvailable'.
My guess would be that the Visual Studio cmdlets are contained with its own PowerShell module, but it's quite possible that it's not "installed" to one of the standard locations in $env:PSModulePath. If this is the case, then you might need to locate the module directory and import either the .psd1 or .psm1 file directly, and pass that into: Import-Module -Name <FullPathToModuleFile>.
As an example of the above, take notice of where the Windows Azure PowerShell module is located: http://trevorsullivan.net/2012/06/07/introducing-microsofts-official-windows-azure-powershell-module/
It's under the Program Files directory, and is not immediately available to PowerShell, unless you import the module from its fully qualified path (the .psd1 module manifest file).
Hope this helps.
I have setup a build definition in Visual Studio Team Services (was Visual Studio Online) builds.
Below is a snapshot of Powershell script setup:
I haven't set anything in 'Working folder' as I am assuming that it defaults to the folder where the script lives as specified in the info.
When build runs, it throws an exception at the Powershell step.
Below is the error snapshot:
Somehow the working folder is not the folder where the script is located.
Any suggestions to fix it?
Use the powershell variable $PSScriptRoot to get the directory where your script is, and use that to figure out all other paths.