> 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
