Serge van den Oever [Macaw] : PowerShell

PowerShell: Return values from a function through reference parameters

svdoever — Thu, 26 Mar 2009 09:41:00 GMT

PowerShell has a special [ref] keyword to specify which parameters are used in a fuction to return values. It's usage is not directly clear however.

If the type of the variable to update is a value type, use the [ref] keyword in the declaration of the function parameter, this specifies that a "pointer" to the variable will be passed.

To pass the "pointer" to the variable, use ([ref]$variable) to create the pointer, and pass this as parameter. To set the value of the value variable pointed to by the "pointer", use the .Value field.

Simple example to show what [ref] does:

C:\Program Files\PowerGUI> $zz = "hoi"
C:\Program Files\PowerGUI> $xz = [ref]$zz
C:\Program Files\PowerGUI> $xz
Value
-----
hoi

C:\Program Files\PowerGUI> $xz.Value = "dag"
C:\Program Files\PowerGUI> $zz
dag

This is only required for value types, not is the type is a referece type like for example Hashtable.

Some sample code:

function fn
{
param
(
[ref]$arg1,
[ref]$arg2,
$arg3
)

$arg1.Value = 1
$arg2.Value = "overwrite"
$arg3.key = "overwrite hash value"
}

$x = 0
$y = "original"
$z = @{"key" = "original hashvalue"}
$x
$y
$z.key
fn -arg1 ([ref]$x) -arg2 ([ref]$y) -arg3 $z
$x
$y
$z.key

Documenting PowerShell script code

svdoever — Sun, 08 Feb 2009 23:17:00 GMT

The Macaw Solutions Factory contains a lot of PowerShell script code. A lot of the code is documented, but it is not documented in a consistent way because there were no documentation standards available for PowerShell 1.0, we only had the very complex XML based MAML documentation standard that was not useable for inline documentation.

With the (upcoming) introduction of PowerShell 2.0, a new more readable documentation standard for PowerShell code is introduced. I did not find any formal documentation on it, only examples on the PowerShell team blog. There is even a script to create a weblog post out of a script containing this documentation format. See http://blogs.msdn.com/powershell/archive/tags/Write-CommandBlogPost/default.aspx for this script and an example of the documentation format.

The new documentation format uses a PowerShell 2.0 feature for multi-line comments:

<#
:
\#>

Because this is not supported in PowerShell 1.0 , we will write the documentation as follows to remain compatible:

\#<#
\#:
\##>

This will allows us to change the documentation by removing the superfluous # characters when the code-base is moved over to PowerShell 2.0 when it is released.

Documenting PowerShell scripts

Scripts can be provided with documentation in the following format:

#<#
#.Synopsis
#	Short description of the purpose of this script
#.Description
#	Extensive description of the script
#.Parameter X
#    Description or parameter X
#.Parameter Y
#    Description or parameter Y
#.Example
#	First example of usage of the script
#.Example
#	Second example of usage of the script
##>
param
(
	X,
	Y
)
:

function MyFunction
{
	#<#
	#.Synopsis
	#	Short description of the purpose of this function
	#.Description
	#	Extensive description of the function
	#.Parameter X
	#    Description or parameter X
	#.Parameter Y
	#    Description or parameter Y
	#.Example
	#	First example of usage of the function
	#.Example
	#	Second example of usage of the function
	##>
	param
	(
		X,
		Y
	)
	:
}

:

Automatically generating documentation

The next step is to automatically generate documentation on all our scripts based on the new documentation format.

The best approach will possibly be to use PowerShell 2.0 to actually generate the documentation, because using PowerShell 2.0 we can parse PowerShell code. We can easily determine the functions and their parameters.

A nice project for the future.

Powershell output capturing and text wrapping: strange quirks... solved!

svdoever — Tue, 09 Dec 2008 22:21:30 GMT

Summary

To capture (transcript) all output of a Powershell script, and control the way textwrapping is done, use the following approach from for exmaple a batch file or your Powershell code:

