Groups | Blog | Home
all groups > dotnet remoting > july 2005 >

dotnet remoting : FileNotFound exception


peter
7/27/2005 12:00:00 AM
Hi Prodip

Can you give a bit more info. See below:

[quoted text, click to view]

Could you explain that a bit more. I'm not sure I follow what you're
saying here.

I simply configure the services through the configuration file. Thanks
[quoted text, click to view]

Should be in the system32 folder on the server. Yes?

[quoted text, click to view]

Which file is not found? The service executable? The remotable object dll?

Is it a file not found exception or an assembly load failure?

At what point is the exception thrown? On starting the service? On
instantiating the proxy? On calling a method on the remotable object?

[quoted text, click to view]

When a component asks to load a dll, the .NET Framework always checks
the GAC first. So if it can't find the component in the GAC, maybe the
strong name is different. For example, is the version number the same?
If you haven't fixed the version number in assemblyInfo.cs, it's going
to increment anything represented by a * each time you rebuild. I
always fix the version when I sign an assembly.

<snip />

I am clutching at straws a bit here though.

Cheers


Prodip Saha
7/27/2005 5:19:56 PM
Hi,
I have a wellknown remote service and it is hosted using windows service.
The windows service is generic and it does not have any reference to any
dll. I simply configure the services through the configuration file. Thanks
to Ingo Rammer for valuable clue on where to store the .config file if the
service is hosted by a Windows Service.

All works fine when the configured components are copied in the same
directory where Windows Service is running. These components are installed
in the GAC. So, obviously, I don't want to have the versioned dlls in this
directory. Instead, I want them to load from GAC. That's where problem
starts and I get FileNotFound error.

I checked the fusion log and it is trying to load from the Windows Service
directory. It is not probing in GAC. Why?

Here is the config file (simplyfied for readability):
<?xml version="1.0"?>
<configuration>
<system.runtime.remoting>
<customErrors mode="off" />
<application name="RemoteService">
<service>
<wellknown type="RemoteNamespace.RemoteService1, RemoteService1,
Version=1.0.1023.12345 Culture=neutral PublicKeyToken=mnh57202530r1g6f"
objectUri="RemoteService1.rem" mode="Singleton"
displayName="RemoteService1"/>
</service>
<channels>
<channel ref="tcp" port="9050">
<channelSinkProviders>
<serverProviders>
<formatter ref="binary"></formatter>
</serverProviders>
</channelSinkProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
<startup>
<supportedRuntime version="v1.1.4322"/>
<requiredRuntime version="v1.1.4322" safemode="true"/></startup>

</configuration>

I would appreciate your help. Thanks.
Prodip

Prodip Saha
7/27/2005 6:52:56 PM
Peter,
First, thanks for the response.

By generic, I mean, the Windows service has only one line of code in the
onStart(..) event. This part works fine and I don't have to have the
configuration file in the system32 folder.

RemotingConfiguration.Configure(AppDomain.CurrentDomain.SetupInformation.Con
figurationFile) ;

The actual error message is FileNotFound but it is attributed from faliure
to load the versioned assembly.

