Когда вы выводите TestClassTwo
в dll (в том же каталоге, что и TestClassOne
) и Add-Type
, это работает. Или, по крайней мере, на моей машине;) Так что это уродливый обходной путь.
При вызове $b.CallTestClassOne()
PowerShell пытается (по какой-то причине я не знаю) найти сборку TestClassOne.dll в следующих местах:
LOG: Pokus o stažení nové adresy URL file:///C:/Windows/SysWOW64/WindowsPowerShell/v1.0/TestClassOne.DLL
LOG: Pokus o stažení nové adresy URL file:///C:/Windows/SysWOW64/WindowsPowerShell/v1.0/TestClassOne/TestClassOne.DLL
LOG: Pokus o stažení nové adresy URL file:///C:/Windows/SysWOW64/WindowsPowerShell/v1.0/TestClassOne.EXE
LOG: Pokus o stažení nové adresy URL file:///C:/Windows/SysWOW64/WindowsPowerShell/v1.0/TestClassOne/TestClassOne.EXE
Это вывод инструмента fuslogvw. Это может быть полезно для вас. Этот же список путей можно увидеть в реальном времени с помощью ProcessMonitor.
Вы также можете попробовать это (перед вызовом CallTestClassOne()
[appdomain]::CurrentDomain.add_assemblyResolve({
$global:x = $args
})
$b.CallTestClassOne()
$x | fl
Это покажет вам, какая сборка не удалась, и немного больше информации.
Я согласен, что это должно работать так, как вы ожидаете. Вот почему это выглядит несколько глючно.