PowerShell -Command "`$host.UI.RawUI.BufferSize = new-object System.Management.Automation.Host.Size(512,50); `"c:\temp\testoutputandcapture.ps1`" -argument `"A value`"" >c:\temp\out.txt 2>&1

Note the '`' (backtick characters).

The problem: output capture and text wrap

Powershell is a great language, but I have been fighting and fighting with Powershell on two topics:

to capture the output
to get it output text in the max width that I want without unexpected wrapping

After reading the manuals you would think that the PowerShell transcripting possibilities are your stairways to heaven. You just start capturing output as follows:

start-transcript "c:\temp\transcript.txt"
do your thing
stop-transcript

Try this with the following sample file c:\temp\testoutputandcapture.ps1:

Start-Transcript "c:\temp\transcript.txt"
function Output
{
    Write-Host "Write-Host"
    Write-Output "Write-Output"
    cmd.exe /c "echo Long long long long long long long long yes very long output from external command"
    PowerShell -Command "Write-Error 'error string'"
}
Output
Stop-Transcript

When you execute this script you get the following output:

PS C:\temp> C:\temp\testoutputandcapture.ps1
Transcript started, output file is c:\temp\transcript.txt
Write-Host
Write-Output
Long long long long long long long long yes very long output from external command
Write-Error 'error string' : error string
Transcript stopped, output file is C:\temp\transcript.txt

If we now look at the generated transcript file c:\temp\transcript.txt:

**********************
Windows PowerShell Transcript Start
Start time: 20081209001108
Username  : VS-D-SVDOMOSS-1\Administrator 
Machine	  : VS-D-SVDOMOSS-1 (Microsoft Windows NT 5.2.3790 Service Pack 2) 
**********************
Transcript started, output file is c:\temp\transcript.txt
Write-Host
Write-Output
**********************
Windows PowerShell Transcript End
End time: 20081209001108
**********************

The output from the external command (the texts Long long long long long long long long yes very long output from external command and Write-Error 'error string' : error string) is not captured!!!

Step one: piping output of external commands

This can be solved by appending | Write-Output to external commands:

Start-Transcript 'c:\temp\transcript.txt'
function Output
{
    Write-Host "Write-Host"
    Write-Output "Write-Output"
    cmd.exe /c "echo Long long long long long long long long yes very long output from external command" | Write-Output
    PowerShell -Command "Write-Error 'error string'" | Write-Output
}
Output
Stop-Transcript

This will result in the following output:

PS C:\temp> C:\temp\testoutputandcapture.ps1
Transcript started, output file is c:\temp\transcript.txt
Write-Host
Write-Output
Long long long long long long long long yes very long output from external command
Write-Error 'error string' : error string
Transcript stopped, output file is C:\temp\transcript.txt

Note that the error string Write-Error 'error string' : error string is not in red anymore.

The resulting transcript file c:\temp\transcript.txt now looks like:

**********************
Windows PowerShell Transcript Start
Start time: 20081209220137
Username  : VS-D-SVDOMOSS-1\Administrator 
Machine	  : VS-D-SVDOMOSS-1 (Microsoft Windows NT 5.2.3790 Service Pack 2) 
**********************
Transcript started, output file is c:\temp\transcript.txt
Write-Host
Write-Output
Long long long long long long long long yes very long output from external command
Write-Error 'error string' : error string
**********************
Windows PowerShell Transcript End
End time: 20081209220139
**********************

This is what we want in the transcript file, everything is captured, but we need to put | Write-Output after every external command. This is way to cumbersome if you have large scripts. For example in our situation there is a BuildAndPackageAll.ps1 script that includes a lot of files and cosists in totla of thousands of lines of Powershell code. There must be a better way...

Transcripting sucks, redirection?

Ok, so transcript just does not do the job of capturing all output. Lets look at another method: good old redirection.

We go back to our initial version of the script, and do c:\temp\testoutputandcapture.ps1 > c:\temp\out.txt. This results in a c:\temp\out.txt file with the following contents:

