Trevor Sullivan read my post and suggested in his comment to analyze the use of wildcards to export functions, variables or aliases using the manifest file.

After trying this I got enthusiastic about it, read further…

As well in the manifest file as with the use of Export-ModuleMember in the module wildcards can be used.

This can be (very) helpful when naming the function in the module according to a certain structure.
In C# accessibility levels are used to restrict or limit access to certain methods. There is no such thing in PowerShell, but this can be achieved by (not) exporting the functions from a module. In C# reserved accessibility levels as public and private are used. We can use this ‘technique’ in PowerShell by naming the functions in a module according to a standard: use for example -public or _public at the end of a functionname or variable in a module and use the same string literal as wildcard to export functions.

Practically this means defining Export-ModuleMember in the module like:
Export-ModuleMember -Function “*”
Export-ModuleMember -Variable “*”
Export-ModuleMember -Alias “*”
to export all functions, variables and aliases.
Then restrict the exported items in the module manifest like:
FunctionsToExport = ‘*-Public’
VariablesToExport = ‘*_Public’
AliasesToExport = ‘*-Public’

Module (psm1)

$msgText_Public = 'Hello world!'
$anotherVariable = 'more here'

function Say-HelloWorld() { Write-Host $msgText }
function Calc-Numbers-Public([int] $a,[int] $b) { $a + $b }
function I-Am-Public() { Write-Host "Public" }

Set-Alias Add Calc-Numbers
Set-Alias Hello-Public Say-HelloWorld

Export-ModuleMember -Function "*" #Say-HelloWorld, Calc-Numbers
Export-ModuleMember -Variable "*" #msgText, anotherVariable
Export-ModuleMember -Alias "*"  #Hello, Add

Manifest (psd1)

# Functions to export from this module
FunctionsToExport = '*-Public'

# Variables to export from this module
VariablesToExport = '*_Public'

# Aliases to export from this module
AliasesToExport = '*-Public'

And the result:

Summary

In my previous post I wrote in the summary:
‘The export keys in the manifest can be seen as an export override of the Export-ModuleMember used in a module… When trying to control the exports of variables and aliases it all comes clear: export them in the module at all times!’

After analyzing the wildcard options to export I still agree on the above statements, but I would like to nuance it a bit: export all items in the module and restrict the exported items in the module manifest by using wildcards in the module manifest and using a naming convention when defining functions, variables and aliases.

When approaching exporting the items from a module as described above you can not forget to export a function, variable or alias, you just have to follow this naming convention.

2. By using a module manifest and specifiy what resources need to be exported like:
@{
….
FunctionsToExport = ‘ VariablesToExport = ”
….
}

By seeing this I got a little confused on which method to use and why: Export-ModuleMember or the manifest way, so it was time to dig into this matter.
By creating a small module, a manifest and a script file the different options can be tested.

Module (psm1)

In the module three functions, two with an alias and two variables are defined and exported:

$msgText = 'Hello world!'
$anotherVariable = 'more here'

function Say-HelloWorld() { Write-Host $msgText }
function Calc-Numbers([int] $a,[int] $b) { $a + $b }
function I-Am-Private() { Write-Host "private" }

Set-Alias Add Calc-Numbers
Set-Alias Hello Say-HelloWorld

Export-ModuleMember -Function Say-HelloWorld, Calc-Numbers
Export-ModuleMember -Variable msgText, anotherVariable
Export-ModuleMember -Alias Hello, Add

Manifest (psd1)

The export variables of the manifest are (default) set to ‘*’:

# Functions to export from this module
FunctionsToExport = '*'

# Cmdlets to export from this module
CmdletsToExport = '*'

# Variables to export from this module
VariablesToExport = '*'

# Aliases to export from this module
AliasesToExport = '*'

Script (ps1)

The script file imports the module and displays information about the module. This is an excellent way to test what resources are exported:

Import-Module ExportFunctions -Force
Get-Module -Name ExportFunctions | fl

Tests

Running this script results in the following output:

