Get assembly files from GAC using PowerShell

A while ago I found myself in an unfortunate situation where I had to use Reflector to figure out what I was doing wrong when interacting with third-party components. Unfortunately, a large part of the third-party code was in assemblies that were installed in the GAC, and I was unable to find them anywhere else.

Here’s a quick PowerShell one-liner that helped me out:

dir C:\Windows\Assembly -Recurse -Filter "VendorName*.dll" | foreach { copy $_.FullName C:\Temp\assemblies }

That was pretty quick and easy to come up with, and it makes me very glad I decided to learn the basics of PowerShell. 🙂

Protocol-relative HTTP URLs

If you’re visiting a web page over an SSL encrypted connection, you might sometimes get an annoying “mixed content” warning. In essence, the browser is telling you that yes, the page itself was delivered over HTTPS, but other bits were not, and that may or may not mean that you’re in danger.

From the developer point of view, having to build every URL so that the protocol is taken into account can be tedious. It might equally well be the case that your framework of choice already handles this. If so, good for you.

However, there’s another escape hatch not known to most people: protocol-relative URLs. You write the url without the protocol and following colon, and the client will choose whichever protocol was used to retrieve the page, like so: //server:port/path/to/resource.html

Not sure how often this is actually necessary, but there you go. 🙂

Power to the people

My esteemed colleague Jouni Heikniemi is a speaker at this year’s TechDays Finland. His topic is “PowerShell for Developers”. We had a chance to hear his presentation beforehand this morning. I’ve been meaning to do so for a few years now, but after the presentation I finally found the motivation to try and write an actual PowerShell script for myself.

The problem

I wanted a simple script to bundle an ASP.NET web application in a directory – basically, copy all the files that are essential to running the app, and nothing more. Something I’d typically use a NAnt or MSBuild task for.

The solution


So I fired up PowerShell ISE (I assume that’s Integrated Scripting Environment) and after a few attempts, came up with this:

$targetPath = "deploy"
if (Test-Path $targetPath) { Remove-Item $targetPath -Recurse -Force }

New-Item $targetPath -type directory

Copy-Item -Path .\App_Data -Destination $targetPath -Recurse 
Copy-Item -Path .\App_GlobalResources -Destination $targetPath -Recurse -Filter "*.resx"
Copy-Item -Path .\bin -Destination $targetPath -Recurse -Filter "*.dll"
Copy-Item -Path ("*.as?x", "*.js", "*.gif", "*.jpg", "Web.config") -Destination $targetPath

Since it creates a directory that can be deployed as an application, I saved the snippet as Deploy.ps1 (in hindsight, Build.ps1 would have been a better name, but I’m too lazy to take another screenshot).

This bit of script is very specific to my needs, so don’t take it as a textbook example of good PowerShell scripting. 🙂

The snag and the resolution

As it turns out, PowerShell scripts aren’t allowed to run, at all, by default. Fortunately, the default is relatively easy to change. Fire up PowerShell or the ISE with administrative privileges, and type:

Set-ExecutionPolicy RemoteSigned

RemoteSigned means you’re free to run unsigned scripts as long as they’re locally created, but scripts downloaded from other sources need to be signed. In case you’re curious, downloaded scripts are identified based on Alternate Data Streams.

PowerShell will ask you to confirm this. In the case of ISE, by means of a really, really long-ass dialog text:


Once you confirm the change, you can restart PowerShell with limited privileges, and scripts will work.

For more info on PowerShell, visit Jouni’s series of blog posts on the topic.

SharePoint web part lifecycle

For various reasons, I’ve found myself doing Web Part development for SharePoint 2007. While I suspect I’ll be blogging more thoroughly about it later (possibly even via SharePoint Blues, who knows) , I thought I’d contribute my first useful SharePoint link: The lifecycle of SharePoint Web Parts.

My WebForms experience is rather limited, but on the surface, the list looks a lot like a WebForms control’s life cycle. The reason I needed this list specifically is that I wanted to know the point at which I could safely assume that other web parts would be connected and their data would be available.