ReflectionOnlyLoad can it be garbage collected?

Question

I want to "hot" load some pre-packaged assembli(es) into a separate AppDomain, the thing however is I do not know the name of the entry point class or even the assembly file. I need to find this entry point so I can run some initialization routine.

So what I intend to do is to run ReflectionOnlyLoad on all the files and find the one that follows a certain convention ie. annotated/implements a certain interface etc.

Question is, will I start leaking memory if I were to run ReflectionOnlyLoad from the main AppDomain over and over? If this can't be run from the main app domain, what are my options, because again I do not know where the entry point is.

Also any additional information about the subtleties in using ReflectionOnlyLoad is appreciated.

In my experience ReflectionOnlyLoad is very annoying to work with. I'd look into `Mono.Cecil` instead. — CodesInChaos, Jun 21 '12 at 16:37

score 3 · Accepted Answer · edited May 23 '17 at 10:30

I recommend Mono.Cecil. It's a simple assembly you can use on .net (it doesn't require the Mono runtime). It offers an API to load assemblies as data, and works pretty well. I found the API easy to work with, and it suffered from none of the problems I experienced when using reflection-only-load.

You can also use CCI, which is an open source project by MS that offers an assembly reader.

See also: CCI vs. Mono.Cecil -- advantages and disadvantages

score 1 · Answer 2 · answered Jun 21 '12 at 16:36

1

ReflectionOnlyLoad won't solve your problem, see docs

Why don't you execute the code for finding the entry point etc. in the new AppDomain?

answered Jun 21 '12 at 16:36

Onkelborg

3,927
1
19
22

Because I don't have the concrete type. I only have the abstraction. The concrete type is supposed to be implemented in the package but I don't know what the the implementer is called. I am not hoping for ReflectionOnlyLoad to solve it all, I also intend to use MarshallByRefObject. All I need is to get the FullName of the concrete type so I can instantiate the remote object. – Alwyn Jun 21 '12 at 17:02
1

If you are able to find the entrypoint in the default AppDomain then you should be able to find it if you execute the code in another AppDomain. – Onkelborg Jun 21 '12 at 18:02
No I cannot find it. The entry point class does not exist in the default AppDomain. It's basically akin to being able to run some arbitrary code as long as the so said code follows a certain convention. – Alwyn Jun 21 '12 at 20:38
1

I don't follow you, are you, or are you not, able to find the entry point through code, somehow? If not, then you can't do what you want to do. If you do, then you can execute that code in the new AppDomain. – Onkelborg Jun 22 '12 at 07:31

score 0 · Answer 3 · answered Jun 22 '12 at 15:58

Cannot reflect through the dlls. Even with reflection only load, the type sticks to the main AppDomain.

2 Solutions:

Put the entry point in an xml somewhere and parse that.
Use a 2 stage AppDomain, one for the reflector, and then another for the actual object.

I picked (1) since it's the most sensible.

(2) I have to pass through 2 separate proxies in order to issue command to the actual remote object, that or I need to couple the interfaces much more closely than I like. Not to mention being a pain to code.

No but that looks like a possible solution. I just wasn't sure since I want to live strictly in the msft .net world to avoid potential conflicts. — Alwyn, Jun 22 '12 at 19:51

ReflectionOnlyLoad can it be garbage collected?

3 Answers3

Linked