Use case: I want a client to be a shell, and as basic as possible. Really just a vehicle to ask a server for code to run.
- The client asks for code to run from either a web page or web service. - The server responds with an assembly, transferring it in it's entirety over the network. - The client receives the assembly, and a little metadata about when to run, what to expect out, timeout value, location of needed files on network, etc. I'd like any dll's or other files to accompany it. - The client kicks off the assembly, which does some work. The assembly will return status periodically to the client either when asked or periodically, as well as signaling completion. - The client transmits the result of the work back to the server (or perhaps the guest assembly did this itself). - The client then deletes all traces of the job, and asks for another. Think grids, and you're real close. My question to you all is what is the best mechanism to support the running of, and communication with, an assembly kicked off by a continually running process (client) when the assembly will not be known at compile time? Any suggestions? Have you heard of anyone doing something like this before? TIA! pat :) P.S. And before you say that it would be better to have all possible code compiled into the client; It isn't. I'd rather change 1 piece of code at the server than upgrade many clients. :)