Client Code snippet (Factory pattern):
RemoteService1
proxy=(RemoteService1)Activator.GetObject(typeof(RemoteService1),"tcp://mach
inename:9050/RemoteService1.rem");
SomeotherClass oData=(SomeotherClass )proxy.CreateInstance(); //This is
where the call fails

_fusionLog "=== Pre-bind state information ===\r\nLOG: DisplayName =
RemoteService1 , Version=1.0.1023.12345 \n (Partial)\r\nLOG: Appbase =
c:\\program files\\blablabla\\remotingserviceshost\\\r\nLOG: Initial
PrivatePath = NULL\r\nCalling assembly : (Unknown).\r\n===\n\r\nLOG: Policy
not being applied to reference at this time (private, custom, partial, or
location-based assembly bind).\r\nLOG: Post-policy reference:
emc.sql.data.access, Version=1.0.1023.12345\r\nLOG: Attempting download of
new URL file:///c:/program
files/blablabla/remotingserviceshost/RemoteService1.DLL.\r\nLOG: Attempting
download of new URL file:///c:/program
files/blablabla/remotingserviceshost/RemoteService1/RemoteService1.DLL.\r\nL
OG: Attempting download of new URL file:///c:/program
files/blablabla/remotingserviceshost/RemoteService1.EXE.\r\nLOG: Attempting
download of new URL RemoteService1/RemoteService1/RemoteService1.EXE.\r\n"
string...

Just to mention- file:///c:/program files/blablabla/remotingserviceshost --
this is where my Windows Service.exe running from.

I have been working with the same version installed in GAC with other
ASP.NET applications and it is working perfect (I don't have dll in the bin
directory of the asp.net app). Interestingly, the same Remote Object works
from GAC if I host the Remote Object through Windows Application. It fails
only when I host the them with Windows Service!

Any further help will be appreciated. Thanks.
Prodip


[quoted text, click to view]

erick NO[at]SPAM csharpbox.com
7/28/2005 4:14:31 AM
[quoted text, click to view]

Is your remoted object's assembly in the same directory? I must say that
loading issues can occur from many differnt issues but i never had anything
similar.

Try this:

//Global scope
private static System.AppDomain domain = null;

public void Start(...)
{
domain = System.AppDomain.CurrentDomain;
domain.AssemblyResolve += new ResolveEventHandler(domain_AssemblyResolve);
// Your code.
}

private static System.Reflection.Assembly domain_AssemblyResolve(object sender,
ResolveEventArgs args)
{

if(args.Name.Equals("MyAssemblyName..."))
{
return System.Reflection.Assembly.LoadFile(path...);
}
// Put a break point here and look at 'args' to see what is
happening.
return null;
}


Erick Sgarbi

[quoted text, click to view]

Prodip Saha
7/28/2005 9:13:23 AM
Erick,
Interesting. Good news is- It works. I was able to load the dll from GAC but
I had to specify the physical location of the dll. This defeats the benefit
of loading the dll through configuration file.

args.Name was RemoteService1, Version=1.0.1023.12345 and that's what I have
specified in the configuration file. Since it is in GAC I did not specify
path anywhere.

So, what am I missing? I tried with <probing /> tag but it did not help. Any
more thoughts other than System.Reflection.Assembly.LoadFile(dllpathname) ?

Thanks,
Prodip


[quoted text, click to view]

Prodip Saha
7/29/2005 5:19:25 PM
My bad, I forgot to include the commas in the assembly name. The type must
be comma delimited.

Wrong:
<wellknown type="RemoteNamespace.RemoteService1, RemoteService1,
Version=1.0.1023.12345 Culture=neutral PublicKeyToken=mnh57202530r1g6f"
objectUri="RemoteService1.rem" mode="Singleton"
displayName="RemoteService1"/>

Correct:
<wellknown type="RemoteNamespace.RemoteService1, RemoteService1,
Version=1.0.1023.12345, Culture=neutral, PublicKeyToken=mnh57202530r1g6f"
objectUri="RemoteService1.rem" mode="Singleton"
displayName="RemoteService1"/>

Erick's suggestion worked but that's not the approach I wanted to go. When I
looked at the exception carefully, it says, the DisplayName=... Partial. I
immediately realized that somethings must be wrong with the name because the
probing NEVER even cared to look in the GAC!! Changed the assembly to name
to fully qualified name and, guess what?, it wroks. I don't make this kind
of BIG mistake but, I guess, I am a human too!!

Again, Suzanne Cook's blog is very helpful. Too much to read. Read with
patienc and it will probably get the result. See ref. at-
http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx

Cheer,
Prodip

[quoted text, click to view]

notifications NO[at]SPAM csharpbox.com
7/29/2005 7:37:41 PM
[quoted text, click to view]
Just to be clear, that wasnt a solution as I mention, it was quick way for
debugging which assembly your app was hitting before throwing the exception.

[quoted text, click to view]
We all are... :-)



Erick Sgarbi
www.blog.csharpbox.com

[quoted text, click to view]
peter
7/30/2005 10:49:14 AM
[quoted text, click to view]

Well, none of us spotted it either, so I guess that makes us all
fallible. No surprises there, then.

:)

Well done for finding it.

Best regards


AddThis Social Bookmark Button