Transcript started, output file is c:\temp\transcript.txt
Write-Output
Long long long long long long long long yes very long output from external command
Write-Error 'error string' : error string
Transcript stopped, output file is C:\temp\transcript.txt

We are missing the Write-Host output! Actually, the Write-Host is the only line ending up in the transcript file;-)

This is not good enough, so another try, but now using the Powershell command-line host on the little modified script c:\temp\testoutputandcapture.ps1 that will showcase our next problem:

function Output
{
    Write-Host "Write-Host"
    Write-Output "Write-Output Long long long long long long long long yes very long output from Write-Output"
    cmd.exe /c "echo Long long long long long long long long yes very long output from external command"
    PowerShell -Command "Write-Error 'error string'"
}
Output

We now do: Powershell -Command "c:\temp\testoutputandcapture.ps1" > c:\temp\out.txt 2>&1 (2>&1 means: redirect stderr to stdout). We capture stderr as well, you never know where it is good for. This results in:

Write-Host
Write-Output Long long long long long long long l
ong yes very long output from Write-Output
Long long long long long long long long yes very long output from external command
Write-Error 'error string' : error string

I hate automatic text wrapping

As you may notice some strange things happen here:

A long output line generated by PowerShell code is wrapped (at 50 characters in the above case)
A long line generated by an external command, called from Powershell is not truncated

The reason the Powershell output is wrapped at 50 characters is because the dos box I started the command from is set to 50 characters wide. I did this on purpose to proof a case. Ok, so you can set your console window really wide, so no truncation is done? True. But you are not always in control of that. For example if you call your Powershell script from a batch file which is executed through Windows Explorer or through an external application like in my case CruiseControl.Net where I may provide an external command.

Powershell -PSConfigFile?... no way!

I hoped the solution would be in an extra parameter to the Powershell command-line host: -PSConfigFile. You can specify a Powershell console configuration XML file here that you can generate with the command Export-Console ConsoleConfiguration. This results in the ConsoleConfiguration.psc1 XML file:

<?xml version="1.0" encoding="utf-8"?>
<PSConsoleFile ConsoleSchemaVersion="1.0">
  <PSVersion>1.0</PSVersion>
  <PSSnapIns />
</PSConsoleFile>

I searched and searched for documentation on extra configuration like console width or something, but documentation on this is really sparse. So I fired up good old Reflector. After some drilling I ended up with the following code for the Export-Console command:

internal static void WriteToFile(MshConsoleInfo consoleInfo, string path)
{
    using (tracer.TraceMethod())
    {
        _mshsnapinTracer.WriteLine("Saving console info to file {0}.", new object[] { path });        
         XmlWriterSettings settings = new XmlWriterSettings();
        settings.Indent = true;
        settings.Encoding = Encoding.UTF8;
        using (XmlWriter writer = XmlWriter.Create(path, settings))
        {
            writer.WriteStartDocument();
            writer.WriteStartElement("PSConsoleFile");
            writer.WriteAttributeString("ConsoleSchemaVersion", "1.0");
            writer.WriteStartElement("PSVersion");
            writer.WriteString(consoleInfo.PSVersion.ToString());
            writer.WriteEndElement();
            writer.WriteStartElement("PSSnapIns");
            foreach (PSSnapInInfo info in consoleInfo.ExternalPSSnapIns)
            {
                writer.WriteStartElement("PSSnapIn");
                writer.WriteAttributeString("Name", info.Name);
                writer.WriteEndElement();
            }
            writer.WriteEndElement();
            writer.WriteEndElement();
            writer.WriteEndDocument();
            writer.Close();
        }
        _mshsnapinTracer.WriteLine("Saving console info succeeded.", new object[0]);    }
}

So the XML that we already saw is all there is... a missed chance there.

A custom command-line PowerShell host?

I have written a few Powershell hosts already, for example one hosted into Visual Studio, and there I encountered the same wrapping issue which I solved by the following implementation of the PSHostRawUserInterface:

using System;
using System.Management.Automation.Host;

