Percy’s Random Ramblings

Fun with Powershell, Part 2 – Investigating code Issues Tuesday, 02/21/2012

Since I missed posting something last week, I’m putting out two this week to keep up with my resolution.  This is the second post in a series of posts about the fun I’m having with Powershell.

Part of me putting this series of posts out there is to help people look at Powershell in a different light – as a developer tool. I think it gets labeled as a SysAdmin tool, which it definitely is. However, I’m finding more and more that when I turn to Powershell to help me, I end up getting the info I need quicker and easier and I write less code. This is another one of those issues.

So, I picked up an unfinished project for a client recently. The project is in the process of being QAed, but there were issues that had been found along the way. The original developer had since left the company, so it was up to me to figure it all out. One of these issues had to do with the rendering of a DataDynamics Active Report. The error that was being thrown had to do with displaying a logo. Basically, it was instantiating a Bitmap object using a stream from an embedded resource, but the stream was returning as null.

new Bitmap(Assembly.GetExecutingAssembly().GetManifestResourceStream("{SupposedlyValidReference}")); 

So, I started thinking about how I could look into what was causing this issue. I could set up the web application where this issue was being thrown and go straight to debugging. However, in this case, that was a bit more complicated than it sounded. Also, the issue was in a compiled assembly that wasn’t specifically part of the website. I could write a harness to call this report and debug that way. I actually already have something like this written and shared with some co-workers, but even that was a bit more complicated then I wanted. Too, I didn’t need to test the entire report, just this one line. I could write a console app, and pull this code out to see what’s going on. Yea, I could do that somewhat quickly, but not as quickly as I could write some Powershell scripts to see what’s going on. So, that’s what I did.

Here’s the script I whipped up somewhat quickly:

cls 
$assemblyPath = "{PathToAssembly}" 
$assembly = [System.Reflection.Assembly]::LoadFile($assemblyPath) 
$stream = $assembly.GetManifestResourceStream("{ValidPath}") 
$stream | Get-Member 

Since that was basically the part of the code that was throwing the error. Running that script threw the following error: “Get-Member : No object has been specified to the get-member cmdlet.” That tells me the same thing the error message from the app tells me – my stream object is null. So, I started looking at the path to the resource, and the actual file name. It turns out the file was named ####_Logo.gif, while the resource referenced ####_logo.gif. So, just to see if that was the issue, I changed my script to have the capital L in the resource path. Running that script gave me a valid System.IO.UnmanagedMemoryStream object for $stream.

That’s it. It was just a letter casing issue. However, instead of firing up a new instance of Visual Studio, creating a new console app, adding a reference to this assembly, writing the code and stepping through it, all I had to do was write a simple 5 line script. Really, it could have been 2 lines (Load the assembly, and get the stream).

If you missed out on Part 1,  here it is.