As can be seen two functions, the aliases and variables are exported as defined in Export-ModuleMember in the module.

The Export-ModuleMembers lines are now removed to test the default settings in the manifest file (all ‘*’ for the export keys). Running the same script now results in:

All the functions are exported, but none of the alias or variables. At first sight this seems a bit strange, because the generated comment of the export keys of the manifest say ‘ to export from this module’. This seems only the case for the functions.

TechNet documentation for FunctionsToExport key:

Specifies the functions that the module exports (wildcard characters are permitted) to the caller’s session state. By default, all functions are exported. You can use this key to restrict the functions that are exported by the module…

And the TechNet documentation for VariableToExport key:

Specifies the variables that the module exports (wildcard characters are permitted) to the caller’s session state. By default, all variables are exported. You can use this key to restrict the variables that are exported by the module…

The statement don’t differ, but the behavior is.

The ‘*’ at the FunctionsToExport key means the restriction is:

If Export-ModuleMember -Function in the module is used, the functions listed there are exported:
In module:

Export-ModuleMember -Function Say-HelloWorld, Calc-Numbers

In manifest:

FunctionsToExport = '*'

Result:

If Export-ModuleMember -Function is NOT used in the module and in manifest ‘*’ is used all functions are exported:

The ‘*’ at the VariablesToExport key means: By default none of the variables are exported, unless variables are exported by the Export-ModuleMember in the module.

In module: No Export-ModuleMember -Variable
In manifest:

VariablesToExport = '*'

Result:

In module: No Export-ModuleMember -Variable
In manifest:

VariablesToExport = 'anotherVariable'

Result:

In module:

Export-ModuleMember -Variable msgText, anotherVariable

In manifest:

VariablesToExport = '*'

Result:

In module:

Export-ModuleMember -Variable msgText, anotherVariable

In manifest:

VariablesToExport = 'anotherVariable'

Result:

Summary

The export keys in the manifest can be seen as an export override of the Export-ModuleMember used in a module. When testing this behavior with functions alone it can be confusing – at least it confused me – which method to use – manifest export key or Export-ModuleMember – to restrict function exports. When trying to control the exports of variables and aliases it all comes clear: export them in the module at all times!

While another displays an actual value:
Actual term in a tree

or just a ‘parent’ term

Why?

When the fieldvalue is less than 19 characters the tooltip stays empty. Well empty.. it displays ‘Refine By:’. Every fieldvalue with more than 19 characters is displayed in the tooltip. A ‘parent’ term or a whole path.

How to solve?

This behavior can be solved by adjusting the xslt.

Original xslt:

<a href="{$SecureUrl}" title="{$RefineByHeading}: {$UrlTooltip}">
<xsl:value-of select="Value"/>
</a>

Adjusted xslt:

<xsl:variable name="UrlTooltipAdjusted">
 <xsl:call-template name="format-tooltip">
 <xsl:with-param name="tooltip" select="$UrlTooltip" />
 <xsl:with-param name="string" select="Value" />
 </xsl:call-template>
</xsl:variable>

<a href="{$SecureUrl}" title="{$RefineByHeading}: $UrlTooltipAdjusted}">
<xsl:value-of select="Value"/>
</a>

<xsl:template name="format-tooltip">
 <xsl:param name="tooltip" />
 <xsl:param name="string" />
 <xsl:choose>
 <xsl:when test="$tooltip != ''">
 <xsl:value-of select="$tooltip" />
 </xsl:when>
 <xsl:otherwise>
 <xsl:value-of select="$string" />
 </xsl:otherwise>
 </xsl:choose>
</xsl:template>

The ‘format-tooltip’ template checks if the tooltip is empty and replaces the tooltip value with the actual fieldvalue if so.
By doing this the tooltip will never be empty and will always show the value of the fieldvalue.

Summary

Besides the fieldvalues also the tooltip values suffer from a character limitation. The values of the refinement panel have a 19 character display limit, the tooltip doesn’t display the value when the fieldvalue is less than 19 characters.
This and the previous post solve these issues by making minor adjustments to the OOTB xslt.

