But I didn’t know you could profile a Silverlight app.

I didn’t until I started doing some digging online. Now, the Silverlight profiling story (at least from what I’ve seen/tried) is not near the easy of say Redgate ANTS Performance Profiler. However, it’s do-able. (And with this helper script – hopefully a little simpler?)

How can I profile a Silverlight Application?

I would recommend you read the following blog, which explains one way of doing it very well.

http://blogs.msdn.com/profiler/archive/2010/04/26/vs2010-silverlight-4-profiling.aspx

So… what’s this script for?

If you read the blog above, or have done this before, then you probably noticed that there was quite a series of commands you had to execute before you could wind up with a performance report.

I threw together a quick little PowerShell script in an attempt to automate smooth out the process.

Hot do I use it?

1. Download the script & save it somewhere. http://github.com/staxmanade/Scripts/blob/master/SilverlightProfiler.ps1
2. Open the PowerShell console. cd to the directory your xap/assemblies are stored.
   (EX: {myProject}\Bin\Debug\ )
3. Execute:
   {pathToScript}\SilverlightProfiler.ps1 -urlPath "{myProject}\Bin\Debug\TestPage.html"
4. When your done profiling press enter to signal that your done.
   Once complete, it will print the location your profiling report was saved. You can then open it with Visual Studio.

Couple of disclaimers.

• Some paths are hard-coded to my x86 machine.
• I had troubles running the built in visual studio .bat files (from powershell) that are supposed to set the environment variables. So I extracted out what vars I could find to make it work.
• I’m not a profiling expert – just hacked this together to get it to work for me.

I hope this is useful, and if you know of a better way, I’m always interested in hearing your feedback.

A typical way to load an assembly within PowerShell is to use the Assembly.LoadFrom(filePath)

# Powershell

[System.Reflection.Assembly]::LoadFrom($assemblyPath)

Except the problem with this (in my case) was it would lock the file for the lifespan of the PowerShell console instance. I didn’t want to have to close and re-open the PowerShell console every time I need to run a build so there had to be a work-around for this.

After searching the web for a solution, I couldn’t find anything that was “easy” and worth the effort to get it to work.

EX: One solution was to create a new AppDomain, do the necessary work and the close the AppDomain which would release the lock on the file.

I’ve never done this myself, and even thought there is example code out there to get this accomplished, it just seemed over the top for what I was trying to do, and back to my previous criteria it wasn’t “worth the effort to get it to work”

Then I remembered in a previous life I used an overload that took an array of bytes to load the an assembly.

[System.Reflection.Assembly]::Load($assemblyBytes)

After spiking it in PowerShell with the below test. I was quite happy with the solution, so I thought I’d throw it out there.

Just stream the assembly from disk into a byte array manually, and call assembly load from there.

Here’s my test case which shows that the file is not locked after it was loaded into the PowerShell runtime

$file = ".\Moq.dll"
$tempFileName = ".\Moq-Renamed.dll"

$fileStream = ([System.IO.FileInfo] (Get-Item $file)).OpenRead();
$assemblyBytes = new-object byte[] $fileStream.Length
$fileStream.Read($assemblyBytes, 0, $fileStream.Length);
$fileStream.Close();

$assemblyLoaded = [System.Reflection.Assembly]::Load($assemblyBytes);

# notice that we can move the file on disk after 
# it's loaded into the powershell runtime
Move-Item $file $tempFileName
Move-Item $tempFileName $file 

# and display the assembly information to show we still have it in memory
echo $assemblyLoaded

After that test passed, and the main reason I wanted to do this, I wrote the “get-assembly-version” PowerShell function.

function get-assembly-version() {
    param([string] $file)
    
    # load the assembly bytes quickly - as to not lock the file for too long
    $fileStream = ([System.IO.FileInfo] (Get-Item $file)).OpenRead()
    $assemblyBytes = new-object byte[] $fileStream.Length
    $fileStream.Read($assemblyBytes, 0, $fileStream.Length) | Out-Null #out null this because this function should only return the version & this call was outputting some garbage number
    $fileStream.Close()
    
    # return the version of the assembly
    [System.Reflection.Assembly]::Load($assemblyBytes).GetName().Version;
}

$version = get-assembly-version(".\Moq.dll")

echo "Loaded v$($version.Major).$($version.Minor).$($version.Build).$($version.Revision) version of $file"

UPDATE:

Martin commented below on a much better solution to the assembly version info problem. Amazing how complicated we can make things if we don’t know the path.

function get-assembly-version() {
    param([string] $file)
    
    $version = [System.Reflection.AssemblyName]::GetAssemblyName($file).Version;
    
    #format the version and output it...
    $version
}

FYI: I’m very new to PowerShell, so any suggestions on how I implemented the below are welcome…

Examples of end result ShouldLookLike()…

