PowerShell not loading them DLLs

How to resolve issues when loading DLLs in PowerShell?

Reading Time: 3 minutes.

This post describes a few different things that can (and will) go wrong when you’re trying to load DLLs in PowerShell, and a couple of ways you can try to fix them. Typically, you’d run into an error message like “Exception calling LoadFrom with 1 argument(s): Could not load file or assembly…. “

These issues most typically arise when you’re running a PowerShell script that depends on certain DLLs to be loaded (to then execute some of the methods from them). This could happen kind of behind the scenes – if you’re importing modules from a path, you’re still essentially loading DLL files, just by using a wrapper around them.

The script never gets far enough to execute anything, though – the error is thrown already when you try to load them into memory.

My most typical use case that I’d run into, would be to load SharePoint Client DLLs (like Microsoft.SharePoint.Client.dll and friends) in a script. Sometimes they are loaded from a location on disk, but often they’re bundled with the script and just loaded from the execution path, which is quite convenient (when it works)!

An example of such call would be:

# This row loads SharePoint Client dll from the execution folder (if it's packaged with the script!)
 
$loaded = [System.Reflection.Assembly]::LoadFrom((Get-Location).Path+"\Microsoft.SharePoint.Client.dll")

And this would throw something like this:

Exception calling "LoadFrom" with "1" argument(s): "Could not load file or assembly 'file:///...\Microsoft.SharePoint.Client.dll' or one of its dependencies. ..."

The important part is actually what comes AFTER that error. See more below…

Solutions

These 2 separate issues and their respective solutions are the most typical ones I’ve run into.

Solution to “An attempt was made to load a program with an incorrect format.”

This is kind of the simpler case: wrong architecture. You’re trying to load 32b files into 64b PowerShell session or vice versa.

In a case like this, the solution is fairly simple. You can’t (easily) run modules (DLLs) compiled against different architecture in PowerShell. In case the DLLs have been compiled for 64-bit architecture, you need to run 64-bit PowerShell as well.

How to test if you’re running 64-bit PowerShell:

# this'll return true or false
[Environment]::Is64BitProcess

(this should work starting from PowerShell 3.0)

Where to find different versions of PowerShell:

  • By default, these are the installation locations:
    • 32-bit PowerShell:
      • C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
    • 64-bit PowerShell:
      • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Solution to “Operation is not supported. (Exception from HRESULT: 0x80131515)”

Okay – so this part is a lot more complicated. Not because the error would be so obscure, but rather because there’s a bunch of possible solutions that work or do not work. The issue is typically caused by a blocked or reserved file, but determining what exactly is wrong might not be straightforward.

Start by trying if the error persists when running the console as administrator.

If that didn’t help, proceed by opening the properties of the DLLs, and checking if you can unblock them (see picture below). Then close the shell, and open it up again – this time it might work.

Unblocking a file in the properties window
Unblocking a file in the properties window

Still doesn’t work? Try restarting your PowerShell – and if even that doesn’t work, restart your laptop.

It’s weird, but this has helped multiple times! I suspect it’s a file handle being left open (from an earlier PowerShell session, maybe?), and the PowerShell instance being unable to load the file because of that. Powershell is kind of notorious for caching things very aggressively, and holding on to file handles even after the window has been closed, so sometimes a reboot might be the easiest path.

References

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.
mm

Leave a Reply

avatar
5000
  Subscribe  
Notify of