Page 1 of 1

'Run' profile configuration

Posted: Fri May 15, 2020 10:28 am
by ggreen
To help you better we need some information from you.

*** Please fill in the fields below. If you leave fields empty or specify 'latest' rather than the actual version your answer will be delayed as we will be forced to ask you for this information. ***

Product, version and build: Product: PowerShell Studio 2020 v5.7.175
32 or 64 bit version of product: 64
Operating system: Windows 10 Enterprise
32 or 64 bit OS: 64

*** Please add details and screenshots as needed below. ***


I am working on a module project currently and building Pester tests for the module. In order to test the module the way I need to, it has to be imported and pull specific metadata for the tests. I have found that when I run the Pester tests I am building, it does not appear to be able to specify a host specific profile (meaning PS Studio specific similar to the way VS Code can use a 'Microsoft.VSCode_profile.ps1' profile) unless I am missing a configuration setting in the application. It also does not appear to be using any existing profiles within PowerShell when running the Pester tests within PS Studio. As a work around I have included lines in the Pester test script for the module to include adding the dev module path into the environment but that is less than ideal.

My question is whether or not there is a configuration setting I have missed to have PS Studio load a particular environment for running the Pester tests or is there a PS Studio specific profile file I can create that PS Studio will use whenever it runs my code so that I can include my dev module location only in that profile? Ideally the host specific profile would be preferable but if I can at least get the environment modification work-around out of my Pester tests that would be nice.


Re: 'Run' profile configuration

Posted: Tue May 19, 2020 3:58 pm
by Alexander Riedel
Without knowing exactly what you are setting this is not easy to answer specifically.
As a general rule, we do not ever execute any profiles when running a script. Just as we *always* run a script in a new runspace. That automatically prevents any dependence on a local setting and runspace contamination, both of which are quite detrimental when you then want to run your script or module on another machine or machines.
Because of that we do not have, support or load any PowerShell Studio specific profiles.

What it sounds like, and please forgive me if I have this wrong, you do not want to include certain settings in each and every pester test script. Which is quite understandable.
I would recommend to create your own profile, with whichever name you prefer (e.g. PesterTestEnvironment.profile.ps1) and simply dot source that in your test scripts as a first statement.
It's really the same thing as a profile, since a profile is simply a script that is executed when a host is fired up.
As PowerShell Studio launches the host each and every time you run your test script, that would just have the same effect.

Re: 'Run' profile configuration

Posted: Thu May 28, 2020 4:32 pm
by ggreen
The problem I was trying to solve was falsely importing an older version of the PowerShell module I am developing and testing with pester (or not importing at all because it cannot find it) when I run the Pester tests. When I posted I was looking for a way for PowerShell Studio to automatically know where scripts in development are located. After I originally I worked through a much cleaner way to accomplish the goal within my Pester test code so that it runs every time without reliance on any external files. It also does not require writing any paths to the test or changing anything except a number value to subtract from the invocation path length (in line 4 of the code below) which is based upon the test file name and where within the module structure it is placed.

I have included code which solved this delema for me below in case anyone that comes across this post in the future is having the same problem and needs a solution for consideration.

Please consider this issue closed if you have not already.


  1. #Determine module names and paths to use for module import
  3. $script_path = ($MyInvocation.MyCommand.Path)
  5. $script_path_length = $script_path.Length
  7. $module_path_length = ($script_path_length - 41)
  9. $module_path = $script_path.Substring(0, $module_path_length)
  11. $module_name = (Split-Path -Path $module_path -Leaf)
  13. $manifest_file_name = $module_name, "psd1" -join "."
  15. $root_module_file_name = $module_name, "psm1" -join "."
  17. $module_import_path = $module_path, $manifest_file_name -join "\"
  19. $root_module_file_path = $module_path, $root_module_file_name -join "\"
  21. $manifest_file_content = (Import-PowerShellDataFile -Path $module_import_path)
  23. $private_function_path = $module_path, "Components", "Functions", "Private" -join "\"
  25. $public_function_path = $module_path, "Components", "Functions", "Public" -join "\"
  27. #Remove existing instance of the module from memory before importing current module for testing
  29. $module_loaded = (Get-Module -Name $module_name)
  31. if ($null -ne $module_loaded) {
  33.     Remove-Module -Name $module_name
  35. }
  37. #Import the modules to begin testing.
  39. Import-Module -Name Pester
  41. Import-Module -Name $module_import_path