Module manifest (.psd1) in PowerShell - Step-by-Step Execution

Concept Flow - Module manifest (.psd1)

Create .psd1 file

↓

Define metadata keys

↓

Set values for keys

↓

Save manifest file

↓

Import module using manifest

↓

Module loads with metadata

This flow shows how a PowerShell module manifest file (.psd1) is created, filled with metadata, saved, and then used to load a module with that metadata.

Execution Sample

PowerShell

@{
  ModuleVersion = '1.0.0'
  GUID = '12345678-1234-1234-1234-123456789abc'
  Author = 'Jane Doe'
  Description = 'Sample module manifest'
}

This code defines a simple PowerShell module manifest with version, GUID, author, and description.

Execution Table

Step	Action	Key/Value Set	Result
1	Create new hashtable for manifest	N/A	Empty hashtable created
2	Set ModuleVersion	ModuleVersion = '1.0.0'	Version key added
3	Set GUID	GUID = '12345678-1234-1234-1234-123456789abc'	GUID key added
4	Set Author	Author = 'Jane Doe'	Author key added
5	Set Description	Description = 'Sample module manifest'	Description key added
6	Save hashtable to .psd1 file	N/A	Manifest file saved
7	Import module using manifest	N/A	Module loads with metadata

💡 All keys set and manifest saved; module imported successfully

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
$Manifest	empty	{ModuleVersion='1.0.0'}	{ModuleVersion='1.0.0', GUID='12345678-1234-1234-1234-123456789abc'}	{ModuleVersion='1.0.0', GUID='12345678-1234-1234-1234-123456789abc', Author='Jane Doe'}	{ModuleVersion='1.0.0', GUID='12345678-1234-1234-1234-123456789abc', Author='Jane Doe', Description='Sample module manifest'}	saved to .psd1 file

Key Moments - 3 Insights

Why do we use a hashtable to create a module manifest?

Because the manifest file (.psd1) is a PowerShell data file that stores key-value pairs in a hashtable format, as shown in the execution_table steps 1-5.

What happens if the GUID is missing or incorrect?

The module may not load correctly or could conflict with other modules. The GUID uniquely identifies the module, as shown in step 3 of the execution_table.

Can we add custom keys to the manifest?

No, the manifest supports specific predefined keys. Adding unknown keys will be ignored or cause errors. The execution_table shows only standard keys being set.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of the 'Author' key after step 4?

A 'Jane Doe'

B 'John Smith'

C Empty

D 'Sample module manifest'

💡 Hint

Check the 'Key/Value Set' column at step 4 in the execution_table.

At which step is the manifest file saved to disk?

A Step 5

B Step 7

C Step 6

D Step 3

💡 Hint

Look for the action mentioning saving the manifest file in the execution_table.

If we remove the GUID key, what is the likely effect when importing the module?

A Module imports normally without issues

B Module import fails or conflicts may occur

C Author information is lost

D Module version resets to 0.0.0

💡 Hint

Refer to the key_moments section about the importance of the GUID.

Concept Snapshot

Module manifest (.psd1) is a PowerShell data file storing module metadata as a hashtable.
Keys like ModuleVersion, GUID, Author, and Description define module info.
Create a hashtable with these keys, then save it as a .psd1 file.
Importing the module uses this manifest to load metadata and settings.
GUID uniquely identifies the module; missing it can cause load issues.

Full Transcript

A PowerShell module manifest is a .psd1 file that holds metadata about a module. It is created as a hashtable with keys such as ModuleVersion, GUID, Author, and Description. Each key is assigned a value describing the module. After setting these keys, the hashtable is saved to a .psd1 file. When the module is imported, PowerShell reads this manifest to load the module with its metadata. The GUID is important because it uniquely identifies the module and prevents conflicts. This process ensures the module is properly described and loaded.

Practice

1. What is the primary purpose of a PowerShell module manifest (.psd1)?

easy

A. To store user credentials for the module

B. To execute the module's main script

C. To describe the module's metadata and control its behavior

D. To compile the module into an executable file

Solution

1. Step 1: Understand what a module manifest is

   A module manifest is a file that contains metadata about the module, such as version, author, and dependencies.

2. Step 2: Identify the manifest's role

   It controls what parts of the module are visible and required, helping users understand and use the module properly.

3. Final Answer:

   To describe the module's metadata and control its behavior -> Option C

4. Quick Check:

   Manifest = metadata and control [OK]

Hint: Manifest files describe modules, not run code [OK]

Common Mistakes:

• Thinking the manifest runs the module code
• Confusing manifest with script files
• Assuming manifest stores credentials

2. Which of the following is the correct syntax to specify the module version in a .psd1 manifest file?

easy

A. 'ModuleVersion' = '1.0.0'

B. ModuleVersion: 1.0.0

C. ModuleVersion = 1.0.0

D. "ModuleVersion" : "1.0.0"

Solution

1. Step 1: Recall .psd1 file syntax

   A .psd1 file uses a hashtable syntax with key-value pairs, where keys are strings in quotes and values are assigned with '='.

2. Step 2: Match correct syntax for version

   The correct syntax is a string key in quotes, an equals sign, and the version string in quotes: 'ModuleVersion' = '1.0.0'

3. Final Answer:

   'ModuleVersion' = '1.0.0' -> Option A

4. Quick Check:

   Hashtable key-value with '=' and quotes [OK]

Hint: Use quotes and '=' for keys and values in .psd1 [OK]

Common Mistakes:

• Using colon instead of equals sign
• Omitting quotes around keys or values
• Using JSON style syntax

3. Given this snippet from a module manifest (.psd1):

@{
  RootModule = 'MyModule.psm1'
  ModuleVersion = '2.1.0'
  FunctionsToExport = @('Get-Data', 'Set-Data')
}

What will happen when you import this module?

medium

A. Only the functions 'Get-Data' and 'Set-Data' will be available to the user

B. All functions in MyModule.psm1 will be available regardless of FunctionsToExport

C. The module will fail to import due to syntax error

D. The module version will be ignored during import

Solution

1. Step 1: Understand FunctionsToExport key

   The FunctionsToExport key lists which functions are visible outside the module when imported.

2. Step 2: Analyze the effect on import

   Only 'Get-Data' and 'Set-Data' will be exported and accessible to users after import.

3. Final Answer:

   Only the functions 'Get-Data' and 'Set-Data' will be available to the user -> Option A

4. Quick Check:

   FunctionsToExport limits visible functions [OK]

Hint: FunctionsToExport controls visible functions [OK]

Common Mistakes:

• Assuming all functions export by default
• Thinking syntax error exists here
• Ignoring FunctionsToExport effect

4. You wrote this in your module manifest (.psd1):

@{
  RootModule = 'MyModule.psm1'
  FunctionsToExport = 'Get-Data', 'Set-Data'
}

When importing the module, you get an error. What is the problem?

medium

A. The manifest file must not contain RootModule key

B. RootModule must be a script file, not a module file

C. FunctionsToExport cannot contain more than one function

D. FunctionsToExport should be an array, not a list of strings without @()

Solution

1. Step 1: Check FunctionsToExport syntax

   FunctionsToExport expects an array of strings, which requires the @() syntax in PowerShell.

2. Step 2: Identify the error cause

   Writing 'Get-Data', 'Set-Data' without @() is invalid in a hashtable value and causes an error.

3. Final Answer:

   FunctionsToExport should be an array, not a list of strings without @() -> Option D

4. Quick Check:

   Use @() for arrays in manifest [OK]

Hint: Use @() to define arrays in .psd1 manifest [OK]

Common Mistakes:

• Omitting @() for arrays
• Misunderstanding RootModule usage
• Assuming single string can list multiple functions

5. You want your PowerShell module to automatically import a required module and only export one function named 'Invoke-Task'. Which manifest entries should you include?

hard

A. @{ RequiredModules = 'HelperModule'; FunctionsToExport = @('Invoke-Task') }

B. @{ RequiredModules = @('HelperModule'); FunctionsToExport = @('Invoke-Task') }

C. @{ RequiredModules = @('HelperModule'); FunctionsToExport = 'Invoke-Task' }

D. @{ RequiredModules = 'HelperModule'; FunctionsToExport = 'Invoke-Task' }

Solution

1. Step 1: Define RequiredModules correctly

   RequiredModules must be an array of module names, so use @('HelperModule').

2. Step 2: Define FunctionsToExport correctly

   FunctionsToExport must be an array of function names, so use @('Invoke-Task').

3. Final Answer:

   @{ RequiredModules = @('HelperModule'); FunctionsToExport = @('Invoke-Task') } -> Option B

4. Quick Check:

   Use arrays (@()) for RequiredModules and FunctionsToExport [OK]

Hint: Always use @() arrays for RequiredModules and FunctionsToExport [OK]

Common Mistakes:

• Using strings instead of arrays for RequiredModules
• Using strings instead of arrays for FunctionsToExport
• Mixing array and string syntax