namespace Macaw.SolutionsFactory.DotNet3.IntegratedUI.Business.Components.Powershell
{
    /// <summary>
    /// Implementation of PSHostRawUserInterface.
    /// </summary>
    public class PowershellHostRawUI : PSHostRawUserInterface
    {
        :

        public override Size BufferSize
        {
            get
            {   
                // The width is the width of the output, make it very wide!
                return new Size(512,1);
            }
            set
            {
                throw new Exception("BufferSize - set: The method or operation is not implemented.");
            }
        }

        :
    }
}

I solved transcripting in my own Powershell hosts by capturing all text output done by Powershell through custom implemented functions for the PSHostUserInterface you need to implement anyway, works like a breeze.

The solution, without custom host...

I was just getting started to solve the transcripting and wrapping issues by implementing again a Powershell host, but now a command-line Powershell host when I did one last digging step. What is you can set the BufferSize at runtime in your Powershell code. And the answer is.... yes you can! Through the $host Powershell variable: $host.UI.RawUI.BufferSize = new-object System.Management.Automation.Host.Size(512,50). This says that the output may be max 512 chars wide, the height may not be 1 (as in my code), bu this height value is not important in this case. It is used for paging in a interactive shell.

And this last statement gives us full control and solves all our transcripting and wrapping issues:

PowerShell -Command "`$host.UI.RawUI.BufferSize = new-object System.Management.Automation.Host.Size(512,50); `"c:\temp\testoutputandcapture.ps1`" -argument `"A value`"" >c:\temp\out.txt 2>&1

And this concludes a long journey into the transcripting and wrapping caves of Powershell. I hope this will save you the days of searching we had to put into it to tame the great but naughty Powershell beast.

Powershell: Generate simple XML from text, useful for CruiseControl.Net merge files

svdoever — Mon, 08 Dec 2008 00:34:17 GMT

I had the problem that I need to include ordinary text files into the CruiseControl.Net build output log file. This log file is a merge of multiple files in xml format. So I needed to get some text files into a simple xml format. I ended up with the following Powershell code to convert an input text file to a simple output xml file

Powershell code:

