I am just going to reiterate what Mike was saying - IIS is not doing anything to host your object on a TCP channel. It is only starting the ASP.Net worker process, which just happens to call RemotingConfiguration.Configure(). It is no different than you creating an exe and calling Configure().
I see one problem with your code. You are using DBRemote.rem as the URI for the remote object. But the remote object is available as DBRemote.soap. So change this line under the TCPChannel string url = "tcp://" + Server + ":8080/DBRemote/DBRemote.rem"; to string url = "tcp://" + Server + ":8080/DBRemote/DBRemote.soap"; The only reason you need the .soap extension is so IIS can use the HTTPHandler registered for the .soap extension. In the case of the TCPChannel, it doesn't really matter what the extension is. IIS is in no way involved with hosting your object on the TCPChannel. Hope this helps Deepak > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of > Peter Laan > Sent: Saturday, April 13, 2002 9:37 AM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] Remoting on Tcp and Http > > Thanks for all the info Mike! > > However, I'm still not convinced. The help files clearly state that it's > not possible and I can't get it to work. I tried with the following > web.config file: > > <configuration> > <system.runtime.remoting> > <application> > <service> > <wellknown mode="SingleCall" > type="AncalagonSoftware.Levels.DBRemote.DBRemote, DBRemote" > objectUri="DBRemote.soap" /> > </service> > <channels> > <channel ref="http"></channel> > <channel ref="tcp" port="8080"></channel> > </channels> > </application> > </system.runtime.remoting> > </configuration> > > It works fine if the client uses Http like this: > > HttpChannel channel = new HttpChannel(); > ChannelServices.RegisterChannel(channel); > string url = "http://" + Server + "/DBRemote/DBRemote.soap"; > remote = (DBRemote.DBRemote) > Activator.GetObject(typeof(DBRemote.DBRemote), url); > > But I get an exception ('No connection could be made because the target > machine actively refused it') if I try with Tcp. > > TcpChannel channel = new TcpChannel(); > ChannelServices.RegisterChannel(channel); > string url = "tcp://" + Server + ":8080/DBRemote/DBRemote.rem"; > remote = (DBRemote.DBRemote) > Activator.GetObject(typeof(DBRemote.DBRemote), url); > > Have anyone actually tried it and seen that it works? > > >From the help file: > ms- > help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconhostingremoteobjectsininterne t > informationservicesiis.htm > > a.. You cannot use any channel other than the HttpChannel. > Note Do not specify a port for any channels listed here; if you want > your application to listen on a particular port, you specify this by using > Internet Services Manager to have IIS listen on that port. The channel you > configure will automatically be used to handle remote requests submitted > on > that port. > Peter > > > From: "Mike Woodring" <[EMAIL PROTECTED]> > > I suppose I should explicitly mention, if it wasn't obvious from my > > description, this means that it all depends on how you interpret "using > tcp > > with IIS". > > > > If your server code is behind a firewall that only allows http traffic > > through port 80, and all the clients are on the "other" side of the > > firewall, then you "can't use tcp with IIS", because IIS will only > handle > > http traffic. > > > > If, OTOH, your server code is behind a firewall that only allows http > > traffic through port 80, but some clients are outside the firewall while > > others are inside the firewall, then those clients outside can use http > to > > get to your server, while those inside the firewall could use tcp to > talk > to > > the same object. > > > > And if, like me here in my home office :-), you can arbitrarily pick > ports > > (or your admin will agree to open one) then you could do what I did and > > allow anyone to use http or tcp to get the same object. > > > > -Mike > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.