How to load DLL files in PowerShell

user_4018304 0
Viewed 1578

I am following MS Document to use Kusto in PowerShell,

When ever I run the installation script ,

$packagesRoot = "C:\Myfiles\tools"
dir $packagesRoot\* | Unblock-File
[System.Reflection.Assembly]::LoadFrom("$packagesRoot\Kusto.Data.dll")

I am getting GAC as False and unable to install the Kusto Dll file as below

enter image description here

Please help me.

azure-data-explorer .net-assembly gac powershell dll
1 Answers

  • There's no error, just unexpected (by you) output; just use
    $null = [System.Reflection.Assembly]::LoadFrom("$packagesRoot\Kusto.Data.dll")
    to suppress the unwanted output.

  • However, the PowerShell-idiomatic way to load an assembly is to use Add-Type, which is silent by default (but would report errors if loading failed), unless you use -PassThru[1]:

Add-Type -LiteralPath "$packagesRoot\Kusto.Data.dll"

The output you're seeing is simply how PowerShell's formatting system represents the System.Reflection.Assembly object returned from the System.Reflection.Assembly.LoadFrom() call - and the fact that such an object was returned implies success.

The GAC column reflecting False simply tells you that the assembly in the question isn't stored in the GAC.

As an aside re the GAC (Global Assembly Cache):

  • Neither System.Reflection.Assembly.LoadFrom() nor Add-Type install an assembly [in the GAC], they simply load an assembly from its current disk location into the current session for use.

  • Generally speaking:

    • Installing assemblies in the GAC is only meant to be performed by Windows Installer - see the docs
    • PowerShell (Core) 7+, the cross-platform successor to Windows PowerShell, is no longer built on .NET Framework, but its cross-platform success, .NET (Core) / .NET 5+, which doesn't have a GAC anymore.

[1] -PassThru always outputs type, not assembly information, so that when you combine -PassThru with -Path / -LiteralPath, i.e. when you load an assembly, it is info objects about the types contained in the assembly that are output (not an object describing the assembly itself, which is what [System.Reflection.Assembly]::LoadFrom does). However, due to a bug as of PowerShell 7.1 relating to forwarded types, the latter aren't included, which can result in no output altogether - see GitHub issue #10802.

user_453750
Related