The type you list in your <wellknown> element needs to have the namespace also.
<wellknown mode="SingleCall" type="ECCFileRequest.FileRequest, ECCFileRequest" objectUri="FileRequest" /> I can't guarantee that it is the only problem, but definitely one. -----Original Message----- From: Sean Chase [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 9:40 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Problems remoting using a config file I'm probably missing something simple, but I was wondering if anyone has come across something like this in their own endeavors.... I have a Windows Service (named FileRequestService) that hosts a remotable class (FileRequest) from another assembly (ECCFileRequest). The Windows Service assembly name is ECCSIRequest, the class library with the remotable class is in an assembly named ECCFileRequest just to clarify. For some reason, I when I try to load remoting configuration (as in the code below), my clients cannot connect to the service: string cfg = System.IO.Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "ECCSIRequest.exe.config"); RemotingConfiguration.Configure(cfg); However, if I programatically set the channel and use RegisterWellKnownServiceType (as in the following code), the clients can successfully connect. Again, I'm sure I'm missing something simple as far as defining the appropriate names or TCP "URL", but I'm just not seeing what it is. Here's the code that will work: _tcp = new TcpChannel(999); ChannelServices.RegisterChannel(_tcp); RemotingConfiguration.RegisterWellKnownServiceType(typeof(ECCFileRequest .Fil eRequest), "FileRequest", WellKnownObjectMode.SingleCall); I'm not sure what I'm missing. Any ideas? I included more detailed info (config files for client and server, and some code) below if anyone is up for taking a look. Thanks! The config file (ECCSIRequest.exe.config) for the Windows Service looks like this: <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application name="FileRequest"> <service> <wellknown mode="SingleCall" type="FileReqest, ECCFileRequest" objectUri="FileRequest" /> </service> <channels> <channel ref="tcp" port="999"> <clientProviders> <formatter ref="binary" /> </clientProviders> <serverProviders> <formatter ref="binary" /> </serverProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration> The test client code looks like this: RemotingConfiguration.Configure("ConsoleApplication17.exe.config"); ECCFileRequest.FileRequest fReq = (FileRequest) RemotingServices.Connect(typeof(FileRequest), ConfigurationSettings.AppSettings["RequestURL"]); Console.WriteLine(fReq.GetXMLFileList(@"somefile.txt")); The test client config file looks like this: <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="RequestURL" value="tcp://localhost:999/FileRequest"/> </appSettings> <system.runtime.remoting> <application name="ConsoleApplication17"> <channels> <channel ref="tcp" port="0"> <clientProviders> <formatter ref="binary" /> </clientProviders> <serverProviders> <formatter ref="binary" /> </serverProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration> The exception being thrown is: Cannot load type FileReqest, ECCFileRequest. Server stack trace: at System.Runtime.Remoting.RemotingConfigInfo.LoadType(String typeName, Strin g assemblyName) at System.Runtime.Remoting.RemotingConfigInfo.StartupWellKnownObject(String a smName, String svrTypeName, String URI, WellKnownObjectMode mode, Boolean fRepla ce) at System.Runtime.Remoting.RemotingConfigInfo.StartupWellKnownObject(String U RI) at System.Runtime.Remoting.RemotingConfigHandler.CreateWellKnownObject(Stri ng uri) at System.Runtime.Remoting.IdentityHolder.CasualResolveIdentity(String uri) at System.Runtime.Remoting.Messaging.MethodCall.ResolveType() at System.Runtime.Remoting.Messaging.MethodCall.ResolveMethod(Boolean bThrowI fNotResolved) at System.Runtime.Remoting.Messaging.MethodCall..ctor(Object handlerObject, B inaryMethodCallMessage smuggledMsg) at System.Runtime.Serialization.Formatters.Binary.BinaryMethodCall.ReadArra y( Object[] callA, Object handlerObject) at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize( He aderHandler handler, __BinaryParser serParser, Boolean fCheck, IMethodCallMessag e methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deseriali ze (Stream serializationStream, HeaderHandler handler, Boolean fCheck, IMethodCallM essage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deseriali ze (Stream serializationStream, HeaderHandler handler) at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMes sa ge(String objectUri, Stream inputStream, Boolean bStrictBinding) at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessag e( IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders reques tHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& respon seHeaders, Stream& responseStream) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req Msg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa ta, Int32 type) at ECCFileRequest.FileRequest.GetXMLFileList(String directory) in c:\document s and settings\zb5897\my documents\visual studio projects\eccfilerequest\filereq uest.cs:line 73 at ConsoleApplication17.Class1.Main(String[] args) in c:\documents and settin gs\zb5897\my documents\visual studio projects\consoleapplication17\class1.cs:lin e 31
