Vista - Trouble when .NET Remoting needs to locate an assembly

I'm writing a PowerShell Provider that will expose the data from an existing
application and server. The existing applcation has a shared DLL that
contains the objects that are serialized and interfaces to the server
objects. Communication between the client and server is done with .NET
Remoting.

The shared DLL has a strong name and is in the same directory as the
Provider DLL. The Provider doesn't have any problem locating the shared DLL
however, when the .NET Remoting layer attempts to deserialize an object, it
trys to load the shared DLL and fails. When the Remoting layer is probing
for shared DLL, it believes that it's application base is
C:\Windows\System32\WindowsPowerShell\V1.0\ which is the base for
powershell.exe and it's calling assembly is "unknown".

Is there something that my provider can do to affect the directories being
searched? I've tried calling AppDomain.AppendPrivatePath (which is
depricated) but, the assembly resolver refuses to consider the path that I
add because it isn't a subdirectory of
C:\Windows\System32\WindowsPowerShell\V1.0.

I think I could solve this by adding my assemblies to the GAC but, I would
like to avoid that. As a test, I copied the shared DLL to
C:\Windows\System32\WindowsPowerShell\V1.0 and it solved the problem but, I
don't think that's a viable solution for a commercial product.

Any ideas would be appreicated.

Thanks,

John Vottero

If you're interested, the following are two logs from fuslogvw, the first is
a successful load when my provider needs the shared DLL and the second is a
failure from when .NET Remoting tries to find the same DLL:

A successful load of JAMSShr because the run-from-source is
JAMS.Commands.dll

*** Assembly Binder Log Entry (10/23/2006 @ 6:28:04 PM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = GRAPE\Administrator
LOG: DisplayName = JAMSShr, Version=4.2.28.0, Culture=neutral,
PublicKeyToken=7da961def3057cf2
(Fully-specified)
LOG: Appbase = file:///C:/WINDOWS/system32/WindowsPowerShell/v1.0/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : JAMS.Commands, Version=4.3.563.0, Culture=neutral,
PublicKeyToken=7da961def3057cf2.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will
only be probed in default load context, like with Assembly.Load().
LOG: No application configuration file found.
LOG: Using machine configuration file from
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: JAMSShr, Version=4.2.28.0, Culture=neutral,
PublicKeyToken=7da961def3057cf2
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL
file:///C:/WINDOWS/system32/WindowsPowerShell/v1.0/JAMSShr.DLL.
LOG: Attempting download of new URL
file:///C:/WINDOWS/system32/WindowsPowerShell/v1.0/JAMSShr/JAMSShr.DLL.
LOG: Attempting download of new URL
file:///C:/WINDOWS/system32/WindowsPowerShell/v1.0/JAMSShr.EXE.
LOG: Attempting download of new URL
file:///C:/WINDOWS/system32/WindowsPowerShell/v1.0/JAMSShr/JAMSShr.EXE.
LOG: Attempting download of new URL
file:///C:/LocalPrj/JAMS/JAMS.Commands/bin/Debug/JAMSShr.DLL.
LOG: Assembly download was successful. Attempting setup of file:
C:\LocalPrj\JAMS\JAMS.Commands\bin\Debug\JAMSShr.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: JAMSShr, Version=4.2.28.0, Culture=neutral,
PublicKeyToken=7da961def3057cf2
LOG: Where-ref bind Codebase does not match what is found in default
context. Keep the result in LoadFrom context.
LOG: Binding succeeds. Returns assembly from
C:\LocalPrj\JAMS\JAMS.Commands\bin\Debug\JAMSShr.dll.
LOG: Assembly is loaded in LoadFrom load context.




Failure from .NET Remoting layer:

*** Assembly Binder Log Entry (10/23/2006 @ 6:30:49 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = GRAPE\Administrator
LOG: DisplayName = JAMSShr, Version=4.2.28.0, Culture=neutral,
PublicKeyToken=7da961def3057cf2
(Fully-specified)
LOG: Appbase = file:///C:/WINDOWS/system32/WindowsPowerShell/v1.0/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr =
0x80070002).

this is a issue that has been in the back of my mind for months.. for
we don't want the powershell directory becoming like the system32
directory or worse..

the problem is not just in the case of hostapp DLL resolving, but also
for cases when your DLL's snapins etc have to have app.config
settings.. (and some of those are i.e settings for system.net namespace
etc, things that you can't just put somewhere else).. here you have to
edit the powershell.exe.config file, since powershell is the actual
host..

I'm not sure what hte best workarounds (if any) are for these group of
issues, and i think that microsoft needs to come up with some sort of
guidance at least.
'
Karl

George Santayana once said "Those who do not remember the past are condemned
to repeat it". That's exactly what we have here. The issue is not that the
PS developers don't remember the past, but that the .NET guidance doesn't -
or at least ignores the case of scripting using external objects, pretending
that applications are always monolithic and can carry needed assemblies with
them.

I've been worrying about this for a couple of years, and it looks like the
solution once again is a general well-known name that allows easy
find-and-load such as that done with late-bound scripting languages. I don't
know how we can resolve the app.config issue in all cases, but I've been
working on some techniques for secondary cmdlet resolution that may be
possible.

It's also worth noting that a couple of the stronger bits of guidance from
the .NET development team are NOT appropriate for administrative scripting -
and to be fair, they do say this. The most significant 2 in my opinion:

(1) It IS acceptable to GAC assemblies for easy access. If you look at .NET
dev blogs, you'll soon notice that they've always said this is something
admins should be able to do for convenience.

(2) Partial name binding is acceptable and even appropriate for script use.
Script tools are often at the end of a large toolchain and may use several
different objects; they are not re-written and deployed every time a
specific DLL is updated, and since they are not compiled they are not
thoroughly tested against specific DLL versions automatically anyway.

<klumsy@xtra.co.nz> wrote in message
news:1161646837.429669.182340@h48g2000cwc.googlegroups.com...
> this is a issue that has been in the back of my mind for months.. for
> we don't want the powershell directory becoming like the system32
> directory or worse..
>
> the problem is not just in the case of hostapp DLL resolving, but also
> for cases when your DLL's snapins etc have to have app.config
> settings.. (and some of those are i.e settings for system.net namespace
> etc, things that you can't just put somewhere else).. here you have to
> edit the powershell.exe.config file, since powershell is the actual
> host..
>
> I'm not sure what hte best workarounds (if any) are for these group of
> issues, and i think that microsoft needs to come up with some sort of
> guidance at least.
> '
> Karl
>