Suppose a sitecolumn of a library is a managed metadata column bound to a global termset. The termset is the parent of a few terms and all of these terms have one or more children itself. A termtree.
The display format of the column is set to ‘Display the entire path to the term in the field’.

A few documents are uploaded to the library and the metadata column is set to one of the terms.
A full crawl is completed and the refinement panel shows the metadata refiner.
The refinement panel now looks like this:

As can be seen, not the whole fieldvalue is displayed. That’s weird. How do I know which one to use if not the whole value can be seen?
Maybe it’s a css issue or the left column of the screen isn’t wide enough? Starting up Firebug and checking out the value:

The whole value isn’t present as text to display in the panel! I was seriously surprised!
SharePoint returns only the first 19 characters and three dots…

But… hover over de terms and the whole path is displayed. But that’s not a satisfactory solution, the values have to be displayed properly!

Ok, I agree displaying the whole term tree path isn’t that useful in this case, but it’s needed somewhere else in the site, so the display format of the site column has to stay ‘Display the entire path to the term in the field’.
It would be great to have on option to show only the last term value despite the column display format. An excellent configuration place would be an extra attribute in the filter categories definition xml.

Displaying the last term value

The xslt of the refinementpanel can be adjusted to display the last term value now we know the tooltip does know the whole value.

Original xslt:

 <a href="{$SecureUrl}" title="{$RefineByHeading}: {$UrlTooltip}">
  <xsl:value-of select="Value"/>
 </a>

The new xslt looks a little bit different than that.
First the fieldvalue has to be analyzed if it contains ‘:’. The ‘:’ means the value is a child term and the whole tree path is displayed.
From the value which contains the whole tree path the last term is filtered by a recursive xslt template ´substring-after-last´.
Then a check has to be performed if the last term value contains the three dots. If it does, the last term value should be taken from the tooltip value, because the xslt Value doesn’t contain this value. Confusing, isn’t it?

<xsl:variable name="PartOfValue">
 <xsl:call-template name="substring-after-last">
  <xsl:with-param name="string" select="Value" />
  <xsl:with-param name="delimiter" select="':'" />
 </xsl:call-template>
</xsl:variable>

<xsl:variable name="PartOfTooltip">
 <xsl:call-template name="substring-after-last">
  <xsl:with-param name="string" select="$UrlTooltip" />
  <xsl:with-param name="delimiter" select="':'" />
 </xsl:call-template>
</xsl:variable>

<xsl:choose>
 <xsl:when test="($FilterCategoryType = 'Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator') and ($PartOfValue != '')">
  <xsl:if test="not(contains($PartOfValue, '…'))">
   <xsl:value-of select="$PartOfValue"/>
  </xsl:if>
  <xsl:if test="contains($PartOfValue, '…')">
   <xsl:value-of select="$PartOfTooltip"/>
  </xsl:if>
 </xsl:when>
 <xsl:otherwise>
  <xsl:value-of select="Value"/>
 </xsl:otherwise>
</xsl:choose>

If the fieldvalue contains less than 19 characters, no dots are displayed and the value can be used, but in that case the urltooltip is empty… To solve an empty tooltip, check out my next post.

After the xslt has been implemented the refinementpanel looks like the picture below

And the tooltip displays the whole term tree:

SharePoint returns only the first 19 characters, so what happens when a term itself exists of 19 or more characters?

On the one hand it’s great the 19 character limitation of displaying a whole termtree isn’t applied to this term, on the other hand, it doesn’t look very nice when the text continues outside the refinement panel.

Summary

The values of the refinement panel have a 19 character display limit. When displaying a whole termtree it’s likely this limitation will be exceeded. Just a few xslt adjustments are necessary to display the fieldvalues correct again.

ProfileSubtypeManager psubm = ProfileSubtypeManager.Get(context);
ProfileSubtype newSubtype = psubm.GetProfileSubtype(newSubtypeName);
currentUserProfile.ProfileSubtype = newSubtype;
currentUserProfile.Commit();

