Script Packaging Step-by-Step: Output Settings

In this installment of our Script Packaging series, we explore the Output Settings. Most settings on this page have a reasonable default; we will address each setting and its alternatives.


Output settings

We will start with the Output settings group.


File name

The File name field is probably self-explanatory; this defines the name of the executable file produced. It will default to the base name of the script to be packaged, so DriveSpace.ps1 becomes Drivespace.exe.

Please note that you do not need and should not add an extension to the name. The .exe is appended during the packaging process.



The Folder is the top-level output folder where the packaged application is placed. Subfolders for individual platforms will be created based on the scripting engine chosen—and, as with PowerShell 7—folders named with the base name of the application. If you have multiple scripts in a folder and they all package to bin, this usually poses no problem as long as the base name is not identical.

If you divert the output folder to another location—for instance, on a network drive—please ensure that you have sufficient access to create subfolders and can write, create, and delete files.


There are three options at the bottom of the Output settings section:

Output settings

Generate .config file

Generate config file is checked by default, and you should leave it that way unless you have a specific reason not to. This setting only applies to packages created with the .NET framework, which means Windows PowerShell 5.1. For other packager engines, this option has no effect. The absence of a config file can negatively impact how your application looks on higher-resolution monitors and prevent your application from correctly handling long path names.


Resolve and include external scripts

Resolve and include external scripts will take any dot-sourced script and directly insert its code at that location—this only works for static file names. If the file name is a variable that only has a value when the script actually runs, this cannot be resolved during packaging. Scripts that get included by this option do not need to be published with your application.


Hash file type

Hash file type gives you the option of creating a corresponding hash file (MD5, SHA1, or SHA256) for your executable file, for example, in case you need to have one for download verification. If you are packaging for PowerShell 7, your application consists of a folder with many files. In that case, creating a hash file is possible but may not make a lot of sense.


Manifest creation

The next section handles settings for manifest creation. What is a manifest, you ask? A manifest is an XML file that gets embedded as a resource in the produced executable file.


Application manifests (Microsoft doc) describes the possible elements this file can contain.

For the purpose of packaging scripts, embedding a default manifest should be your choice unless you require your packaged script to run elevated. In this case, you should choose Embed a default manifest for elevation. Creating an application without a manifest is commonly used when you want to include a particular, user-modifiable custom manifest as an external file.

From regular user to elevated administrator will provide you with more information regarding elevation and the manifest’s role in it.


Alternate credentials

The Alternate credentials settings enable you to force your script to run under the security context of another user.


The previous link about the elevation manifest also explains some of the issues regarding this subject.


Run Mode

There are three options for Run Mode:

Current user is the default and runs your script under the currently logged on user’s security context.

Impersonate user uses the provided credentials to create a new security context for the user in-process. For example, this may be necessary to access a specific user’s data folder from the current user’s context.

RunAs user has the packaged executable relaunch itself with another user context. If you use this option and look in Process Explorer, you will see two instances of your application; this is normal and expected.

Please note that you cannot use RunAs and elevation successfully in the same executable file. The elevation manifest is evaluated before the process is launched, so the RunAs part would be too late to the party.



Signing lets you to use a digital code signing certificate to sign and timestamp your application. As with script signing, this verifies the origin and integrity of your application to the end user.


For more information about code signing and digital certificates, please see Everything you wanted to know about Code Signing but were afraid to ask.

If you have questions about timestamps, please see Why do I need a timestamp when signing a script?.

You should note that if you have a more recent code signing certificate using SHA256, the timestamp server must also use SHA256 (also referred to as SHA2). If signing fails with an otherwise functioning certificate, the timestamp server is most commonly the source of problem. Please try different options or ask the vendor of your certificate which timestamp server they recommend.



Questions or comments? Please feel free to post in the comment section below or in our support forums.