Can't get powershell script to run inside PowerGUI - powershell

When I run my script directly from the Powershell console it works. When I run my script in PowerGUI and try instantiate an object, I get an error:
Exception calling ".ctor" with "3" argument(s): "Could not load file or assembly 'MyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=77f676cc8f85d94e' or one of its dependencies. The system cannot find the file specified."
If I put all of the needed DLLs in $PSHOME, the script will successfully run from the console but not PowerGUI. If I move the DLLs to a local directory and load the DLLs with reflection, the script will not run in PowerGUI nor the powershell console.
[reflection.assembly]::loadfile('c:\mylibs\mylib.dll')
What do I need to do to get the script to run in PowerGUI? Ideally, I'd like the DLLs in a different directory than $PSHOME.

You should be using [Assembly]::LoadFrom as opposed to LoadFile. LoadFile is intended for loading assemblies that cannot be loaded in the normal assembly loading context such as the case where you are trying to load two versions of the same assembly. It does not use the normal probing rules so that is why it doesn't automatically load dependencies. Here's an excerpt from the documentation for LoadFile.
Use the LoadFile method to load and
examine assemblies that have the same
identity, but are located in different
paths. LoadFile does not load files
into the LoadFrom context, and does
not resolve dependencies using the
load path, as the LoadFrom method
does. LoadFile is useful in this
limited scenario because LoadFrom
cannot be used to load assemblies that
have the same identities but different
paths; it will load only the first
such assembly.
If you are using PowerShell 2.0 you may wish to use Add-Type instead:
Add-Type -Path c:\mylibs\mylib.dll
And if all else fails, run Fuslogvw.exe to find out why binding fails.

Use set-psdebug -trace 2 to see what it is attempting to call exactly.

This could be because PowerGUI is a different PowerShell host so its 'local folder' is PowerGUI's folder in Program Files, and not $pshome - where you put the DLLs.

Related

Using Microsoft.Data.SqlClient in PowerShell

I would like to use the Microsoft.Data.SqlClient namespace/ objects in a PowerShell script.
Two (click1, click2) Github posts provide a way to load the correct dll's, but the solutions don't seem to work anymore.
E.g. result of the first solution while copying the next files:
(Packages copied from .nuget/packages folder)
Microsoft.Data.SqlClient.dll
Microsoft.Data.SqlClient.SNI.x64.dll
Microsoft.Identity.Client.dll
Result: Could not load file or assembly 'System.Runtime, Version=6.0.0.0'
In addition, I've tried to create a Dummy Console App -> Added the Microsoft.Data.SqlClient Nuget package -> built the project and copied all dll's to the same folder as the PS script.
As soon as I start the script (using the 'Add-Type -Path' construction), it results in errors, such as 'couldn't load file or assembly - wrong version...' (this is strange, because the folder contains all dll's...)
Could you provide an alternative solution/ steps in order to use the described package in a PS script?

Powershell : Not all .dll load from the specified source LoadFrom

I am quite new to powershell and in one of the Powershell Project I am not able to load all the DLLs from the same specified source $dllPath using LoadFrom.
As shown, Az.NewUtility (first dll) references all below .dlls and all 9 dlls are present in my DBScripts\KvProviderLib Folder.
But powershell automatically loads two from the folder "Az.Accounts\1.2.1\" instead from DBScripts\KvProviderLib
As per the functionality this project executes some Powershell commands like Get-AzContex, Get-AzKeyVault and once those commands are executed it tries to load the dlls using above code. But it loads these two dlls (Microsoft.Rest.ClientRuntime.dll and Microsoft.Rest.ClientRuntime.Azure.dll) from different source.
I need to load these two dlls (Microsoft.Rest.ClientRuntime.dll and Microsoft.Rest.ClientRuntime.Azure.dll) from the same folder I specified in $dllPath to execute the functions written in Az.NewUtility successfully.
Is there Anyway I can forcefully load them from the specified path i.e $dllPath and in the same Powershell session after commands Get-AzContex, Get-AzKeyVault are executed?
P.S : If I open a new powershell session and execute the script it loads it from right source but it loads it from different source if I try loading it after executing Get-AzContext, Get-AzKeyVault Command.

Problems when loading Assemblies in PowerShell

I'm currently building a powershell transfer script that uses WinSCP assembly to upload files. I have defined a class in which I'm initializing things like the WinSCP.SessionOptions etc. These types are defined in the WinSCPnet.dll. At the beginning of my script I'm importing the assembly with
Add-Type -Path <Path-to-assembly.dll>
Later in my class definition I have a variable like this that is not yet initialized
[WinSCP.SessionOptions]$Script:SessionOptions
When I try to run the script I always get "Type not found" error referencing to the line where I'm declaring the uninitialized variable.
This problem is not limited to the WinSCP assemblies. I'm also getting it when I call a static method no matter if it's a system or a custom assembly.
What can I do to solve that?
Thanks in advance.

Determine difference between COM and .NET DLLs in Powershell

I'm writing a script to copy and move DLLs from the bin folder to a mapped drive, and I need to register/unregister the DLLs during the process. I've figured out how to do all of this, but there's a catch. The program I'm working on utilizes VB6 COM DLLs and VB.NET .NET DLLs. I understand that COM DLLs use regsvr32.exe, and .NET DLLs use regasm.exe, but I am interested in programmatically calling the correct function, based upon the DLL I am moving. Is there a way to determine what time I am using in Powershell?
Call
[Reflection.Assembly]::LoadFile( `mydll.dll`)
It should raise a BadImageFormatException if it is not a .Net dll.
As per MSDN:
"This exception is thrown when the file format of a dynamic link library (.dll file) or an executable (.exe file) does not conform to the format that is expected by the common language runtime. In particular, the exception is thrown under the following conditions:
...
An attempt is made to load an unmanaged dynamic link library or executable (such as a Windows system DLL) as if it were a .NET Framework assembly. The following example illustrates this by using the Assembly.LoadFile method to load Kernel32.dll."

nunit network drive, failing to load tests

We currently carry out development on a mapped drive. When I write nunit tests against a test assembly it will pick up the assembly, however does not recognise any of the tests.
If I move the solultion etc to a local drive and reference it again then everything works fine.
What I really woiuld like to know is why this is being caused, and how I can carry on using a network drive for development.
Per http://geekswithblogs.net/TimH/archive/2007/08/02/114340.aspx, NUnit apparently does not have appropriate permissions to access the assembly when on a network drive. The suggested fix is to add a post-build event to copy the assembly to a local temp directory and run NUnit off that copied assembly:
Within VS, open the project properties.
Go to the Build Events tab and enter the following 'Post-build event command line':
del /q c:\temp\nunit*.*
copy "$(TargetDir)." c:\temp\nunit
A potential issue you may have as a result of this change is related to the AppBase as per Unable to load <mytest> because it is not located under Appbase. The answer there is to update the Settings element within the .nunit file to include an app base of C:\Temp\NUnit then update the assembly element's path to remove any leading directory information.