0

I have a .NET class library which I need to load to a separate domain and execute some code from it. Right now I am using AppDomain.CreateInstanceFrom to create a remoting object and unwrap it using some interface. But what alternatives do I have? Remoting is kind of obsolete technology.

Bogdan Verbenets
  • 25,686
  • 13
  • 66
  • 119

1 Answers1

1

Remoting is fine for cross-AppDomain, but the other approach is to pretend they are different processes on the same machine, or different machines.

For example, you could use a basic socket-server between the two, or something like WCF or Service Stack operating on a named-pipe (or similar). Or flat files in a known location and polling. Or a database table as a queue. Or a dedicated messaging stack - anything from MSMQ to redis pub/sub. Or a http server (HttpListener maybe) and client (WebClient maybe). Go wild.

Personally, I'd be tempted to stick with remoting if it works, though. Note I only say this between app-domains, in the way laid out in your post - I wouldn't personally use remoting between processes/machines.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • No, creating another process is not what we need. And if we think WCF for example, then we need to configure the WCF host, and for this we need to call something in another AppDomain. So we are back to Remoting again. – Bogdan Verbenets Aug 09 '12 at 10:07
  • @BogdanVerbenets not necessarily; it could have a pre-decided endpoint, for example - or it could be available in the config file. But frankly, I'm unclear what "problem" you are trying to solve - for inter-AppDomain calls, remoting isn't too ugly. – Marc Gravell Aug 09 '12 at 10:15