Custom types and formats are mostly used while creating custom modules. Rarely do administrators require modifying the types or formats for stock PowerShell modules. And when you do require modifying custom types or formats, create a new PS1XML; do not modify the stock files, since they are digitally signed, and modifying them would break your setup.

Think of this PS1XML file as a regular XML file. Here is a simpler way of showing the structure. Remember that each type and each of the members within, must have a name.

Types
-- Type
---- Members
------ [The custom properties and methods you define]

In essence, using the XML for type extension is not very different from how we performed type extension in the last recipe, except this uses an XML file, which makes the setup more portable. When we work on creating our custom modules, we will look at packaging the types along with the modules, and at that time, we will look in detail, how to work the paths. For now, we load the XML by manually specifying the exact path to the file. If you would like to load these custom types for every session of yours, you can easily call the PS1XML from your profile. The portability aspect here is that the XML can easily be shared or deployed; only the loading would be manual, or through the profile—much simpler than adding cmdlets to profiles.

When updating the type data using cmdlets, we used the parameters Name as well as Value, along with the MemberType parameter. PowerShell understood the context and set up the types accordingly. In case of XML, though, one must remember to use the correct tags for each of the member types. For instance, for AliasProperty, the tags within should be Name and ReferencedMemberName (shown below); for ScriptProperty, they should be Name and GetScriptBlock; for a NoteProperty, the tags would be Name and Value.

<AliasProperty>
   <Name>Modified</Name>
   <ReferencedMemberName>LastWriteTime</ReferencedMemberName>
</AliasProperty>

Also, remember not to enclose the entire script block in braces when placing the statement within the GetScriptBlock tag:

<GetScriptBlock>
 [math]::Round(((Get-Date) - $this.LastWriteTime).TotalDays)
</GetScriptBlock>

and not:

<GetScriptBlock>
 { [math]::Round(((Get-Date) - $this.LastWriteTime).TotalDays) }
</GetScriptBlock>

When loading the XML, we use the PrependPath parameter to load our XML before the built-in types are loaded. To load them after the built-in types, there is no need to use the AppendPath parameter, unless the situation really needs it, since AppendPath is the default. Why do the parameters matter? They determine the precedence of loading the types.

The XML file shown may look like having a large number of items. Use the indent guide in Visual Studio Code to guide you through reading the XML. The file, in reality, is very simple to read. And reading it will help you understand how the properties are defined.