Step 1: Figure out how to write a C# style extension method in PowerShell.

I found a great blog post describing how to extend any PowerShell object to add extension methods. Extension Methods in Windows PowerShell

<?xml version="1.0" encoding="utf-16"?>
<Types>
    <Type>
        <Name>System.Object</Name>
        <Members>
            <ScriptMethod>
                <Name>ShouldBeFalse</Name>
                <Script>
                    [NUnit.Framework.Assert]::IsFalse($this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldBeTrue</Name>
                <Script>
                    [NUnit.Framework.Assert]::IsTrue($this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldEqual</Name>
                <Script>
                    [NUnit.Framework.Assert]::AreEqual($args[0], $this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldNotEqual</Name>
                <Script>
                    [NUnit.Framework.Assert]::AreNotEqual($args[0], $this)
                </Script>
            </ScriptMethod>
        </Members>
    </Type>
</Types>

NOTE: the file HAS to be saved with the extension .ps1xml Ex: NunitSpecificationPowerShellExtensions.ps1xml

Step 2: Load the extended type definition into the PowerShell runtime.

Update-TypeData -PrependPath NunitSpecificationPowerShellExtensions.ps1xml

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\NUnit 2.5.2\bin\net-2.0\framework\nunit.framework.dll") | Out-Null

#
# Update-TypeData -prependPath C:\Code\NunitSpecificationPowerShellExtensions.ps1xml
#

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\NUnit 2.5.2\bin\net-2.0\framework\nunit.framework.dll") | Out-Null

$true.ShouldBeTrue()

$false.ShouldBeFalse()

"a".ShouldEqual("a")

"a".ShouldNotEqual("b")

As a tester, I am constantly creating new environments, installing our product, taking snapshots, ect. Doing this by hand is a waste of time in my opinion. Doing this with a script makes life easier and frees up my time.

Typically, I prefer to create is to create one VM and to have other VMs inherit from that base image. My second VM (the first child to inherit from the base), I will install daily builds of our product. I will then create a third child, which I use a sandbox. I can easily delete it and recreate as needed without having to install our product over again. I have not consistently found success with using snapshots, so I prefer to use differencing disks. The examples below use differencing disks.

This first code block shows how I am using the PowerShell management library to simply the creation of a base VM. There is nothing magic about it. It’s pretty strait-forward. I create a VM, give it a name, set the CPU count, memory size, network adapters, hard drive, and DVD drive.

$server = "my-dev-server"
$vmName = "TestParentVM"
$vmVirtualSwitch = "My Virtual Network"

# create a new virtual machine
$vm = New-VM $vmName -server $server

# set cpu count
Set-VMCPUCount $vm 2 -server $server

# set memory size
Set-VMMemory $vm 2 -memory 4GB -server $server

# add a legacy network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch -legacy

# add a default VMBus (non-legacy) network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch

# add the hard drive to the VM
Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath "$(get-VHDdefaultPath)$vmName.vhd" -size 20GB

# add the DVD with bootup ISO
Add-VMDRIVE –vm $vm 1 1 -server $server -DVD 

Write-Host "Operation complete."

The next code block will create a differencing disk pointing to the parent created in the previous example. I create the usual, VM, CPU count, ect. What makes this a differencing disk is how the VHD is created by specifying the parent. I do some cleanup in this routine by deleting any previously created VMs or VHDs, and I loop through the creation a failure preventative.

$server = "my-dev-server"
$vmName = "TestChildVM"
$vmParent = "TestParentVM"
$vmVirtualSwitch = "My Virtual Network"

#region functions - feel free to move to a separate file

Function DeleteVhd
{
    Param ($pathToVhd)
    # delete the disk that was added if it exists
    if (test-path -path $pathToVhd)
    {
        Remove-Item -Path $pathToVhd -Force
    }
}

#endregion

# delete the VHD if it already exists
DeleteVhd "$(get-VHDdefaultPath)$vmName.vhd"

# delete the VM if it already exists
Remove-VM -vm $vmName -server $server

# create a new virtual machine
$vm = New-VM $vmName -server $server

# get the vm
$vm = Get-VM $vmName

# set cpu count
Set-VMCPUCount $vm 2 -server $server

# set memory size
Set-VMMemory $vm 2 -memory 4GB -server $server

# get VM Nics available
$vmNics = Get-VMNic -server $server -vmbus -legacy
$vmNicSwitchList = New-Object System.Collections.ArrayList

# get VM Nic Switch available for each VM Nic and add it to our list
foreach ($vmNic in $vmNics)
{
    $vmSwitchElementName = (Get-VMNicSwitch $vmNic).ElementName
    if ($vmNicSwitchList.Contains($vmSwitchElementName) -ne $true)
    {
        $vmNicSwitchList.Add($vmSwitchElementName)
    }
}

# Use the first available VM Nic Switch - this assumes 
# I do not create more than on per each environment.
if ($vmNicSwitchList.Count -gt 0)
{
    $vmVirtualSwitch = $vmNicSwitchList[0]
}

# add a legacy network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch -legacy

# add a default VMBus (non-legacy) network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch

# add the hard drive to the VM
$parent = "$(get-VHDdefaultPath)$vmParent.vhd"
$vhdPath = "$(get-VHDdefaultPath)$vmName.vhd"
Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath $vhdPath -parent $parent

# get the VM to see if a disk is attached to it, if it is not, then it failed
$disks = Get-VMDisk -vm $vm
$count = 1

# if the disk was not successfully added, try and add it again
while ($disks -eq $null -and $count -le 5)
{
    Write-Host "RETRY $count - The disk was not properly added. Attempting to retry."
    
    # delete the disk that was added
    DeleteVhd "$(get-VHDdefaultPath)$vmName.vhd"
    
    Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath $vhdPath -parent $parent
    
    $disks = Get-VMDisk -vm $vm
    $count++
}

if ($disks -eq $null)
{
    Write-Host "Operation failed to create this virtual machine. Contact an admin."
}
else
{
    Write-Host "Operation completed successfully. Attempting to start the VM."
    Start-VM -vm $vm -wait
}

I have found that the VM creation is not consistently successful on the first pass, so I have added the while loop. Since adding that, I have not had any issues.

I hope these help. They should be easy to change if you prefer snapshots versus differencing disks. Thanks to James O’Neill for creating this library. It makes administering Hyper-V much easier. It is available via CodePlex, where the latest release, updates, and forum support can be found.

This past weekend, I decided to upgrade my work laptop from Vista Enterprise to Windows 7 Ultimate Beta. I was unable to upgrade from Vista Enterprise to 7 Ultimate because that action is not supported. I then tried to upgrade from Enterprise to 7 Enterprise, but I was unable to upgrade from a staged build to a non-staged build. I decided to repave entirely, choosing Windows 7 Ultimate Beta, and I tried to do all of this on a Friday afternoon, two hours before leaving.

I installed Windows 7 Beta Checked Build (x86) - DVD (English), last updated on January 14, 2009,  from my MSDN subscription. I did not install an internal build. Instead, I decided to go with what is publicly available via MSDN.

Why did I go with a Checked Build? Because I failed to read the details describing it. What it cost me in time and frustration, I gain in valuable learning experiences. So it was not a total loss. I received a number of buggy issues with the checked build, mainly the inability for Windows Update to properly download all of my necessary updates, including my video drivers and smart card reader, where the latter enables me to remotely access my work domain.

I gave up and decided to download and install the Windows 7 Beta – DVD (English). Everything works great. I was able to get online, download all of my updates, and connect to my work domain. No issues found so far, and no annoying assertion error popups.

My favorite Windows 7 feature so far (non-UI related) is that PowerShell 2.0 is installed by default. PowerShell 2.0 provides more functionality for remoting, among other enhancements.

Get-Help Remove-Item -Full

As I was retrieving information on "Remove-Item," this is what I came across. There is more detail beyond what I am showing, but pay attention to what is bolded.

NAME
    Remove-Item

SYNOPSIS
    Deletes the specified items.

SYNTAX
    Remove-Item [-path] <string[]> [-recurse] [-force] [-include <string[]>] [-
    exclude <string[]>] [-filter <string>] [-credential <PSCredential>] [-whatI
    f] [-confirm] [<CommonParameters>]

    Remove-Item [-literalPath] <string[]> [-recurse] [-force] [-include <string
    []>] [-exclude <string[]>] [-filter <string>] [-credential <PSCredential>]
    [-whatIf] [-confirm] [<CommonParameters>]

DETAILED DESCRIPTION
    The Remove-Item cmdlet deletes one or more items. Because it is supported b
    y many providers, it can delete many different types of items, including fi
    les, directories, registry keys, variables, aliases, certificates, and func
    tions.

PARAMETERS
    -path <string[]>
        Specifies a path to the items being removed. Wildcards are permitted. T
        he parameter name ("-Path") is optional.

        Required?                    true
        Position?                    1
        Default value                N/A - The path must be specified
        Accept pipeline input?       true (ByValue, ByPropertyName)
        Accept wildcard characters?  true

    -recurse <SwitchParameter>
        Deletes the items in the specified locations and in all child items of
        the locations.

        The Recurse parameter in this cmdlet does not work properly.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       false
        Accept wildcard characters?  false

 

"Hmmm... Am I feeling lucky? Ahhh, what the hell, let's do it."

Remove-Item "C:\" -Recurse

As a tester, I am constantly creating new environments, installing our product, taking snapshots, ect. Doing this by hand is a waste of time in my opinion. Doing this with a script makes life easier and frees up my time.

Typically, I prefer to create is to create one VM and to have other VMs inherit from that base image. My second VM (the first child to inherit from the base), I will install daily builds of our product. I will then create a third child, which I use a sandbox. I can easily delete it and recreate as needed without having to install our product over again. I have not consistently found success with using snapshots, so I prefer to use differencing disks. The examples below use differencing disks.

This first code block shows how I am using the PowerShell management library to simply the creation of a base VM. There is nothing magic about it. It’s pretty strait-forward. I create a VM, give it a name, set the CPU count, memory size, network adapters, hard drive, and DVD drive.

$server = "my-dev-server"
$vmName = "TestParentVM"
$vmVirtualSwitch = "My Virtual Network"

# create a new virtual machine
$vm = New-VM $vmName -server $server

# set cpu count
Set-VMCPUCount $vm 2 -server $server

# set memory size
Set-VMMemory $vm 2 -memory 4GB -server $server

# add a legacy network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch -legacy

# add a default VMBus (non-legacy) network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch

# add the hard drive to the VM
Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath "$(get-VHDdefaultPath)\$vmName.vhd" -size 20GB

# add the DVD with bootup ISO
Add-VMDRIVE –vm $vm 1 1 -server $server -DVD 

Write-Host "Operation complete."

The next code block will create a differencing disk pointing to the parent created in the previous example. I create the usual, VM, CPU count, ect. What makes this a differencing disk is how the VHD is created by specifying the parent. I do some cleanup in this routine by deleting any previously created VMs or VHDs, and I loop through the creation a failure preventative.

$server = "my-dev-server"
$vmName = "TestChildVM"
$vmParent = "TestParentVM"
$vmVirtualSwitch = "My Virtual Network"

#region functions - feel free to move to a separate file

Function DeleteVhd
{
    Param ($pathToVhd)
    # delete the disk that was added if it exists
    if (test-path -path $pathToVhd)
    {
        Remove-Item -Path $pathToVhd -Force
    }
}

#endregion

# delete the VHD if it already exists
DeleteVhd "$(get-VHDdefaultPath)\$vmName.vhd"

# delete the VM if it already exists
Remove-VM -vm $vmName -server $server

# create a new virtual machine
$vm = New-VM $vmName -server $server

# get the vm
$vm = Get-VM $vmName

# set cpu count
Set-VMCPUCount $vm 2 -server $server

# set memory size
Set-VMMemory $vm 2 -memory 4GB -server $server

# get VM Nics available
$vmNics = Get-VMNic -server $server -vmbus -legacy
$vmNicSwitchList = New-Object System.Collections.ArrayList

# get VM Nic Switch available for each VM Nic and add it to our list
foreach ($vmNic in $vmNics)
{
    $vmSwitchElementName = (Get-VMNicSwitch $vmNic).ElementName
    if ($vmNicSwitchList.Contains($vmSwitchElementName) -ne $true)
    {
        $vmNicSwitchList.Add($vmSwitchElementName)
    }
}

# Use the first available VM Nic Switch - this assumes 
# I do not create more than on per each environment.
if ($vmNicSwitchList.Count -gt 0)
{
    $vmVirtualSwitch = $vmNicSwitchList[0]
}

# add a legacy network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch -legacy

# add a default VMBus (non-legacy) network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch

# add the hard drive to the VM
$parent = "$(get-VHDdefaultPath)\$vmParent.vhd"
$vhdPath = "$(get-VHDdefaultPath)\$vmName.vhd"
Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath $vhdPath -parent $parent

# get the VM to see if a disk is attached to it, if it is not, then it failed
$disks = Get-VMDisk -vm $vm
$count = 1

# if the disk was not successfully added, try and add it again
while ($disks -eq $null -and $count -le 5)
{
    Write-Host "RETRY $count - The disk was not properly added. Attempting to retry."
    
    # delete the disk that was added
    DeleteVhd "$(get-VHDdefaultPath)\$vmName.vhd"
    
    Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath $vhdPath -parent $parent
    
    $disks = Get-VMDisk -vm $vm
    $count++
}

if ($disks -eq $null)
{
    Write-Host "Operation failed to create this virtual machine. Contact an admin."
}
else
{
    Write-Host "Operation completed successfully. Attempting to start the VM."
    Start-VM -vm $vm -wait
}

I have found that the VM creation is not consistently successful on the first pass, so I have added the while loop. Since adding that, I have not had any issues.

I hope these help. They should be easy to change if you prefer snapshots versus differencing disks. Thanks to James O’Neill for creating this library. It makes administering Hyper-V much easier. It is available via CodePlex, where the latest release, updates, and forum support can be found.