Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't run in VS Code Locally #190

Open
michael-hawker opened this issue Jul 7, 2022 · 9 comments
Open

Can't run in VS Code Locally #190

michael-hawker opened this issue Jul 7, 2022 · 9 comments
Labels
bug 🐛 Something isn't working build 🔥 dev loop ➰ For issues that impact the core dev-loop of building experiments documentation 📃 Improvements or additions to documentation WASM Bugs related to working with WASM/Codespaces

Comments

@michael-hawker
Copy link
Member

michael-hawker commented Jul 7, 2022

Looks like the revamp in #91 to make everything work in codespaces broke things from working in VS Code locally due to the use of pwsh in the tasks.json pre-launch step:

> Executing task: pwsh ./GenerateAllSolution.ps1 <

pwsh : The term 'pwsh' 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
+ pwsh ./GenerateAllSolution.ps1
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (pwsh:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 
The terminal process "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -Command pwsh ./GenerateAllSolution.ps1" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

We need to figure out a way to make this work for both local and Codespace development on Windows/Linux, there must be something to handle this built into VS Code itself, right?

  1. Clone main
  2. Open up VS Code in root
  3. Run and Debug 'All samples app'
  4. See error.

On Win 10 latest.

@michael-hawker michael-hawker added bug 🐛 Something isn't working WASM Bugs related to working with WASM/Codespaces build 🔥 dev loop ➰ For issues that impact the core dev-loop of building experiments labels Jul 7, 2022
@michael-hawker michael-hawker added this to the Initial Release milestone Jul 7, 2022
@michael-hawker
Copy link
Member Author

Looks like I'm not getting PowerShell Core installed so it's still using the inbox version.

@michael-hawker michael-hawker added the documentation 📃 Improvements or additions to documentation label Jul 8, 2022
@michael-hawker
Copy link
Member Author

michael-hawker commented Jul 8, 2022

I used winget to grab the PowerShell version from the store, then restarting VS Code picked that up automatically; but doesn't look like that's the default, so we'll have to document this?

@michael-hawker
Copy link
Member Author

(Also, would be nice if we pop open the website in a tab in VS Code or something like what happens in Codespaces?)

@Arlodotexe
Copy link
Member

Iirc, PowerShell Core should have been prebundled with VSCode as the "PowerShell Integrated Console", and if this is open when you use click the Run it should get used.

image

@michael-hawker
Copy link
Member Author

Before I installed PS Core separately, I was seeing the Integrated Console message with the latest update, but it was still just using my local Desktop version of PowerShell.

I think VS Code is programmed to detect which PowerShell versions you have and use Core if it's available, but I don't think it's coming/installing bundled together.

@Arlodotexe
Copy link
Member

That sounds plausible. The next question is "how do we fix this", because PowerShell Desktop uses powershell.exe, and PowerShell Core uses pwsh, and our solution needs to work on box Windows and Linux.

@michael-hawker
Copy link
Member Author

That sounds plausible. The next question is "how do we fix this", because PowerShell Desktop uses powershell.exe, and PowerShell Core uses pwsh, and our solution needs to work on box Windows and Linux.

I mean once I installed the right thing, it worked, so it may just be an extra pre-build check we need to do to let people know to install the right thing vs. just failing. (Though, I still think it's important we test and maintain our scripts to ensure they run on the Windows version of powershell.exe like we're doing in the CI right now still.)

@Arlodotexe
Copy link
Member

It's a bit of a chicken and egg situation. We need to know if the user is on Windows or Linux before picking between pwsh and powershell.exe, but we can't know that without some kind of scripting.

If we can solve this problem, we're good. I wonder if Visual Studio Code has something built in that could help us?

@Arlodotexe
Copy link
Member

This should help: https://stackoverflow.com/a/64911186/5953220

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something isn't working build 🔥 dev loop ➰ For issues that impact the core dev-loop of building experiments documentation 📃 Improvements or additions to documentation WASM Bugs related to working with WASM/Codespaces
Projects
None yet
Development

No branches or pull requests

2 participants