Changing the user subtype in the UI really updated the setting, so it was time to debug the SharePoint UserProfiles assembly.
The short version of what the debugging session(s) told me:
A UserProfileUpdateWrapper was created with the following xml

<?xml version="1.0" encoding="utf-16"?>
<MSPROFILE>
 <PROFILE ProfileName="UserProfile">
 <USER NewUser="0" NTAccount="account" UserID="3db01e67-abb0-4946-8fa8-85943768cb79">

The next step is iterating through the user profile fields to check if the value ‘IsDirty’ aka the value has been changed. This is the only trigger to actually update a user profile.
When adjusting the user subtype from the UI a few properties are updated, even when they’re not changed. The final XML looks like the following:

<?xml version="1.0" encoding="utf-16"?>
<MSPROFILE>
 <PROFILE ProfileName="UserProfile">
 <USER NewUser="0" NTAccount="account" UserID="3db01e67-abb0-4946-8fa8-85943768cb79">
 <PROPERTY PropertyName="Assistant" Privacy="1" PropertyValue="" />
 <PROPERTY PropertyName="PictureURL" Privacy="1" PropertyValue="" />
 <PROPERTY PropertyName="SPS-TimeZone" Privacy="1" PropertyValue="" />
 </USER>
 </PROFILE>
</MSPROFILE>

and a real update of the user profile occurred.

To make the update work from code appearently another property has to be updated together with the change of subtype. After a test with an update of a random property, the user subtype was updated too.

Summary

Changing only the user subtype from code, does trigger the Commit() method, but doesn’t call the update profile, because no user profile property was changed. Use a dummy property to update every time the user subtype has changed.

1. In Central Administration select ‘Manage service applications’
2. Select the Search Service Application
3. Select ‘Metadata properties’
4. Select ‘Categories’
5. Edit the category of your choice
6. Select ‘Delete all unmapped crawled properties’
7. Select ‘Ok’

First thing to notice here: it deletes only unmapped crawled properties. So if your crawled property is still mapped, remove this first.

Second thing: make sure the crawled property isn’t included in the index!

First there are two crawled properties in the SharePoint category (well, there are more, I selected two to see the difference…) :

One is included in the index, the other isn’t.
Next step is to clear the SharePoint category by following all the steps above. The result:

The crawled property included in the index is still present! Even if a full index reset has been performed and the category has been cleaned up, the crawled properties doesn’t get deleted when ‘Included in index’ is set to ‘Yes’.

Summary

Besides unmapping a crawled property, deselect ‘Included in index’ in the crawled property’s properties to delete a crawled property.

This is a valid and working solution for the most of the crawled properties and certainly your custom ones.

When you’re going to test this youself, you’ll notice some of the OOTB unmapped and not include in the index crawled properties will still be present after performing the steps above. This is the case because SharePoint uses some hidden managed properties which are mapped to these crawled properties. Steve Curran explains this in his post which was written for MOSS 2007, but the same principle is still valid for SharePoint 2010:

In table MSSCrawledProperties ows_BaseName can be found with CrawledPropertyId 192.
In table MSSSchemaPropertyMappings CrawledPropertyId 192 is mapped to PID 2147418032.
In table MSSManagedProperties PID 2147418032 is mapped to property TempTitle with ‘Hidden’ and ‘NoDelete’ set to 1:

At first they both seemed to do the job, but there are some differences.
Let’s do a test with a simple array of items and loop through it using both foreach methods. To measure the time elapsed to loop the array the Measure-Command is used.

$items = 1,2,3,4,5,6,7,8,9,0,10,12,13,14,15,52,58,41,59,841,5,4,1

Write-Host "ForEach-Object: "
(Measure-Command {  `
 $items | ForEach-Object { `
  "Item: $_" `
 }}).totalmilliseconds

Write-Host "Foreach: "
(Measure-Command {  `
 Foreach ($item in $items) { `
  "Item: $element" `
 }}).totalmilliseconds

Multiple results:

The results differ a lot!

When to use which method?

