Having multiple individual scripts sitting around on your machine can make it difficult to stay organized. Collection projects can help you manage your scripts while utilizing the benefits of a project in PowerShell Studio.
This article is the next installment in our PowerShell Studio Project series and covers the basics of working with Collection projects.
What is a Collection project?
A Collection project groups various files without creating a single script (as is done in a regular project), and each script file runs individually.
Collection projects allow you to keep track of a group of files, which typically consist of—but are not limited to—PS1 or PSF script files. For example, you may have various PS1 scripts that dot source each other. A Collection project can manage multiple files, provide PrimalSense support for dot sourced files, and apply rename refactoring on all of your files.
When you first create a Collection project, the project will be empty:
Because all of the files in a Collection project are individual files, there is no entry point; therefore, there is no Startup.pss file.
Collection projects only support project files with Build = Content. Therefore, the Build Order property is not applicable, which means there is no merging of the project files to make one script. See PowerShell Studio Projects: Introduction for more information on general project settings. You will be unable to change the Build Setting for project files:
Building and Running
You can run or debug each file individually from the ribbon (Home -> Build and Run) or by right-clicking on the file:
When debugging, all breakpoints in project files will be written to the Tools Output panel:
This will always happen even if the files listed are not dot sourced to the selected running file. You will be able to walk through dot sourced project files while debugging.
Deploy As determines the deployment behavior of the Project as a whole. There are two Deploy As options:
The File option instructs the project to handle each file individually during deployment. Each project file will maintain its own independent settings.
It is best to use this setting when you are using the Collection project to group individual files that don’t necessarily interact with each other. This setting enables you to package and deploy (publish) each script independently; each file will have its own PSBUILD settings file for the SAPIEN Script Packager.
The Project option tells the project to handle the deployment of all the files as a whole. You must define a Primary File to build with the SAPIEN Script Packager:
Primary File is the file that is packaged into an executable when deploying as a Project. All other files will be considered external Content—they will not be combined into the primary file to make one script.
The PSBUILD file will use the name of the project rather than one of the project files like the following:
It is best to use this setting when you have a group of files that interact and have a start/entry point script; for example, if you have a primary script that dot sources various secondary scripts. In this case, the primary script will get packaged to an executable, and then you can create an installer that includes the primary packaged script and all the supporting files scripts.
All information provided in this article is based on the functionality available in PowerShell Studio 2022 build 5.8.205.
As always, any feedback is appreciated. If you have a particular type of blog article or product feature request you would like to see, please submit your suggestions on the Wish List and Feature Requests forum or the new Feature Requests page.