ADNUG–PowerShell for Developers

Monday, 30 June 2014

I'm presenting at the July meeting of the Adelaide .NET User Group.

If you're not automating repetitive tasks with PowerShell, you're probably doing it wrong! In this presentation I will give a quick introduction to PowerShell (including some recommended practices) and then dive deeper into how you can use PowerShell as part of your TFS build process and how you can even host PowerShell in your own .NET applications.

6pm, Wednesday 9th July 2014

Marcellina Adelaide
273 Hindley Street, (Cnr Gray St) Adelaide

($5 for pizza, free if you're an ADNUG member)

Register via the ACS Events site

Hope to see you there!

Lumia 920–Stuck in ‘headphones’ mode

Tuesday, 10 June 2014

Last month after watching the demos from the Microsoft Build conference on the updates to Windows Phone, I decided to take the plunge and update my phone to Windows Phone 8.1. All was going well and some of the new features were really nice – improved keyboard, the notification centre, and VPN support to name a few.

Then all of a sudden a few weeks later my handset wouldn't acknowledge that my headphones were no longer plugged in. It thought they were always plugged in, so didn't play audio through the speaker – making receiving phone calls tricky as you either had to switch the call to 'hands free', or to quickly plug the headphones back in.

A few others seemed to be in the same boat, but subsequent updates for 8.1 didn't resolve the issue. The original reporter then sent his phone off to be checked under warranty. I decided to do the same – for while the problem happened after I'd upgraded to 8.1, there don't seem to be heaps of people with the same problem, so maybe it was more a coincidence and just a regular mechanical fault with the headphone jack.

The only tricky bit was proving to Nokia that it was my phone (I'd won it from Microsoft so I didn't have a receipt). After a bit of email tag and a few phone calls they were finally convinced and I posted my handset off to Sydney.

Before being sent off to Nokia Care, I was asked to use the Nokia Software Recovery Tool. This had the interesting effect of downgrading the firmware and OS back to 8.0 (and didn't fix the audio problem, which increased my suspicions that the problem was not software-based)

Here's the details before it was posted off:

imagewp_ss_20140530_0002

Today I finally got it back. They'd replaced the audio jack and the USB jack. Looks like they re-flashed the firmware with the Australian ‘country’ variant of the Lumia Black Update (3051.40000.1349.0007) – Probably better to have ‘RM-821_apac_australia_new_zealand_304’ instead of ‘RM-821_eu_euro1_425’ I suppose.

imagewp_ss_20140610_0002

And yes, the audio is now working!

While my phone was being serviced, I dug up my trusty old Samsung 'dumb' handset and after visiting Vodafone to get a normal-sized SIM I at least was contactable on my mobile (if not online). Conveniently, Vodafone now give out SIMs that you can pop-out the middle to get a micro-SIM, so I didn't need to go back to the Vodafone shop a second time.

WP_20140610_001

Also, thanks to the Windows Phone Backup feature, I am restoring all my apps and settings so my phone is basically back to how it was before all the dramas started! Very convenient.

Next step, to the latest Windows Phone 8.1 release. With a new audio jack fitted, I'm hoping there will be no more issues.

imagewp_ss_20140610_0002 1

PowerShell Wix Extension

Sunday, 25 May 2014

I’ve looked, but I couldn’t find anyone who’d implemented a Wix Extension that would allow running PowerShell scripts. So I’ve spent a few hours this weekend writing one (and learned a bit more about Wix and MSIs along the way).

This extension allows you to run script from a file that is included in the MSI, or inline script (inside a CDATA section)

By hosting PowerShell in the custom actions, scripts also get access to the $session variable (which is of type Microsoft.Deployment.WindowsInstaller.Session), so you can call $session.Log(“Running this”) and it will add “Running This” to the MSI log!

Here’s an example of what you can do:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:powershell="http://schemas.gardiner.net.au/PowerShellWixExtensionSchema">
  <Product Id="*" Name="PowerShellWixTest" Language="1033" Version="1.0.0.0" Manufacturer="David Gardiner" UpgradeCode="c61298af-d8c9-4179-903f-f42fa69b59ad">
    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />

    <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
    <MediaTemplate />

    <Feature Id="ProductFeature" Title="PowerShellWixTest" Level="1">
      <ComponentGroupRef Id="ProductComponents" />
    </Feature>

    <powershell:File Id="PSFile1" File="[#TestPs1]" Arguments="&quot;First Argument&quot; 2"/>

    <powershell:Script Id="Script2">
      <![CDATA[
        
        # Write-Host "Number 2";
        
        for ($i = 1; $i -le 100; $i++) 
        { 
          Write-Progress -Activity "Activity" -Status "Status $i% complete" -CurrentOperation "Operation $i" -PercentComplete $i
          Start-Sleep -Milliseconds 5 
        }
        
        ]]>
    </powershell:Script>
    
    <UI>
      <TextStyle Id="WixUI_Font_Normal" FaceName="Tahoma" Size="8" />
      <TextStyle Id="WixUI_Font_Bigger" FaceName="Tahoma" Size="12" />
      <TextStyle Id="WixUI_Font_Title" FaceName="Tahoma" Size="9" Bold="yes" />

      <Property Id="DefaultUIFont" Value="WixUI_Font_Normal" />
      <Property Id="WixUI_Mode" Value="Minimal" />

      <DialogRef Id="ErrorDlg" />
      <DialogRef Id="FatalError" />
      <DialogRef Id="FilesInUse" />
      <DialogRef Id="ProgressDlg2" />
      <DialogRef Id="UserExit" />

      <Publish Dialog="ExitDialog" Control="Finish" Event="EndDialog" Value="Return" Order="999">1</Publish>

      <Property Id="ARPNOMODIFY" Value="1" />
    </UI>

    <UIRef Id="WixUI_Common" />
  </Product>

  <Fragment>
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="PowerShellWixTest" />
      </Directory>
    </Directory>
  </Fragment>

  <Fragment>
    <ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
      <Component Id="ProductComponent">
        <File Id="TestPs1" Source="Test.ps1" KeyPath="yes" />
      </Component>
    </ComponentGroup>
  </Fragment>
</Wix>

The code and releases are hosted on GitHub - https://github.com/flcdrg/PowerShellWixExtension

Development resources

Aussie Forecast

Friday, 9 May 2014

My latest app for Windows Phone is now available in the store – Aussie Forecast!

Aussie Forecast Lock Screen

Windows Phone 8 supports apps displaying custom information on the lock screen. The Bing Weather app is a nice example, but I was frustrated by the inaccurate forecast data that it was using. Not the first time I've seen this problem.

So I thought I'd create my own app that uses the Australian Bureau of Meteorology's data to display the forecast for a selected location. You can optionally choose to have the forecast displayed on your phone's lock screen, and a background task runs at regular intervals to keep the information current.

Application main page screenshotSettings screen

Future enhancements will include allowing a user-selected photo for the background image or the daily Bing Photo.

If you've got a Windows Phone 8 device, then please try it out!

Download from the Windows Phone Store

Using BugSense for Windows Phone with Caliburn.Micro

Sunday, 4 May 2014

BugSense is a 3rd party service I came across recently being promoted on Nokia's (now Microsoft's) DVLUP site. They provide aggregation and reporting of errors from your apps.

All of the usual platforms are supported, and conveniently they provide NuGet packages to facilitate integrating with Windows Phone 7, 8 and Windows Store apps.

I like using Caliburn Micro (CM) for most of my Windows Phone apps to help with using the MVVM pattern, and one of the requirements for using CM is to strip out the contents of the App.xaml.cs file's constructor, leaving just

public App()
{
    // Standard XAML initialization
    InitializeComponent();
}

The BugSense instructions however assume you're using a regular Windows Phone project that has the original App.xaml.cs contents. The workaround I've settled on is to add the BugSense code to the body of the Configure method in the CM AppBootstrapper class.

First, add the BugSense namespaces:

using BugSense;
using BugSense.Core.Model;

Then initialise BugSense (replacing API_KEY with the key displayed when you click on 'Help me integrate' on the BugSense site:

protected override void Configure()
{
    // Initialize BugSense
    BugSenseHandler.Instance.InitAndStartSession(new ExceptionManager(App.Current), RootFrame, "API_KEY");

You might also wish to add logging of handled exceptions too:

catch (Exception ex)
{
    BugSenseLogResult logResult = BugSenseHandler.Instance.LogException(ex);

    // Examine the ResultState to determine whether it was successful.
    Debug.WriteLine("Result: {0}", logResult.ResultState.ToString());

    Debug.WriteLine(ex);
}

In a future post I hope to describe logging exceptions for background tasks.