Carl (discord)the latter is able to import "Microsoft.PowerShell.Utility". Next it is able to run the import-module statement against your module, but it does not yield the imported module given -passthru
chrisdent (discord)CreateDefault2 has less clutter in it. It's generally better for more modern things
Carl (discord)and var posh = PowerShell.Create(InitialSessionState.CreateDefault2());
Carl (discord)o no...... Now suddenly AddCommand also just works
Carl (discord)there you go........ where is this execution policy setting living?
Carl (discord) cmd> C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
powershell32-bit> Get-ExecutionPolicy -list
Scope ExecutionPolicy ----- ---------------
Carl (discord)got it.......
seeminglyscience (discord)vscode? or just normal terminal? if the former the easiest is to make sure you have the 64bit version of vscode installed and check that the settings aren't explicitly calling the 32bit version. If the latter, you can't really other than just making sure you open the right one
seeminglyscience (discord)just to be 100% clear, there's no PowerShell process involved. It's load the libraries directly into the same process. But you can just do
seeminglyscience (discord)just set the scope to process
Carl (discord)Any clue where the local machine scoped execution policy gets persisted? I discovered that there are at least for different "local machine" locations: PowerShell 64-bit 5.1, PowerShell 7+, PowerShell 32-bit 5.1 and... At least one for the .NET app hosted PowerShell runspace. In the registry I see maybe all of them. The latter would then be "ScriptedDiagnostics" (when I am at my laptop I will check the exact name); have to play with it.
Carl (discord)Ok just checked the source code, it is stored into powershell.config.json for the systemwide install. but where are the settings for the dotnet app hosted version? Answer: ConsoleApp1\bin\Debug\netcoreapp3.1\runtimes\win\lib\netcoreapp3.1 (edited)
wsmelton (discord)Is it not stored or controlled by your InitialSessionState? https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.runspaces.initialsessionstate.executionpolicy?view=powershellsdk-7.0.0
johlju (slack)Maybe this helps? https://github.com/dsccommunity/DscResource.AnalyzerRules/blob/master/Source/Public/Measure-Keyword.ps1
Jaykul (discord)I half wrote a C# version to submit to the ScriptAnalyzer repo
Jaykul (discord)I'm trying to decide if I should get carried away and do variable case too (edited)
ninmonkey (discord)Maybe if the powershell extension were to use https://code.visualstudio.com/api/language-extensions/embedded-languages
pwshaddict (discord) So next question would be how to run tests against the code? Sounds more complicated than it needs to be.
I really wanna push for only using inline code for very basic stuff. If more than X number of lines, maybe we should make it a script or part of a custom module. (edited)
chrisdent (discord)you've got to get it out of the yaml doc. ScriptAnalyzer cannot do that part for you.
chrisdent (discord)for all my inline PS I have it run minimal commands which install / use modules I've written. Those, ofc, can be properly tested
ninmonkey (discord)You could try this module https://github.com/StartAutomating/Benchpress
c.bergmeister (slack)running just that rule will isolate any noise, you will only be left with some overhead to initialize PSSA (which always takes longer the first time). custom rules are run serially so no multi-threading complexity. I suggest to test it how the rule scales with the size of the script. I myself like to use PowerShell's build module as a realistic test case: