Allright, I think I found the answer to my issue, with some help from
Reflector. The issue seems to be in the constructor of the
System.Runtime.Remoting.WellKnownClientTypeEntry class:
public *WellKnownClientTypeEntry*(Type
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=1> type, string
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=2> objectUrl)
{
this._appUrl <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=3> =
null;
if (type == null)
{
throw new ArgumentNullException
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=4>("type");
}
if (objectUrl == null)
{
throw new ArgumentNullException
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=5>("objectUrl");
}
base.TypeName <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=6> =
type.FullName <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=7>;
base.AssemblyName <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=8> = type.Module
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=9>.Assembly
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=10>.nGetSimpleName
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=11>();
this._objectUrl
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=12> = objectUrl;
}
As you can see, the AssemblyName property is set to the Simple Name of
the type being created. So, later on when the Remoting helper (again,
from [1]) tries to accesss the ObjectType it fails. Here is the code
for the ObjectType property:
public Type <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=1>
*ObjectType*
{
get
{
StackCrawlMark <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=2>
*mark1* = StackCrawlMark
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=3>.LookForMyCaller
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=4>;
bool <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=5>
*flag1* = false;
return RuntimeType <http://www.aisto.com/roeder/dotnet/Default.aspx?Object=6>.GetTypeImpl
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=7>(base.TypeName
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=8> + ", " + base.AssemblyName
<http://www.aisto.com/roeder/dotnet/Default.aspx?Object=9>, false, false, ref mark1, ref flag1);
}
}
Because the Interface assembly is in the GAC GetTypeImpl requires a
fully-qualified assembly name rather than a simple assembly name, and
thus fails.
If I remove the offending GAC'ed Interface assembly from my client
remoting configuration file, and introduce some code-based remoting
configuration that properly sets the AssemblyName to the fully-qualified
assembly name, like so:
Type t = Type.GetType(@"MyNameSpace.IRemotingInterface,
RemotingInterface, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=01302c4325c0c4f5");
WellKnownClientTypeEntry entry = new
WellKnownClientTypeEntry(t, @"tcp://localhost:5555/RemotingService.rem");
entry.AssemblyName = t.Module.Assembly.FullName;
RemotingConfiguration.RegisterWellKnownClientType(entry);
Things start working just fine.
Does anyone know whether this is a bug in the Remoting code, or whether
it was a design decision?
Thanks,
Craig
[1]
http://www.thinktecture.com/Resources/RemotingFAQ/USEINTERFACE
SWITHCONFIGFILES.html
Craig Vermeer wrote:
I don't think that's it, actually. I think it has to do with the
client-side remoting configuration, instead.
I did try what you suggested, though. In my case the
RemotingServiceImpl class was defined in a Windows Service executable.
So, I refactored it out into a library assembly that was strongly-named,
and installed it into the gac. However, even after trying this I still
had the same issue with the Interface assemblies not being in the local
bin of the client executable.
They key to me seems to be in the client configuration:
<client>
<wellknown type="MyNamespace.IRemotingService,
RemotingInterface" url="tcp://localhost:5555/RemotingService.rem" />
</client>
If the RemotingInterface assembly is installed in the GAC, but not in
the private bin directory of the client things fail. I've tried fully
assembly-qualifying the type of the interface in the client
configuration, but Remoting Configuration throws an exception telling me
I'm not allowed to specify version info in a client configuration node
in this case.
I ran across a newsgroup posting where someone was having the same
issue, but they weren't able to get things solved even with Ingo
Rammer's help :-/
http://dotnet247.com/247reference/msgs/20/101559.aspx
Richard Blewett wrote:
You need to fully qualify the aseumbly name in the wellknown element
<wellknown mode="Singleton"
type="MyNamespace.RemotingServiceImpl, RemotingService,
Version=1.0.0.0,
Culture=neutral, PublicKeyToken=1243fac112caaaa"
objectUri="RemotingService.rem" />
Regards
Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of
Craig Vermeer
Sent: 06 June 2005 16:43
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: [ADVANCED-DOTNET] Interface-based Remoting and
GAC'ed Assemblies
Hi All,
I was hoping someone might be able to help with this issue.
We're using an Interface-based remoting architecture
described here [1]. Everything works just fine as long as
the assembly containing our interface definitions is located
in the private bin directory of our client applications. As
soon as we put the Interface assembly into the GAC and remove
it from the client bin directory, the client can no longer
locate the WellKnownType of the remotable object.
For reference, our Server config file looks something like this:
<service>
<wellknown mode="Singleton"
type="MyNamespace.RemotingServiceImpl, RemotingService"
objectUri="RemotingService.rem" />
</service>
And our Client config looks something like this:
<client>
<wellknown type="MyNamespace.IRemotingService,
RemotingInterface"
url="tcp://localhost:5555/RemotingService.rem" /> </client>
RemotingServiceImpl implements the IRemotingService
interface. The way this issue manifests itself is within the
RemotingHelper class described in [1]: the
RemotingConfiguration.GetRegisteredWellKnownClientTypes call
returns zero types.
I have an idea as to _why_ it's not able to locate the types;
however, I'm at a loss as to how to resolve the issue without
moving away from the Interface-based design or without
resorting to configuring the client in code.
Thanks in advance,
Craig
[1] :
http://www.thinktecture.com/Resources/RemotingFAQ/USEINTERFACE
SWITHCONFIGFILES.html
===================================
This list is hosted by DevelopMentorR http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
