Peter,
"OnStart doesn't call RemotingConfiguration.Configure(). It must be
a sample from that book doing so."
It's a sample from every book I've read on remoting that does so.
Remember that I'm concerned about services that host remote objects (as
I said in an earlier post - but you may have missed that).
I didn't miss that. One may call RemotingConfiguration.Configure()
from OnStart, but this is not a rule.
"It is true that the working directory of a service is system32.
Hoewever, Rammer's advice to put the remoting into system32 is
pretty weird."
Not the remoting - if by that you mean the executable - but rather the
app.config file for the service hosting the remote object.
Sorry, I missed a word: "remoting config".
Once again, Rammer is not on his own. In my post I also quoted from
Conger, "Remoting with C# and .NET", which gives exactly the same
advice. I also know that the same advice is given in textbooks for the
Microsoft MCSA exams. I'll find the quotes tonight when I'm at home, if
you like.
Thanks, but I know how it works. They probably crib from each other ;-)
"You should use that. If simply loads the remoting configuration
from the app.exe.config of your app, regardless of the current
directory."
OK. I'll play with that. The property has to be set, of course, which
means hard coding a path into code, which is something I like to avoid
where I can, but it doesn't seem too much of a risk in this situation.
Thank you.
The property has not to be set (and cannot be set, unless a new
app domain is created).
It defaults the to the absolute path name of the app.exe.config,
and that's exectly what it's needed for RemotingConfiguration.Config (),
which otherwise tries to pick the file from the current directory.
Rob
_______________________________________________
Mono-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list
