Problem loading an assembly referencing a non-.NET dll

Hi, I searched for this on the forum but couldn't find anything.

I loaded an assembly in powershell using:
[reflection.assembly]::loadfrom((resolve-path
D:\NET\Projects\Watchtower\Code\ECS.WatchTower.Testing.MessageSender\bin\Debug\ECS.WatchTower.Testing.MessageSender.dll))

(the resolve-path call wasn't necessary, but it allows tab-completion)

This assembly references some other .NET assemblies, which in turn reference
some plain-old non-.NET .dlls. The load command is done without complaint,
but when I try to create a new object, .NET attempts to load the required
assemblies. Everything seems to load properly except for the non-.NET .dlls,
which give the error:

New-Object : Exception calling ".ctor" with "0" argument(s): "Could not load
file or assembly '[name redacted], Version=1.0.0.0, Culture=neutral,
PublicKeyToken=99e83667a1e13da9' or one of its dependencies. The system
cannot find the file specified."
At line:1 char:16
+ $b = New-Object <<<< ECS.WatchTower.Testing.MessageSender.MessageFactory

Things that don't work:
Copying the .dll into the same directory as the MessageFactory assembly.
Registering the .dll

I CAN fix this by copying the non-.NET .dlls into
c:\windows\system32\windowspowershell\v1.0
but, that's not a particularly good solution. Can anyone tell me what's
going on, and why I have to use this workaround?

Thanks,

Jeremiah

..NET has a hirearchy that it will search for an assembly starting with the
Global Assembly Cache [GAC] and passing through various folders including the
folder the application is running from - in this case the PowerShell install
directory. By copying the dlls into the PowerShell directory you are
therefore making them available on the standard .NET search path
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Jeremiah Buckley" wrote:

> Hi, I searched for this on the forum but couldn't find anything.
>
> I loaded an assembly in powershell using:
> [reflection.assembly]::loadfrom((resolve-path
> D:\NET\Projects\Watchtower\Code\ECS.WatchTower.Testing.MessageSender\bin\Debug\ECS.WatchTower.Testing.MessageSender.dll))
>
> (the resolve-path call wasn't necessary, but it allows tab-completion)
>
> This assembly references some other .NET assemblies, which in turn reference
> some plain-old non-.NET .dlls. The load command is done without complaint,
> but when I try to create a new object, .NET attempts to load the required
> assemblies. Everything seems to load properly except for the non-.NET .dlls,
> which give the error:
>
> New-Object : Exception calling ".ctor" with "0" argument(s): "Could not load
> file or assembly '[name redacted], Version=1.0.0.0, Culture=neutral,
> PublicKeyToken=99e83667a1e13da9' or one of its dependencies. The system
> cannot find the file specified."
> At line:1 char:16
> + $b = New-Object <<<< ECS.WatchTower.Testing.MessageSender.MessageFactory
>
> Things that don't work:
> Copying the .dll into the same directory as the MessageFactory assembly.
> Registering the .dll
>
> I CAN fix this by copying the non-.NET .dlls into
> c:\windows\system32\windowspowershell\v1.0
> but, that's not a particularly good solution. Can anyone tell me what's
> going on, and why I have to use this workaround?
>
> Thanks,
>
> Jeremiah
>

OK, I hear you, but it would be nice if I could put the .dll somewhere a
little more logical (to me).

It seems that .NET should check in the directory of the referencing
Assembly, or something. Maybe that leads to outlandish discovery algorithms.

Let me refine the question a bit: is there a way to keep the non-.NET .dll
in the same location as the referencing .NET assembly and get .NET to notice
it?

Thanks again,

Jeremiah

"RichS" wrote:

> .NET has a hirearchy that it will search for an assembly starting with the
> Global Assembly Cache [GAC] and passing through various folders including the
> folder the application is running from - in this case the PowerShell install
> directory. By copying the dlls into the PowerShell directory you are
> therefore making them available on the standard .NET search path
> --
> Richard Siddaway
> Please note that all scripts are supplied "as is" and with no warranty
> Blog: http://richardsiddaway.spaces.live.com/
> PowerShell User Group: http://www.get-psuguk.org.uk
>
>
> "Jeremiah Buckley" wrote:
>
> > Hi, I searched for this on the forum but couldn't find anything.
> >
> > I loaded an assembly in powershell using:
> > [reflection.assembly]::loadfrom((resolve-path
> > D:\NET\Projects\Watchtower\Code\ECS.WatchTower.Testing.MessageSender\bin\Debug\ECS.WatchTower.Testing.MessageSender.dll))
> >
> > (the resolve-path call wasn't necessary, but it allows tab-completion)
> >
> > This assembly references some other .NET assemblies, which in turn reference
> > some plain-old non-.NET .dlls. The load command is done without complaint,
> > but when I try to create a new object, .NET attempts to load the required
> > assemblies. Everything seems to load properly except for the non-.NET .dlls,
> > which give the error:
> >
> > New-Object : Exception calling ".ctor" with "0" argument(s): "Could not load
> > file or assembly '[name redacted], Version=1.0.0.0, Culture=neutral,
> > PublicKeyToken=99e83667a1e13da9' or one of its dependencies. The system
> > cannot find the file specified."
> > At line:1 char:16
> > + $b = New-Object <<<< ECS.WatchTower.Testing.MessageSender.MessageFactory
> >
> > Things that don't work:
> > Copying the .dll into the same directory as the MessageFactory assembly.
> > Registering the .dll
> >
> > I CAN fix this by copying the non-.NET .dlls into
> > c:\windows\system32\windowspowershell\v1.0
> > but, that's not a particularly good solution. Can anyone tell me what's
> > going on, and why I have to use this workaround?
> >
> > Thanks,
> >
> > Jeremiah
> >

There are ways you can force this for .NET applications but it involves the
use of configuration files which aren't available fro PowerShell
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Jeremiah Buckley" wrote:

> OK, I hear you, but it would be nice if I could put the .dll somewhere a
> little more logical (to me).
>
> It seems that .NET should check in the directory of the referencing
> Assembly, or something. Maybe that leads to outlandish discovery algorithms.
>
> Let me refine the question a bit: is there a way to keep the non-.NET .dll
> in the same location as the referencing .NET assembly and get .NET to notice
> it?
>
> Thanks again,
>
> Jeremiah
>
> "RichS" wrote:
>
> > .NET has a hirearchy that it will search for an assembly starting with the
> > Global Assembly Cache [GAC] and passing through various folders including the
> > folder the application is running from - in this case the PowerShell install
> > directory. By copying the dlls into the PowerShell directory you are
> > therefore making them available on the standard .NET search path
> > --
> > Richard Siddaway
> > Please note that all scripts are supplied "as is" and with no warranty
> > Blog: http://richardsiddaway.spaces.live.com/
> > PowerShell User Group: http://www.get-psuguk.org.uk
> >
> >
> > "Jeremiah Buckley" wrote:
> >
> > > Hi, I searched for this on the forum but couldn't find anything.
> > >
> > > I loaded an assembly in powershell using:
> > > [reflection.assembly]::loadfrom((resolve-path
> > > D:\NET\Projects\Watchtower\Code\ECS.WatchTower.Testing.MessageSender\bin\Debug\ECS.WatchTower.Testing.MessageSender.dll))
> > >
> > > (the resolve-path call wasn't necessary, but it allows tab-completion)
> > >
> > > This assembly references some other .NET assemblies, which in turn reference
> > > some plain-old non-.NET .dlls. The load command is done without complaint,
> > > but when I try to create a new object, .NET attempts to load the required
> > > assemblies. Everything seems to load properly except for the non-.NET .dlls,
> > > which give the error:
> > >
> > > New-Object : Exception calling ".ctor" with "0" argument(s): "Could not load
> > > file or assembly '[name redacted], Version=1.0.0.0, Culture=neutral,
> > > PublicKeyToken=99e83667a1e13da9' or one of its dependencies. The system
> > > cannot find the file specified."
> > > At line:1 char:16
> > > + $b = New-Object <<<< ECS.WatchTower.Testing.MessageSender.MessageFactory
> > >
> > > Things that don't work:
> > > Copying the .dll into the same directory as the MessageFactory assembly.
> > > Registering the .dll
> > >
> > > I CAN fix this by copying the non-.NET .dlls into
> > > c:\windows\system32\windowspowershell\v1.0
> > > but, that's not a particularly good solution. Can anyone tell me what's
> > > going on, and why I have to use this workaround?
> > >
> > > Thanks,
> > >
> > > Jeremiah
> > >

"Jeremiah Buckley" <JeremiahBuckley@discussions.microsoft.com> wrote in
message news:68FB4981-9480-4C54-A5A3-D1DD4E18014C@microsoft.com...
> OK, I hear you, but it would be nice if I could put the .dll somewhere a
> little more logical (to me).
>
> It seems that .NET should check in the directory of the referencing
> Assembly, or something. Maybe that leads to outlandish discovery
> algorithms.
>
> Let me refine the question a bit: is there a way to keep the non-.NET .dll
> in the same location as the referencing .NET assembly and get .NET to
> notice
> it?

Try updating $env:Path - append the path of the dir where the DLLs are
located.

--
Keith