0

I'm attempting to load a specific DLL within PowerShell using the below code:

function New-SpecificAssembly {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [string]$Path
    )
    process {
        [string]$Fullname = ([System.Reflection.AssemblyName]::GetAssemblyName($Path)).FullName
        Write-Verbose "Loading: $Fullname"
        Write-Output ([System.Reflection.Assembly]::Load($FullName))
    }
}

$d11_Security = New-SpecificAssembly -Path 'C:\Windows\Microsoft.NET\Framework\v1.1.4322\System.Security.dll' -Verbose
$d11_Security | ft ImageRuntimeVersion, Location -autosize

However, I cannot find a way to get it to load the .net1.1 version of the DLL. The above returns: v2.0.50727 / C:\Windows\assembly\GAC_MSIL\System.Security\2.0.0.0__b03f5f7f11d50a3a\System.Security.dll.

Additional Info

LoadFrom

NB: I've also tried using LoadFrom as detailed here: https://stackoverflow.com/a/9447959/361842; however that returned the v2 version of the dll. Checking https://msdn.microsoft.com/en-us/library/1009fa28(v=vs.110).aspx

The LoadFrom method has the following disadvantages. Consider using Load instead.

  • If an assembly with the same identity is already loaded, LoadFrom returns the loaded assembly even if a different path was specified.

That said, it turns out that Load has the same caveat despite the recommendation. i.e. per https://msdn.microsoft.com/en-us/library/ky3942xh(v=vs.110).aspx:

FileLoadException is thrown if assemblyString specifies the full assembly name, and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name.

LoadFile

I'd thought LoadFile may work where LoadFrom failed, given we're explicitly stating the file path. https://msdn.microsoft.com/en-us/library/b61s44e8(v=vs.110).aspx. Sadly though the documentation doesn't report any potential issues here (beyond dependencies not being loaded), however this still returns the wrong version:

ImageRuntimeVersion Location
------------------- --------
v2.0.50727          C:\Windows\assembly\GAC_MSIL\System.Security\2.0.0.0__b03f5f7f11d50a3a\System.Security.dll

More Detail

NB: Since we're looking at an x86 dll, I'm running PowerShell x86 (i.e. %SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe).

The reason for this is to aid in investigating an issue migrating a legacy site from an old Windows 2003 server to Windows 2008 R2, having already followed the steps outlined here: https://learn.microsoft.com/en-us/iis/install/installing-iis-7/how-to-install-aspnet-11-with-iis-on-vista-and-windows-2008. Sadly we don't have access to the source for this site, so recoding is not an option. The error mentions InvokeMember("_GetRoles", /* ... */, so I assume they've used the reflection technique for enumarting roles as outlined here: https://www.thecodingforums.com/threads/enumerate-roles-a-user-belongs-to-seek-vb-net-sample.85831/. The PowerShell's just my way of playing with the DLLs to get an idea of what may be going on under the covers / to try to see if the DLL can loaded correctly / etc. i.e. it's a way for me to poke around.

JohnLBevan
  • 22,735
  • 13
  • 96
  • 178
  • Loading the raw assembly might work: `[System.Reflection.Assembly]::Load([byte[]]@(Get-Content $Path -Encoding byte))` – Mathias R. Jessen Oct 11 '17 at 16:40
  • Thanks @MathiasR.Jessen; sadly that still gives `v2.0.50727`. I suspect it may be because PS itself uses this assembly, and once one version of a DLL's loaded .Net will only use that version of the DLL with that name, regardless of evidence/other settings... – JohnLBevan Oct 14 '17 at 11:28
  • NB: Thankfully the issue I was hunting down turned out to be unrelated to .Net versions; rather I'd set up a hosts file entry to ensure tests on my new server went to itself rather than contacting the old server before DNS was updated to switch to the new server, and this was causing a loopback issue: https://stackoverflow.com/a/16281571/361842 – JohnLBevan Oct 14 '17 at 11:32
  • For the given issue, I found http://www.hurryupandwait.io/blog/hosting-a-net-4x-runtime-inside-powershell-v2, detailing running PS under a different version of .net. However, `$env:COMPLUS_version = 'v1.1.4322'; & powershell {$psVersionTable}` throws error `Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 80070002.`; implying that this is a no-go. – JohnLBevan Oct 14 '17 at 11:54

0 Answers0