PowerShell Core 6.1.1 in VSCode
- Sat, Jan 26 2019 at 12:00 pm #979298
Thanks to Mr Pietroforte’s article on running VSCode with multiple shells, I was able to configure Powershell Core 6.1.1 into my VSCode (Win7) environment (insert a one-line into the Users settings .json file). To confirm that I now have both Powershell Core 6.1.1 and Powershell 5.1 (used in ISE), I attach a portion of my newly configured VScode:
Furthermore, I changed the shell to [1: pwsh] and typed ‘$PSVersiontable’, changed it again to [2: PS Integ. Con] and Typed ‘$PSVersiontable’ again, to confirm that I am running the corresponding PS.
However, when I started to open my scripts and run them with [1: pwsh], they always “force” the shell to be [2: PS Integ. Con]. I can’t seem to “make it” use [1: pwsh] even though it is already configured.
I must be missing some principle of operation within VSCode or something else.
Would be grateful for any advice or tips for using [pwsh] properly under VSCode.
Thanks in advance!
- Sun, Jan 27 2019 at 6:21 am #979459
Unfortunately, that’s by design and how it currently works.
It has nothing to do with the version of PowerShell.
There’s no workaround for the moment and I am not aware of any ongoing improvement on this side.
This is one of the major reasons why I currently stick to ISE for SysAdmin work.
There is currently a huge debate here on Github about having real tabs like in ISE.
The VS Code extension that comes closest to this feature is feature is named Terminal Tabs.
But it’s only a gadget and doesn’t make the job at all.
- Sun, Jan 27 2019 at 8:47 am #979466
Thanks very much Mr Fullenwarth for your reply. I must’ve misunderstood the article by Mr Pietroforte on using “multiple shells”, even though Powershell Core 6.1.1 was successfully configured.
If my intention now is to just use [1:pwsh] and no other — i.e., run VSCode with just Powershell Core 6.1.1, can I “remove” the configuration setting of [2: Powershell Integrated Console] (which I understand is the Windows Powershell 5.1)? Would this work?
If so, how can I “remove” [2: Powershell Integrated Console]?
Thanking you for your attention and kind consideration.
- Sun, Jan 27 2019 at 11:46 am #979470
- Sun, Jan 27 2019 at 11:57 am #979474
- Sun, Feb 3 2019 at 12:57 pm #989400
Hello Mr Fullenwarth,
I implemented the change as specified: CTR+SHiFT-P >> User settings >> Terminal integrated shell windows >>
C:\Program Files\Powershell\6\pwsh.exe. In fact, it was already there.
However when I type something in VS Code and do a Run Debug or Run no Debug it continues to insist on using Powershell 5.1. I am attaching a screenshot of the [User settings] >> [Terminal integrated shell windows] step.
Would be grateful for any advice / tips or suggestions.
- Mon, Feb 4 2019 at 8:34 am #991840
- Mon, Feb 4 2019 at 5:34 pm #991892
Your last recommendation works! My sincerest thanks. The area where it shows a drop down arrow remains the same, with 2 entries:
[1: pwsh] and [2: Powershell Integrated Console]. However, when I run my scripts it always goes to [pwsh.exe] regardless of what this field says.
I am however discovering that Powershell Core 6.1 (i.e., pwsh.exe) is missing a few things. For example, I am getting an error message on an old script which runs perfectly well under Powershell ISE (i.e., Powershell 5.1).
This script requires using OLE:
$connStr = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=$AccessFile;Persist Security Info=False" $conn = New-Object Data.OleDb.OleDbConnection($connStr) $conn.open()
In case you happen to know the syntax for loading the assembly that the statement
requires, I’d appreciate some assistance. In any case, I am highly grateful for your patience and kind assistance.
- Tue, Feb 5 2019 at 12:56 pm #994387
This is a .Net Framework 4.0 class from the System.Data assembly.
Try the following to load the assembly:
Add-Type -AssemblyName 'System.Data'
Add-Type -Path 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\System.Data\v4.0_188.8.131.52__b77a5c561934e089\System.Data.dll'
However, it is very likely that the assembly is not compatible with PowerShell 6…
- Tue, Feb 5 2019 at 11:26 pm #994578
- Mon, Feb 4 2019 at 11:19 pm #992016
Following the successful configuration of pwsh.exe (Powershell Core 6.1) into VSCode using your suggestion, I was about to do the same on another newer PC. I then accidentally came across some documentation on installing VS Code / Powershell, and note that VS Code has a click to switch from one shell to another. It is a tiny button highlighted in green on the lower right corner:
Clicking it pops a menu at the top:
which allows one to select which shell to switch to. I have only spent a few minutes since discovering it, and tried it a number of times, and it seems to do what it purports to do: switch from one shell to another.
I thought I’d mention this for what it’s worth, since it has taken me a quite a while to reach this level of understanding how VS Code can be configured with the various Powershell versions out there. My sincerest thanks again to you for your kind assistance and consideration.
- Tue, Feb 5 2019 at 1:05 pm #994391
- Tue, Feb 5 2019 at 11:24 pm #994574
Yes, my intention is to use only one: Powershell Core (6.1), as it is supposedly the “future” of Powershell.
Still I do not understand how or why Microsoft says that “there is no future” in Windows Powershell ISE (5.1), and to start switching to the “future” platforms: VS Code & Powershell Core, but the “future” seems to have less functionality than the old platform.
Many thanks again for your generous assistance.
- Wed, Feb 6 2019 at 7:21 am #996774
This way they have more people trying PowerShell 6 and reporting errors, which in turn will help them to improve the product.
By experiment they know that most of people stick to the old version if the old and new versions coexist together.
Think about Windows XP, Windows 7, Windows Server 2003, Windows Server 2008, IPv6…
- Wed, Feb 6 2019 at 6:14 pm #996810
Cross platform support comes at a very high price. Features have to be removed and reliability suffers significantly. It remains to be seen if Microsoft has the engineers who can make this work in the long run. If you work in a Windows only environment and have to ensure that everything works smoothly, I would stick with Windows PowerShell for a while.
- Sun, Jan 27 2019 at 6:10 pm #979504
Ramon, how do you start your scripts?
- Sun, Jan 27 2019 at 8:43 pm #979511
Hello Mr Pietroforte,
I first launch VSCode (I always Run as Adminstrator).
Once inside, I do a File >> Open File, and then pick one of several *.ps1 files that I’ve written from the days of using Windows Powershell ISE (5.1).
Then depending on whether I am testing or running something already working, I would press F5 (Start Debugging) or CTRL+F5 (Start w/o Debugging), or Run Selection (F8) if only testing a portion of the script/program.
I note that I am still on a Windows 7 laptop, although I just got a new laptop with Win10, but I still haven’t touched the new laptop yet.
Thanking you for your attention and kind consideration.
- Sun, Jan 27 2019 at 9:12 pm #979629
“Run Selection” is a feature of the PowerShell extension. This is the reason why your code runs in the Integrated Console. To run code in the pwsh console, you can launch your script from the console.
The PowerSell extension hijacks the Debug feature of VSCode and it seems there is no setting to turn this off. The only thing you can do is disable the PowerShell extension. This will remove the Integrated Console.
Another way of running code in VSCode is the Code Runner extension.
Of course you can also replace the PowerShell version as Luc suggested.
- Sun, Jan 27 2019 at 9:47 pm #979638
Hello Mr Pietroforte,
Thank you very much for a clear explanation. Since I am preparing to run VS Code with Powershell Core 6.1, I will disable the Powershell extension as suggested by Mr Fullenwarth. This is so I will be ready for the Powershell Summit OnRamp (a 3-day beginner’s course) on April 28-May 2, 2019.
My sincerest gratitude to you and Mr Fullenwarth for your generous attention and technical assistance.
- You must be logged in to reply to this topic.