Assume the following scenario:

c:\a\remoteclient.exe

c:\b\remote_c.dll
c:\b\remote_r.dll

remoteclient makes remoting calls through remote_c.dll. Some remote
interfaces are in remote_r.dll, and are only instantiated on return from
the remoting call.

Under the above scenario, I'm getting a remoting exception "The system
cannot find the file specified" because on the client side, the
remote_r.dll assembly can't be located.

At this point, I don't want to modify remoteclient.exe or its config
file, I can't install the assemblies to the GAC, but I can modify
remote_c.dll.

Is there a way to accomplish what I need so that the remote_r.dll
assembly can be located at runtime by the framework, even though it
isn't in the same folder as the .exe?

Thanks for any help

Peter Franks <none (AT) none (DOT) com> wrote in news:dZoFg.14145$lv.5985@fed1read12:

ASP.NET's 2.0 ClickOnce Deployment MAY help - it can dynamically download
assemblies as needed from a remote server.

You can do the same in .NET 1.1, although it's not as sleek nor documented
as well.

Spam Catcher wrote:
Thanks for the info, but can't use a remote server as well. Binaries
pretty much have to stay where they are.

I did subsequently run across private bin and probe configuration
(either through the exe .config or manual specification in code), but
neither of those work because those folders must hang off of the .exe
folder...

It is starting to look like there is no solution.

Peter Franks wrote:

Are you sure it's /remote_r/ that the client can't find?
From the little I understand about how the Framework finds things, if
you've managed to load remote_c into the client program, then it
/should/ be able to locate any other, dependent assemblies in the /same/
directory (as remote_c).

Of course, if it can't find remote_c /either/, that's another story.

Normally, you'd configure this with "dependentAssembly" and "codebase"
entries in the client's .exe.config (these /can/ be relative paths, if
you want). I'm not sure why you're trying to avoid using these...

HTH,
Phill W.

Phill W. wrote:
Right -- remote_r.

Here is a little more:

suppose the following in remote_c:

public class WidgetFactory
{
public Widget CreateRemote(string server)
//...
}

and the following in remote_r:

public class Widget
{
//...
}

and finally the following in remoteclient:

using remote_r;
using remote_c;

//...
WidgetFactory factory = new WidgetFactory();
Widget widget = factory.CreateRemote("myserver"); // dies here


The execution of the above will die in that last call on the return as
the object is deserialized -- the remote_r assembly can't be located, by
the remoting framework, therefore the instance of Widget can't be
instantiated.

Even though remote_r is loaded in the process space of remoteclient, it
isn't used because it lies outside of the folder hierarchy of remote client.

Specifying the probe or private binary directories in the .config fail
for the same reason -- the assembly lies outside of the remoteclient.exe
hierarchy and therefore aren't found/used.

I'm presuming that this has to do w/ security in that only assemblies
that are within the folder hierarchy OR are in the GAC can be used by
the remoting framework on deserialization, but I haven't found anything
definitive that states this.

So, I guess that I'm out of luck on my original requirement, and will
have to find an alternative.

Peter Franks wrote:
So if your Client's directory structure is something like ...

C:\
a\ remoteclient.exe
b\ remote_c.dll, remote_r.dll

.... how does remoteclient.exe find either of the Dll's?

I'd set up my .exe.config with a relative code base
("..\Res\remote_c.dll" ) and whichever one got loaded first, the
Framework would then automatically pick up the other from the same
directory.

Or, possibly, this is a different problem.

You say that it's complaining at the point of deserialising the Widget.
Could it be that the client and server ends of the Remoting "pipeline"
are using different "versions" of remote_c (or _r)? If the Assembly
Versions (name, version, culture & PublicKey) aren't /identical/ at both
ends, then the Framework will see the serverside Widget as a totally
separate entity to the clientside one. Indeed, the client process will
go and try to find the /server-side/ definition (assembly) of a Widget,
because that's what it's been passed (albeit in a serialised form)
which, of course, it can't find on the client.

HTH,
Phill W.

Phill W. wrote:

Assembly and location are passed on the command line, something similar to:

remoteclient.exe c:\a\remote_c.dll

The .config codebase values /must/ be at or lower in the hierarchy.
Absolute and relative paths that are above will not be searched.

The versions are the same on the client and server.

If I copy the remote_c and _r dlls to the remoteclient.exe folder,
everything works, it only fails when the assemblies are in a different
folder not in the hierarchy.

The real-world example of this is through unit tests. Unless NUnit (or
similar tool) is in the same folder as the assemblies (or conversely,
the assemblies are in the same folder as NUnit), remoting tests will
fail if the remote call returns an instance of an application-defined
class. In our case, we have resorted to copying NUnit.exe to the
application bin folder (post build event) and run the tests from there.
Obviously not optimal, but about the only option that we have...

Thanks for the comments.

Peter Franks wrote:
Really?
I use .exe.config's like this all the time: (note the codeBase href)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity
name="A.B.C.XYZ"
publicKeyToken="1a2b3c4d5e6f7g8h"
culture="neutral"
/>
<codeBase
version="1.0.0.0"
href="..\System\A.B.C.XYZ.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

Sorry to say it, but it works for me ... ;-)

HTH,
Phill W.

Phill W. wrote:
Interesting, wouldn't work for me. I'd get an error in the Fusion Log
that (in so many words) said "NOT SEARCHED". Using .Net 2.0.

I was never able to find anything in the docs about the path
requirements, but no surprise, help search engine sux*100.

Peter Franks wrote:
That's worrying, because I rely rather heavily on that working and if it
gets "broken" by Fx 2.0 ... :-(

Regards,
Phill W.