How to resolve issues when loading DLLs in PowerShell?

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.

The most typical use case that I've 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)!

So, let's get to the point.

How to load a DLL in PowerShell?

An example of such a 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 if it goes wrong, it 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.

A 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 a 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 architectures 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

A 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 are 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.

Time needed: 5 minutes.

Unblock the DLLs properties

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

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

   
   Unblocking a file in the properties window

3. 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

• Multiple solutions are offered in these threads:

  • https://stackoverflow.com/questions/13799260/powershell-runtime-exception-could-not-load-file-or-assembly

  • https://intellitect.com/loadfrom-exception-an-attempt-was-made-to-load-a-program-with-an-incorrect-format/

• Loading PowerShell with different architectures:

  • https://www.gregorystrike.com/2011/01/27/how-to-tell-if-powershell-is-32-bit-or-64-bit/