No difference. In fact, Activator.GetObject just calls RemotingServices.Connect and is provided for symmetry with Activator.CreateInstance.
-Mike DevelopMentor http://staff.develop.com/woodring > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Sean Chase > Sent: Monday, March 10, 2003 4:07 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Asynch Remoting Call Fails > (re: M. Woodring's example) > > > Hi Mike, > > You helped me out immensely a few weeks ago with the callback > via remoting > problem I was having with your example @ > http://staff.develop.com/woodring/dotnet/#RemoteEvents. I was > just curious > what the difference would be between using > RemotingServices.Connect as in > your example: > > ICalc c = (ICalc) RemotingServices.Connect(typeof(ICalc), > ConfigurationSettings.AppSettings["calcURL"]); > > ...and using Activator.GetObject like so: > > ICalc c = (ICalc) Activator.GetObject(typeof(ICalc), > ConfigurationSettings.AppSettings["calcURL"]); > > Any performance gains one way or the other? Is the process different? > > Thanks again! > > Sean > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of > Mike Woodring > (DevelopMentor) > Sent: Wednesday, February 12, 2003 3:28 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Asynch Remoting Call Fails > > > > I should have been using my course > > materials from the Guerrilla .NET class you taught in LA. :) > > > > I guess my eyes must have glazed over after the first 12 > hour day or > > something > > That must have been from the high-carb, -sugar, -fat, and > -caffeinated foods > (and maybe even alcohol) you consumed during the day - definitely not > because of our teaching style :-) > > > but...all I'm really trying to do is create a "hello > > world" type of remoting app using binary/tcp between the client and > > server with an asycn callback to the client. > > Once you iron our your assembly naming issue (see my other > reply) then you > can switch back to tcp/binary in your code easily enough. > You still won't > have a callback from the server to the client. You're use of > delegates just > means you're leveraging someone else's thread to make the > long blocking call > from the client to the server while you go off and do other > things. If you > totally eliminate your use of delegates in the code you > posted, you'd have > the same thing - just your main thread blocking instead of a > threadpool > thread. Either way, there's no callback being made from the > server to the > client. > > If you want a callback from the server to the client, then > you just need to > code that relationship in. For example, you might redefine > Server.TimeConsumingRemoteCall so that it's annotated with > the [OneWay] > attribute, returns void, and so that it takes a reference to > an interface > that your client class implements. The [OneWay] attribute > will prevent your > client from blocking until the method call makes it to the > server and back - > your client program will simply issue the request message to > the server and > return right away. Because it's a one-way method, only input > arguments are > supported (no out/ref or retval). Then when the server > finishes carrying > out the long operation, it can call back through the > interfaced passed as an > input parameter to the client, notifying you that the long > operation has > finished (and providing you with the results if you like). > > Alternatively, you can use an event-based callback model instead of an > interface-based callback model. In either case, you'll need > to make sure > that the server program has access to the "right" amount of metadata > describing the client interface/class. If you go with an > interface that's > defined in it's own dll then this is easy - as both the > client & server > programs will have access to the library (the client because it's > implementing the interface, the server because it's > programming against the > interface). If you use an event, you'll need to work around > some assembly > resolution issues a little more. I have a sample > demonstrating one such > work around here[1]. > > Also, in either scenario you can change the client to pass 0 to the > constructor for the http/tcp channel so that a random unused port is > selected. No need to hard code the port number used by the > client to accept > callbacks. Only the server's port needs to be well known. > > -Mike > DevelopMentor > http://staff.develop.com/woodring > > [1] http://staff.develop.com/woodring/dotnet/#RemoteEvents > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com > You may be interested in Guerrilla .NET, 24 March 2003, in London > http://www.develop.com/courses/gdotnet > > View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com You may be interested in Guerrilla .NET, 24 March 2003, in London http://www.develop.com/courses/gdotnet View archives and manage your subscription(s) at http://discuss.develop.com
