CODEWITHSUNDEEP
c#configappdomain
HardTouch
HardTouch

Reputation: 69

C# Accessing configuration of another process (Cross Domain Access)

I have a software that loads different libraries at runtime upon the selection of the user. Currently, those libraries are loaded in the same domain of the parent process. I access the configuration of the main software from the classes inside these libraries and set some properties depending on the config.

This task is not a problem as I can access the running config of the main software by :

AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

However I'm planning to load these libraries in another domain and want to learn if it is possible to access the config of the calling process. I'm thinking of memory access restrictions may cause problems and have never tried such thing before. Is it possible? Thanks in advance.

Upvotes: 1

Views: 249

Answers (1)

user585968
user585968

Reputation:

However I'm planning to load these libraries in another domain and want to learn if it is possible to access the config of the calling process

Yes it's possible. Two objects in different App Domains talk to each other via .NET Remoting.

When you create your child AppDomain say via a Manager class, you create some form of proxy object (let's say MyChildDomainProxy) in the child domain. This proxy allows Manager to perform operations on objects in the child domain such as loading the library. You don't want the primary App Domain loading the libraries.

When you invoke methods on the proxy the call stack travels from the manager object to the proxy crossing AppDomains over .NET Remoting in the same Windows process. The trick is to ensure the proxy class derives from MarshalByRefObject. This makes objects act a bit like COM where methods are invoked on the objects themselves rather than be serialised over the wire.

public class MyChildDomainProxy : MarshalByRefObject 
{
    public void LoadLibrary (string path) {...}
}

Conversely, your Manager object in the Primary AppDomain can expose a type derived from MarshalByRefObject that your proxy can call thus allowing for two-way communications between AppDomains.

AppDomain Best Practices

One of the purposes of AppDomains is to isolate or protect one domain from another. Generally you don't want code from one to leak into another. By that I mean you want to restrict the return types from a proxy object and not include types from 3rd party code. You don't want them being deserialised or finalised in the primary app domain. Depending on what you are doing, you may not even want 3rd party types being mentioned as return types to the primary app domain because the finaliser may execute in the primary domain thus becoming a security risk!

  • What are these libraries you are loading?
  • Are they trustworthy?
  • Do you really want child domains calling into the primary domain?
  • Are you wanting to look into Code Access Security (CAS)?

if the intent is to create some form of sandboxing or plug-in system then you never want child domains calling into the primary.

More

Upvotes: 1

Related Questions