function Convert-XmlString
{
    param
    (
        [string]$text
    )
    # Escape Xml markup characters (http://www.w3.org/TR/2006/REC-xml-20060816/#syntax)
    $text.replace('&', '&').replace("'", ''').replace('"', '"').replace('<', '<').replace('>', '>')
}

function Convert-TextToXml
{
    param
    (
        $rootNode = 'root',
        $node = 'node',
        $path = $(Throw 'Missing argument: path'),
        $destination = $(Throw 'Missing argument: destination')
    )
    Get-Content -Path $path | ForEach-Object `
        -Begin {
            Write-Output "<$rootNode>"
        } `
        -Process {
            Write-Output " <$node>$(Convert-XmlString -text $_)</$node>"
        } `
        -End {
            Write-Output "</$rootNode>"
        } | Set-Content -Path $destination -Force
}

You can call this code as follows:

Convert-TextToXml -rootNode 'BuildAndPackageAll' -node 'message' -path 'c:\temp\in.txt' -destination 'c:\temp\out.xml'

where the file c:\temp\in.txt:

This is line 1
This is a line with the characters <, >, &, ' and "
This is line 3

Will be converted the the file c:\temp\out.xml:

<BuildAndPackageAll>
<message>This is line 1</message>
<message>This is a line with the characters <, >, &, ' and "</message>
<message>This is line 3</message>
</BuildAndPackageAll>

Post to self: getting the directory where the CLR is installed in PowerShell

svdoever — Fri, 08 Aug 2008 08:55:25 GMT

[System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()

will return a path like: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\

C:\Program Files\Reference Assemblies for assemblies to reference in your code

svdoever — Sun, 20 Jul 2008 20:35:01 GMT

I just stumbles across a "new" concept of Microsoft. In the C:\Program Files\Reference Assemblies folder Microsoft installs assemblies for products that can be referenced from your code. Instead of referencing assemblies directly from the GAC or copying an assembly from an installation folder or the GAC to your project for reference, you can now reference the assemblies in this folder.

We have a similar approach in our Macaw Solutions Factory where we have a _SharedAssemblies folder to keep track of all external assemblies to reference. We prefer to keep the assemblies with the source that is checked into source control, because otherwise it is possible that a build server does not contain the expected assemblies when compiling a checked-out solution and can't successfully compile the solution.

On the MsBuild team blog you can read more about this feature that happened to be with us since the .Net 3.0 framework:

http://blogs.msdn.com/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx

Also other applications like PowerShell keep their assemblies to reference in this location.

Edit file in Wss3 web application with SharePoint Designer blows up your web site

svdoever — Tue, 29 Jan 2008 10:21:02 GMT

I wanted to create a simple html file in the root of my Wss3 web application, so I created an empty file test.htm. I double clicked te file and because I have SharePoint Designer installed, it is the default editor for .htm files. I put some test into the .htm file along the lines of "Hello world!", and boom: my Wss3 web application is dead. I get the following error:

Server Error in '/' Application.

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Data at the root level is invalid. Line 1, position 1.
Source Error:

Line 1:  <browsers>
Line 2:      <browser id="Safari2" parentID="Safari1Plus">
Line 3:          <controlAdapters>

Source File: /App_Browsers/compat.browser Line: 1

Version Information: Microsoft .NET Framework Version:2.0.50727.832; ASP.NET Version:2.0.50727.832

After some searching I found what happened:

When you open a file with SharePoint Designer, it creates all kind of FrontPage Server Extension functionality in your web application. One thing it does it that it creates a _vti_cnf folder in every folder you have in your web application. If you remove all these folders you fix your problem.

I don't know of a handy DOS command to delete all these folders recursively, but with some PowerShell I solved the problem.

Open a PowerShell prompt, set the current directory to the folder hosting your web application and execute the following command to see the "damage":

PS C:\Inetpub\wwwroot\wss\VirtualDirectories\wss3dev> get-childitem -path . -name _vti_cnf -recurse
_vti_cnf
App_Browsers\_vti_cnf
App_GlobalResources\_vti_cnf
aspnet_client\system_web\2_0_50727\CrystalReportWebFormViewer3\CSs\_vti_cnf
aspnet_client\system_web\2_0_50727\CrystalReportWebFormViewer3\html\_vti_cnf
aspnet_client\system_web\2_0_50727\CrystalReportWebFormViewer3\Images\ToolBar\_vti_cnf
aspnet_client\system_web\2_0_50727\CrystalReportWebFormViewer3\Images\Tree\_vti_cnf
aspnet_client\system_web\2_0_50727\CrystalReportWebFormViewer3\JS\_vti_cnf
wpresources\_vti_cnf
_app_bin\_vti_cnf

Now execute the following PowerShell command to kill all these folders and become a happy camper again:

PS C:\Inetpub\wwwroot\wss\VirtualDirectories\wss3dev> get-childitem -path . -name _vti_cnf -recurse | % { remove-item -Path $_ -recurse }

SharePoint stsadm.exe and the infamous "Command line error"

svdoever — Sat, 22 Dec 2007 00:11:30 GMT

The SharePoint command-line utility stsadm.exe was driving me crazy for the last two days. I'm automating all kind of this from PowerShell scripts, but I got the error "Command line error" while I was absolutely sure that what I was doing was correct. I did stsadm.exe -o deletesolution foobar.wsp. And the problem was: character encoding...

First I thought it was a problem with the way I executed this command from PowerShell. When I copied over the command to a different script it worked. What!!!??? Then I copied it over to the cmd.exe shell on the command line and I got the same error.

I started searching on Google and came accross this blogpost. It said it had something to do with encoding. The blog post also pointed to this blog post where people responded in the contents with the most hillarious solutions like:

If I type STSADM.EXE it works, while STSADM.exe does not work, or that a solution file must be in the same folder as stsadm.exe. Read the comments, it is fun how far off people can get.

Another post mentioning the problem is this discussion thread.

The problem happened to be in the encoding. One way or the other it is possible to get different encodings while typing in the same command multiple times in the same cmd.exe shell. Don't ask me how.

If you have problems, type your text in an editor like Notepad++, and switch between "Encode in ANSI" and "Encode in UTF-8" (it is under the Format menu in Notepad++). You see (sometimes)the dash(-) in stsadm -o command... change from '-' to a strange little block... There is the problem. The dash is not always a dash, it is a hyphen... And stsadm then thinks that no command is specified. Remove the strange block, type a hyphen while is UTF-8 encoding, copy that and bingo!! It works.

Ok, how to repeat this:

Start Notepad++, set encoding to ANSI
Make sure the path to stsadm.exe is in your path environment variable (or use full path)
Type stsadm -o deletesolution foobar.wsp
Start cmd.exe
Copy the text over and press enter: voila, Command line error.

The strange thing is that even if you remove the dash (-), and type it again, it still gives errors. I have no clue why.

This dash/hypen thing is a common problem if you search Google, for more info see for example:

PowerShell Exception handling using "Trap" explained - links

svdoever — Thu, 22 Nov 2007 15:53:30 GMT

PowerShell has powerful exception handling, but it is badly documented and takes while to understand what the heck they actually want to do to wire up the exception handling.

I'm normally not such a link poster, this is more of a "post-to-self" item that might be useful for others as well.

See Trap [Exception] { “In PowerShell” } for a very good explantation
See PowerShell: Try...Catch...Finally Comes To Life for a Try/Catch/Finally implementation in PowerShell for the more c# oriented developers

Powershell: Is a SharePoint solution installed or deployed?

svdoever — Wed, 10 Oct 2007 18:39:23 GMT

I was having some fun with PowerShell to talks against the SharePoint object model. I needed to know if a SharePoint solution was installed and if it was deployed. I got to the code below. Might be handy for someone to see how easy it is to get info out of SharePoint.

And the purpose I need it for? In our Macaw Solutions Factory we have a development build and a package build. Development build for SharePoint deploys everything to the bin folder of one or more web applications. Package build creates a solution package (.wsp file) that does install assemblies to the GAC. If this solutions package is deployed on the development machine, we want to detect that, because you will not see any changes after compile in a development build. The GAC assemblies have precedence over the assemblies in the web application bin folder.

So here is the code, have fun with it.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint")

function global:Test-SharePointSolution
{
    param
    (
        $solutionName = $(throw 'Missing: solutionName'),
        [switch]$installed,
        [switch]$deployed
    )
    
    if (!($solutionName.EndsWith('.cab') -or $solutionName.EndsWith('.wsp') -or $solutionName.EndsWith('.wpp')))
    {
        throw "solution name '$solutionName' should end with .cab, .wsp or .wpp"
    }
    
    if ($installed -and $deployed)
    {
        throw "Select either the '-installed' switch parameter or the '-deployed' switch parameter, not both at the same time"
    }
    
    $farm = [Microsoft.SharePoint.Administration.SPFarm]::get_Local()
    $solutions = $farm.get_Solutions()
    $solutioncheck = $false
    foreach ($solution in $solutions)
    {
        if ($solution.Name -ieq $solutionName)
        {
            if ($deployed)
            {
                $solutioncheck = $solution.Deployed
            }
            else
            {
                # installed, is always true if we get here
                $solutioncheck = $true
            }
            break
        }
    }
    return $solutioncheck
}

Test-SharePointSolution -solutionName wikidiscussionsolution.wsp -installed
Test-SharePointSolution -solutionName wikidiscussionsolution.wsp -deployed

PowerShell: Creating a SharePoint solution package (WSP file) with CAS

svdoever — Wed, 10 Oct 2007 18:31:23 GMT

I need to add some code access security information to a SharePoint solution package manifest file. Given the assembly file we can retrieve the required assembly info, and with some xml magic in PowerShell create some result xml. It is not actually the exact code I use in my solution, but it shows the job...

# function: GetAssemblyInfo
# Arguments: $assemblyFile - path to assembly file to determine information from
# Returns: Hashtable with the following keys: PublicKeyBlob, Name, Version
function global:GetAssemblyInfo
{
    param
    (
       $assemblyFile = $(Throw'Missing: assemblyFile')
    )

   if (!(Test-Path -Path $assemblyFile))
    {
        Throw"Assembly file '$assemblyFile' does not exist"
    }

   # Secutil returns:
   #Line 0: Microsoft (R) .NET Framework SecUtil 2.0.50727.42
   #Line 1: Copyright (c) Microsoft Corporation. All rights reserved.
   #Line 2:
   #Line 3: Public Key =
   #Line 4: 0x00240000048000009400000006020000002400005253413100040000010001003BBC200DC39F9419851471C4AF65A91540C5904D72694CDE6DF63427FAD8D180630538338E557D90BA4F18A2EF6F44F3A53A5C7CFE625F4954D53B4FF9CF700226FDF13F04731EDED323B1821BA38C5F310231007E7AF862F497174A127BD42C0FA4FAFF1154910B48E177E090888A7745145ED4F4F7BB75D28D6616961A71E3
   #Line 5: Name =
   #Line 6: Macaw.Mast.Wss3.Templates.Presentation.WebAppUI
   #Line 7: Version =
   #Line 8: 1.0.0.0
   #Line 9: Success
   $secutilExe = 'C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\SecUtil.exe'

   $resultLines = (& $secutilExe -hex -s $assemblyFile)
   if ($resultLines[9]-ne 'Success')
    {
        Throw"secutil.exe can't determine assembly information from assembly file '$assemblyFile', secutil.exe command failed"
    }
    @{'PublicKeyBlob' = $resultLines[4];'Name' = $resultLines[6];'Version' = $resultLines[8] }
}

$assemblyFile = 'C:\Inetpub\wwwroot\wss\VirtualDirectories\1000\bin\Macaw.Mast.Wss3.Templates.Presentation.WebAppUI.dll'
$result = GetAssemblyInfo -assemblyFile $assemblyFile
$result

This will result in the following output:

We can now create out code access security information (in this case in a SharePoint solution package manifest.xml file with code similar to the following code:

$assemblyInfo = GetAssemblyInfo -assemblyFile $assemblyFile
$policyItem = @"
<PolicyItem>
    <PermissionSet class="NamedPermissionSet" version="1" Description="Macaw Solution Factory generated permissionSet" Name="$($assemblyInfo.Name)-PermissionSet">
        <IPermission class="WebPermission" version="1">
            <ConnectAccess>
                <URI uri="`$OriginHost`$" />
            </ConnectAccess>
        </IPermission>
        <IPermission class="SmtpPermission" version="1" Access="Connect" />
        <IPermission class="SharePointPermission" version="1" ObjectModel="True" />
        <IPermission class="PrintingPermission" version="1" Level="DefaultPrinting" />
        <IPermission class="FileIOPermission" version="1" Read="`$AppDir`$" Write="`$AppDir`$" Append="`$AppDir`$" PathDiscovery="`$AppDir`$" />
        <IPermission class="EnvironmentPermission" version="1" Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME" />
        <IPermission class="SqlClientPermission" version="1" Unrestricted="true" />
        <IPermission class="SecurityPermission" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration" />
        <IPermission class="DnsPermission" version="1" Unrestricted="true" />
        <IPermission class="WebPartPermission" version="1" Connections="True" />
        <IPermission class="AspNetHostingPermission" version="1" Level="Medium" />
        <IPermission class="IsolatedStorageFilePermission" version="1" Allowed="AssemblyIsolationByUser" UserQuota="9223372036854775807" />
    </PermissionSet>
<Assemblies>
	<Assembly Name="$($assemblyInfo.Name)" Version="$($assemblyInfo.Version)" PublicKeyBlob="$($assemblyInfo.PublicKeyBlob)" />
</Assemblies>
</PolicyItem>
"@

$xmltext = @"
<?xml version="1.0" encoding="utf-8"?>
<Solution DeploymentServerType="WebFrontEnd" SolutionId="2244989E-9DA9-4a5d-9767-0D8F387181B7" ResetWebServer="true">
    <CodeAccessSecurity>
    </CodeAccessSecurity>
</Solution>
"@

[xml]$xmlDoc = $xmltext
$xmlDoc.SelectSingleNode('/Solution/CodeAccessSecurity').set_InnerXml($policyItem)
$xmlDoc.get_InnerXml()

This will results in the following output:

In the production of a real SharePoint solution package a lot more is happening, but this showcases some of the PowerShell power you can use to get the job done.

PowerShell: get SharePoint Central Administration web application path

svdoever — Fri, 17 Aug 2007 11:58:33 GMT

One of those things that you find out, forget, and never find back. So its more a post to self;-)

[void][reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint")
[Microsoft.SharePoint.Administration.SPAdministrationWebApplication]::Local.IisSettings.get_Item(0).Path.FullName

Generate a list of GUID's

svdoever — Wed, 30 May 2007 23:07:36 GMT

Sometimes you just need a lot of GUID's while programming. Ofcourse you could use the Visual Studio GUID tool, bu that is a lot of work.

Open a PowerShell console, and paste in the following line to get a list of 100 guid's:

$i=100; while ($i-- -gt 0) { Write-Host ([System.Guid]::NewGuid()) }

Factories @ Macaw - the DotNed presentation of april 26, 2007

svdoever — Thu, 03 May 2007 22:08:12 GMT

On april 26, 2007 I gave a presentation at the Macaw headquarters in Schiphol-Rijk, The Netherlands on what we are doing with Software Factories at Macaw.

I promised the audience to publish some links to tools and information mentioned in the presentation. I can't upload the presentation itself because it was a real "look into the kitchen of..." session with information that we can't give away (yet). I promise to blog more on this in the future however.

Some initial posts on what we are working on:

Blog post by Vincent Hoogendoorn: Realizing the Software Factories Vision for a Microsoft Systems Integrator
Blog post by Maarten Sikkema: De race naar Software Factories (in Dutch)

Tools we are using to realize our software factory vision:

Visual studio SDK 4.0 - Contains the DSL tools and everything to create visual studio extensions
Guidance Automation Extensions - Runtime needed to run GAT guidance packages
Guidance Automation Toolkit - Visual studio extension for development of guidance packages
Clarius Software Factory Toolkit - Additional tooling for developing GAT packages
PowerShell - The glue language we use extensively in our Solutions Factory. I have written thousands of lines of code in PowerShell, it rocks!

I hope you all had an informative session and got some "food for thought" ob what you could do within your organization. If you would like to leave a comment on what your impression of the presentation, please do so as a comment to this blog post, or send me a direct e-mail at serge@macaw.nl!

Consistent naming of PowerShell Cmdlets

svdoever — Sun, 25 Mar 2007 20:05:28 GMT

PowerShell has some simple guidelines in naming cmdlets so consistence is achieved in cmdlet names.

Some quotes from this page describing Cmdlet Verb Names:

Windows PowerShell uses a verb-noun pair format for the names of cmdlets and their derived .NET classes. For example, the Get-Command cmdlet provided by Windows PowerShell is used to retrieve all commands registered in the Windows PowerShell shell. The verb part of the name identifies the action that the cmdlet performs. The noun part of the name identifies the entity on which the action is performed.

And

The following list provides guidelines to consider when creating a verb-noun pair:

When specifying the verb part of a name, it is strongly recommended to use one of the predefined verb names provided by Windows PowerShell. In doing so, you will ensure consistency between the cmdlets that you create, those provided by Windows PowerShell, and others.
To enforce consistency across cmdlets, do not use a synonym of an approved verb name.
Use only the present tense of a verb for a name. For example, use "get" instead of "getting".
Use a simple, singular noun in cmdlet naming. For example, use "Get-Record" instead of "Get-Records".

I wish I knew about this convention before writing loads of PowerShell code...