When the items of the array are known at forehand, like in the test, foreach is the better approach because of the speed. This kind of speed can only be reached when all the objects are already known and stored in a variable.

ForEach-Object is a different story. When the items have to be collected before the loop starts and this can take a while: use ForEach-Object.
This method processes the objects collected in the array directly when available and doesn’t wait until all objects are collected.

There are different ways of encoding and decoding querystring parameters, for example by using SPHttpUtility or HttpUtility.
While programming SharePoint I always tend to use the SPHttpUtility class, but I didn’t know exactly why. Until I accidentally used the HttpUtility and SPHttpUtility at the same time: I noticed some differences.  

Encode

SharePoint has a Utilities namespace, Microsoft.SharePoint.Utilities, which provides the SPHttpUtility class. One of the methods in this class is UrlKeyValueEncode with several overloads.
The description of the method 

UrlKeyValueEncode(string keyOrValueToEncode)

is ‘Encodes the specified URL query string key or value’. 

The HttpUtility class in the namespace System.Web contains a method UrlEnode, also with overloads. The description of

UrlEncode(string str)

is ‘Encodes a URL string’.
The HttpUtility class doesn’t have a method to encode a query string key or value as UrlKeyValueEncode, but this is the best match.  

Let’s encode a space:
The result while encoding with HttpUtility is ‘+’, encoding with SPHttpUtility results in a ‘%20′.

One of the major differences is the casing of the encoded characters. SPHttpUtility encodes the characters uppercase, HttpUtility lowercase.
Another difference can be seen in the picture below: HttpUtility doesn’t encode all characters, SPHttpUtility does:  

  

Decode

To decode characters the SPHttpUtility class provides the method

UrlKeyValueDecode(string keyOrValueToDecode)

The couterpart of the UrlEncode method in the HttpUtility class is

UrlDecode(string str)

