So, let me start off by saying thank you for this software. It may have given me headaches most of today, but when I’ve gotten it working, I love it. I don’t want to be ungrateful, so thank you for your hard work.
Environment: Server 2019 std
PowerShell Universal: 1.5.19
VSCode: 1.56.2
PowerShell Universal Ext: 1.8.2
I installed PowerShell Universal today on a server/jumpbox. It had an older version that was installed but never used. I removed it first and then installed the latest version. As an aside, I do find it odd that an MSI installer launched in graphical mode in an interactive session gives no feedback to its installation process. Just a quick blip from UAC and then gone. Any indication that the installer is done and has been successful, like a simple “installation complete” dialog at the end, would be welcome, since the installer wasn’t launched with the quiet argument. I’ve seen some reference that it’s supposed to open a web browser to the admin console, this hasn’t happened the last two times I’ve installed it on two different machines. I’d rather have a dialog box confirming it that then attempts to open a browser session to the admin panel after clicking OK.
I opened VSCode and installed the latest extension and promptly had problems. After excessive tinkering I decided to start all over and uninstalled the extension and Universal itself and started over. Same problems.
The extension first refused to work due to missing a Server Path variable. It gives no indication of where this variable might be or its scope. Reading through the docs makes it sound like it’s only an install time configurable variable. Anyway, its a VSCode configuration on the extension not in Universal config file or an environment variable. No idea why that’s blank by default, but since I installed Universal via MSI, I just took the path from the Service it creates and popped it in. That fixed that.
Next was Exit Code 3762504530. This was caused by another confusing default extension configuration. Simply unchecking PowerShell Universal: Start Server resolved the error message.
I could now see my blank test dashboard. Unfortunately, the authentication configuration file loads a blank file from C:\Users\MYUSER\AppData\Local\Temp\2.universal.code.configuration instead of what is clearly displayed in the browser. OK, I made some edits in the browser and now it successfully loads in VSCode. It looks like the same file location, so I guess that’s a bug/quirk.
All of this comes to my last issue. It doesn’t look like the module loads by default when you open the extension, nor does it look like the MSI installer registers the module correctly with PowerShell. While trying to edit the default authentication, testing anything with a PowerShell Universal cmdlet will fail, saying the cmdlet is unrecognized. A quick Get-Module confirms it’s not there. When I hit this problem in previous installs (not a first), I was able to just import-module and point at the dashboard framework I was working on, but that seems to be throwing errors today. I can run Import-Module 'C:\Program Files (x86)\Universal\Universal.psm1' -Scope Global successfully, but trying to import either the v2 or v3 module the same way throws a bunch of type mismatch errors. I’m guessing I’m missing some other module that needs to be loaded first, but I am just frustrated that it isn’t being loaded automagically at all.
I feel like I must be doing something wrong, but it’s just so frustrating to have all these issues right out of the box, and if I wasn’t a returning user, this would certainly leave an awful first impression. So, that’s my long-winded frustration for the day. Any help and direction would be greatly appreciated. Thanks in advance.
Thanks for the feedback. I’ve updated the installer to include a more traditional UI; including an end page when finished that includes information about what to do next.
Yes. This sounds buggy. I’m working on making the extension configuration more seamless. Instead of configuring the extension manually from within the extension, what I’m adding is a button within PowerShell Universal that, when clicked, will automatically open VS Code and configure it for the PSU instance you are using via a custom protocol handler.
I’ve gone through a few iterations of how to get the VS Code extension configured easily but every time it seems to cause problems like the one you are seeing. It’s certainly too hard to use right now.
The VS Code extension should load the modules but if it’s not, it’s something else I need to look into. The reason we don’t install the Universal module or the UD modules into the PSModulePath is because it’s possible to install multiple instances of PSU on a single server and potentially have multiple versions. That said, it’s rare and I’ve had this discussion with others that we should probably just be setting the PSModulePath in the installer to make things easier for first time users. It might even make sense to have an option that does this and it’s on by default but you can disable it if you like.
We also publish this modules to the PS Gallery so you can install Universal and UniversalDashboard to get intellisense that way. UD is dependent on Universal so if you install the module, it will install Unviersal as well.
Install-Module UniversalDashboard
I agree this sounds like a very poor first experience with the platform. I’m constantly improving and feedback like this is extremely important to me to understand the user experience. I think the transition from the previous version of UD to PSU has been rough for existing users so I understand the frustration and hope that going forward you’ll stick around as the platform evolves into something great.
I’ve implemented a new button in the PSU admin console to make connecting to VS Code much easier. This will be available in PSUv2.
You’ll be able to just click Edit with VS Code and it will automatically connect the PSU instance with your local VS Code instance. It takes care of setting the URL and app token automatically.
