Stuck in .NET dependency hell trying to build a PowerShell browser automation module? Learn three real-world solutions from a senior engineer to conquer assembly loading conflicts for good.

Taming .NET Dependencies for PowerShell Browser Automation: A Field Guide

It was 2 AM on a Tuesday. A critical deployment to our prod-billing-api-01 cluster was failing, and the on-call engineer was stumped. The culprit? A tiny PowerShell monitoring script I wrote, which innocently used a newer version of Newtonsoft.Json.dll, was conflicting with the deployment agent’s older, required version. The entire PowerShell session went belly-up, taking the deployment with it. That’s when I learned, the hard way, about PowerShell’s single AppDomain and the versioning nightmare it can create. So when I saw a Reddit post from a developer trying to build a browser automation module and hitting the exact same wall, I knew I had to share some hard-won wisdom.

The “Why”: PowerShell’s One Big Sandbox

Before we dive into the fixes, you need to understand the root of the problem. Your PowerShell session, the one you’re running your scripts in, operates within a single .NET Application Domain (or “AppDomain”). Think of it as one big room. When you load a .NET assembly (a DLL file) using Add-Type or by importing a module, you’re essentially putting a tool on a single workbench in that room.

Now, what happens if your browser automation module needs Selenium.WebDriver.dll version 4.1.0, but another script or module you’re using has already put version 3.8.0 on the workbench? PowerShell gets confused and angry. It can’t have two different versions of the same file with the same name in the same AppDomain. This is the heart of “dependency hell,” and it’s a place no engineer wants to be.

So, how do we get out of it? We have a few options, ranging from “quick and dirty” to “enterprise-grade.”

Solution 1: The Quick & Dirty Fix (The ‘GAC’ Gamble)

The first thing many people try is to force their DLL onto the system using the Global Assembly Cache (GAC). The GAC is a machine-wide repository for .NET assemblies. By installing your DLL here, you make it available to all .NET applications on that server.

How to do it:

You use the gacutil.exe tool, which comes with Visual Studio or the Windows SDK. You’d run this from a Developer Command Prompt:

gacutil.exe /i "C:\path\to\your\module\libs\Selenium.WebDriver.dll"

Why it’s usually a bad idea:

• It’s not portable. Your module now has a hidden dependency on a system-wide configuration. It’ll work on your machine, but it will fail spectacularly when you try to run it on `prod-web-fe-04` unless you remember to GAC the DLL there, too.
• It pollutes the system. You’re making a system-level change for a single module’s convenience. This can lead to even worse conflicts down the road.
• Version management is a nightmare. Upgrading the DLL means you have to remember to update the GAC on every single machine.

Darian’s Warning: I call this the “sledgehammer” approach. It might work for a quick test on your local dev box, but do not use this for anything you plan to put into production or share with your team. You’re just creating a bigger problem for your future self.

Solution 2: The ‘Right Way’ (The Module Manifest)

This is the professional, standard way to handle dependencies for a PowerShell module you intend to distribute or reuse. You bundle your required DLLs with your module and tell PowerShell exactly where to find them using the module manifest file (the .psd1).

How to do it:

First, create a predictable folder structure for your module. I like to use a lib or bin folder.

MyBrowserModule/
├── lib/
│   ├── Selenium.WebDriver.dll
│   └── Selenium.Support.dll
├── MyBrowserModule.psd1
└── MyBrowserModule.psm1

Next, you edit your MyBrowserModule.psd1 manifest file and add the RequiredAssemblies key, pointing to the DLLs using relative paths.

# In MyBrowserModule.psd1
@{
    # ... Other manifest settings like ModuleVersion, Author, etc.
    RootModule = 'MyBrowserModule.psm1'
    
    # This is the magic key.
    # PowerShell will automatically load these assemblies when the module is imported.
    RequiredAssemblies = @(
        'lib/Selenium.WebDriver.dll',
        'lib/Selenium.Support.dll'
    )

    # ... more settings
}

Why this is the best approach:

• It’s self-contained. Everything the module needs is right there in its folder. Just copy the folder, and it works.
• It’s explicit. Anyone looking at the manifest can see the module’s dependencies.
• It plays nicely with the PowerShell Gallery. This is how you publish modules for others to use reliably.

Solution 3: The ‘Nuclear’ Option (Isolate the Process)

Sometimes, even the manifest isn’t enough. You might be running on a locked-down server or alongside another critical tool that has already loaded a conflicting DLL, and you simply cannot win the AppDomain war. In this case, you don’t fight the war—you leave the battlefield. You run your code in a completely separate, isolated PowerShell process.

How to do it:

The easiest way to do this is with PowerShell Jobs using Start-Job. Each job runs in a brand-new powershell.exe process, with its own clean AppDomain.

$scriptBlock = {
    # This ScriptBlock runs in a fresh, isolated process.
    # It has its own memory and its own AppDomain.
    param($Url, $AssemblyPath)

    try {
        Add-Type -Path (Join-Path $AssemblyPath "Selenium.WebDriver.dll")
        
        $options = New-Object OpenQA.Selenium.Chrome.ChromeOptions
        $options.AddArgument('--headless') # Run without a visible browser window

        $driver = New-Object OpenQA.Selenium.Chrome.ChromeDriver($options)
        $driver.Navigate().GoToUrl($Url)
        
        # Scrape some data from an internal dashboard
        $statusElement = $driver.FindElement([OpenQA.Selenium.By]::Id('server-status-text'))
        $status = $statusElement.Text
        
        return $status # This gets sent back to the main script
    }
    finally {
        if ($driver) {
            $driver.Quit()
        }
    }
}

# Execute the job
$job = Start-Job -ScriptBlock $scriptBlock -ArgumentList 'https://dashboard.internal.techresolve.com', 'C:\Modules\MyBrowserModule\lib'

# Wait for it to finish and get the results
Wait-Job $job | Out-Null
$serverState = Receive-Job $job

Write-Host "The current server state is: $serverState"

# Clean up the job object
Remove-Job $job

When to use this:

This is your escape hatch. It’s heavier and more complex because you have to pass data back and forth, and there’s a performance cost to spinning up a new process. But it provides guaranteed isolation. If you’re building a tool that needs to run reliably on servers you don’t control, this is the safest bet.

Pro Tip: Think of this as putting your code in a hazmat suit. It can’t touch anything in the main session, and nothing can touch it. It’s perfect for mission-critical automation that absolutely, positively cannot fail due to a dependency conflict.

Choosing Your Weapon

So, which solution should you use? Here’s a quick cheat sheet.

Solution	Best For	Pros	Cons
1. The GAC	Quick, temporary local testing.	Fast to implement.	Brittle, not portable, pollutes system. (Avoid)
2. Module Manifest	95% of use cases. Reusable/sharable modules.	Self-contained, clean, industry standard.	Still runs in the shared AppDomain.
3. Isolated Process	Hostile/unknown environments, unresolvable conflicts.	Total isolation, guaranteed to run.	Slower, more complex, higher overhead.

My advice? Always start with Solution 2. It’s the right way to build robust, maintainable PowerShell tools. Only reach for the ‘Nuclear’ option when you’re backed into a corner. We’ve all been in that 2 AM dependency hell, but with the right architecture, you won’t have to visit it again. Happy automating.

---

🤖 Frequently Asked Questions