While encoding results in different outcome, decoding doesn’t.
As can be seen in the picture of the encoded characters above, HttpUtility doesn’t encode e.g. ‘(‘, ‘!’, ‘*’. When decoding these (unencoded) characters with SPHttpUtility the results stay ‘(‘, ‘!’, ‘*’. Check the pictures below.
Encoded with HttpUtility, decoded these characters:  

SPHttpUtility encodes characters ‘(‘, ‘!’ and ‘*’ as ‘%28′, ‘%21′ and ‘%2A’. When decoding these characters with SPHttpUtility, but also with HttpUtility, the results are the same:  

  

Summary

Since decoding gives the same results with SPHttpUtility and HttpUtility, why bother the encoding method?  

Well, something inside me tells me SharePoint is using it somewhere internally. I didn’t figure out where, but why is the SPHttpUtility implemented if SharePoint easily could use HttpUtility?
Besides some feelings, the SPHttpUtility doesn’t use HttpUtility internally. When checking out the SPHttpUtility.UrlKeyValueEncode with ILSpy, the encoded values, uppercase(!), are listed is the readonly string array s_crgstrUrlHexValue.

  

Wikipedia has a definition of percent encoding (http://en.wikipedia.org/wiki/Percent-encoding) :
‘Percent-encoding, also known as URL encoding, is a mechanism for encoding information in a Uniform Resource Identifier (URI) under certain circumstances’  

According to this article reserved characters (Reserved characters are those characters that sometimes have special meaning) must be encoded…
According to RFC 3986 reserved characters are:

And encoded:
  

So HttpUtility doesn’t encode the first five characters, SPHttpUtility encodes all reserved characters.  

To be compatible with 3986 standard it seems SPHttpUtility is the best option to use.

To create a version of a document set the action Capture Version in this part of the ribbon has to be selected. When selecting the following screen will be shown:

To use versioning of a document set (and items) versioning has to be enabled on the library.    

After selecting a version option (when major/minor enabled), adding some comment and selecting the Ok button a document set version is created. To view the versions of the document set the action Version History can be selected in the ribbon.

In this screen the first column displayed is No. This is not the regular version column of the library, but a totally different one. When creating a document set version the version column of the library doesn’t change, only the No value.    

That’s nice, but where is the version of the document set actually stored?    

The version(s) of a document set are stored in the propertybag of the item itself.    

To analyze settings I always start up PowerShell first to check on things. Just because it’s quick and easy. When I get what I want from PowerShell it’s easily turned into C# code. I followed the same procedure to get to the storage of document set versions. Since I couldn’t find the version anywhere in the UI, my first guess was checking the propertybag keys.    

$site=Get-SPSite "http://sp2010dev"
$docList = $site.RootWeb.Lists.TryGetList("Documents");
$item = $docList.Items.GetItemById(2)
$prop = $item.Properties

Often I use PowerGui Script Editor which gives an excellent overview of variables:    

The keys:

And the values:

While scrolling through the property keys I noticed a key named snapshots. By checking out the value of that key I knew I found it!    

The following PowerShell command can be used to get the value of the snapshot key:    

$item.Properties.get_Item("snapshots")

The version history is stored in xml:    

<SnapshotCollection NextSnapshotNumber="3" NextInternalId="1">
  <Items />
  <Snapshots>
    <Snapshot Label="2" Major="True" Created="08/21/2011 07:50:56" By="username">
      <Comments>Another version of the document set.</Comments>
      <Fields>
        <Field Id="8553196d-ec8d-4564-9861-3dbe931050c8">Document set name</Field>
        <Field Id="fa564e0f-0c70-4ab9-b863-0177e6ddd247">Document set name</Field>
        <Field Id="cbb92da4-fd46-4c7d-af6c-3128c2a5576e">Add a description here.</Field>
      </Fields>
      <SnapshotItems />
    </Snapshot>
    <Snapshot Label="1" Major="True" Created="08/21/2011 07:50:20" By="username">
      <Comments>This is the first version of this document set.</Comments>
      <Fields>
        <Field Id="8553196d-ec8d-4564-9861-3dbe931050c8">Document set name</Field>
        <Field Id="fa564e0f-0c70-4ab9-b863-0177e6ddd247">Document set name</Field>
        <Field Id="cbb92da4-fd46-4c7d-af6c-3128c2a5576e" />
      </Fields>
      <SnapshotItems />
    </Snapshot>
  </Snapshots>
</SnapshotCollection>

   

The Snapshot element with Label attribute 1 is the first version. The comment is displayed and the fields and values of the document set.    

The Snapshot element with Label attribute 2 is the second version. The same items are displayed with the addition of the value of the description ‘Add a description here’. That’s what I changed before creating the second version.    

The attribute NextSnapshotNumber holds the value of the version number that will be created when creating another version, 3 in this case.    

Summary  

Document set versions are different than regular item versions. The version history of a document set is stored in the propertybag of the document set itself as xml.

What do these two do?
Write-Host: Writes customized output to a host
Write-Output: Sends the specified objects to the next command in the pipeline. If the command is the last command in the pipeline, the objects are displayed in the console 

An example of Write-Host

Write-Host "Write-Host statement..."

The result displayed in the host 

 

An example of Write-Output

Write-Output "Write-Output statement..."

The result displayed in the host

 

At this point there is no difference in the result of these two statements. 

Write-Host with ForegroundColor 

A nice parameter of Write-Host is -ForegroundColor. Using this parameter with a color, the text displayed in the host has the color specified. I find this very useful to quickly see if a script has succeeded or failed. I always display the success message in green, the failed message in red.   

To show this the existence of a SPList will be checked. If it doesn´t exist, it will be created using the following statement:   

$sampleListName = "PS List"
$siteUrl=http://sp2010dev
$site = Get-SPSite $siteUrl
$web = $site.RootWeb</pre>

function CreateList($listName){
  $web.Lists.Add($listName, "Description for list", [Microsoft.SharePoint.SPListTemplateType]::GenericList)
}

function CheckIfListExists(){
$currentList = $web.Lists.TryGetList($sampleListName)
  if($currentList -ne $null){
    Write-Host "List exists" -ForegroundColor Green
  }
  else{
    Write-Host "List doesn't exist, creating now..." -ForegroundColor Red
    CreateList $sampleListName
    Write-Host "Check if list exist..."
    CheckIfListExists
  }
}

Write-Host "Calling CheckIfListExists ..."
CheckIfListExists

If the list exists a message with green colored text will appear: ‘List exists’, else a message with red colored text will appear: ‘List doesn’t exist, creating now…’, followed by the actual creation of the list. After this the existence of the list is check again. As you can see if the list creation fails the code will be stuck in an infinite loop, so don´t use this as production code…   

Outcome when the list doesn´t exist and is created:

Outcome when the list already exists:<picture PSWrite02>

Write-Output with output to file   

A nice option of Write-Output is the possibility to write the output to a file on the filesystem.   

$file = "C:\_Tools\OutputFile.txt"
Write-Output "Write-Output statement..."
Write-Output "Write-Output statement..." | Out-File $file

The first Write-Output statement writes the output to the host, the second to the file (but not to the host).   

Best of both worlds?   

Ofcourse Write-Host as well as Write-Output has a lot more options to use, but I want to point out something here.
Write-Host can write colored messages to the host, but it can’t write output to a file.
Write-Output can’t write colored messages to the host, but it can write output to a file.   

What if I want to:   

write colored messages to the host if I decide to output to the host AND
write messages to a file just by using ‘| Out-File $file’

With the current possibilities of both operations I have to choose between:
1. colored messages (and nothing written to the output file) or put the output to a file and host, but no colored messages displayed in the hostÂ
2. write double statements; Write-Host with -ForeGroundColor to write the colored output to the host and Write-Output to write the output to a file when using ‘| Out-File $file’.   

Let me clarify the second option with an example.

Write-Output "Write-Output statement..." | Out-File $file
Write-Host "Write-Host statement..." -ForegroundColor Blue

Write-Output writes the message to the file specified in $file and is not written to the host.
Write-Host writes the message to the host in the color blue.
Just as expected and just want I wanted. But I have to write the messages twice.

Another option:   

Write-Output "Write-Output statement..."
Write-Host "Write-Host statement..." -ForegroundColor Blue

The code above is saved in a file and called by:   

PS C:\_Tools> .\PSScriptFile.ps1

Result: messages appear twice in the host.

Output it to a file:   

PS C:\_Tools> .\PSScriptFile.ps1 | Out-File $file

Result: No message in the host, but a message in the file!
Still, the messages have to be written twice in the file: Write-Host and Write-Output…
Do I really have to write all the messages twice to show them colored in the host and write them to an output file?
Actually, there is no possibility to make Write-Host write to an output file.
But the host itself can be accessed to change its text color (and more) and use Write-Output to write to the host (in color!) and to an output file.

The host itself can be accessed by $Host.   

$Host.Name

When using PowerGUI Script Editor the results of the above statement is: PowerGUIScriptEditorHost
Executing the same statement in the console the result is: ConsoleHost

That’s awesome, $Host knows who he is!

Let’s try to get the text color of the host:

$currentColor = $Host.UI.RawUI.ForegroundColor

PowerGUI Script Editor:

Console:

So what about changing the text color of the host?   

function WriteCustomOutput($message, [System.ConsoleColor]$foregroundcolor)
{
  currentColor = $Host.UI.RawUI.ForegroundColor
  $Host.UI.RawUI.ForegroundColor = $foregroundcolor
  if ($message)
  {
    Write-Output $message
  }
  $Host.UI.RawUI.ForegroundColor = $currentColor
}

WriteCustomOutput -message "WriteColoredOutput statement..." -foregroundcolor Green

And the result in the host:

   

Let’s save the code to a file and call the file from the console:

 

And will the output be written to an output file when using the statement:

.\PSWriteCustomOutput.ps1 | Out-File OutputFile.txt

Yes it is written to the file:

   

Summary

Write-Host and Write-Output are very simple and useful statements. Sometimes the best of both is wished for.
With some creativity you can have both. Use WriteCustomOutput!