Issue with Resolve event about appdomaintoolkit HOT 7 CLOSED

Hey Lorenz, thanks for the thoughts! I'll give this a look over the weekend--until then I think you're work around is perfectly fine. You could theoretically right your own path resolver and support whatever custom loading you want--but I'll think through your use case and see if I can get a more abstract solution. Appreciate the props, and let me know if you have any other troubles.

from appdomaintoolkit.

I'm glad I saw this: I'm implementing a plugin framework using this toolkit. (Why did it take me a week to find this!? I was rolling my own..) As contract types shared between calling app, interop assembly, the plugins drift over time (ie: plugin interface evolves, etc), presumably I'll need all the references loaded from the plugin's folder/workspace. But this seems to open a new can of worms: backward compatibility for plugins..

from appdomaintoolkit.

There's a pull request for changes I've made to support better extensibility without having to fork the project.

1. AppDomainContext now requires 2 type parameters:
   a. TAssemblyTargetLoader (where : MarshalByRefObject, IAssemblyTargetLoader, new())
   b. TAssemblyResolver (where : MarshalByRefObject, IAssemblyResolver, new())
2. IAssemblyResolver gets 2 new properties:
   a. string ApplicationBase
   b. string PrivateBinPath
3. AppDomainContext sets these new properties rather than calling AddProbePath().
   (But in the same order as before)
4. PathBasedAssemblyResolver implementation calls AddProbePath(value) in setter to maintain backward compatibility.
5. New static AppDomainContext definition for no-hassle factory method definitions, also maintaining (most) backward compatibility. (**)

With this, we can create our own IAssemblyResolver that handles the ordering of the search paths (and their verification with DirectoryInfo, for example), plugging that type directly into the AppDomainContext. Previously, we would have to recreate the AppDomainContext as well.

Technically, I did not have to also expose TAssemblyTargetLoader to address this Issue, but felt it would be a good idea because others may indeed wish to extend that component. However, I stopped short of genericizing IAssemblyTargetLoader to allow piecemeal replacement of it's IAssemblyLoader component. I figured if you're going to replace one, it wouldn't be too much hassle to also replace the other (mostly since the code is available for them).

(**):
Type instance definitions will need to explicitly define the 2 new type parameters. To avoid this, I toyed with the idea of renaming the new generic type to something else and then just wrap the default-typed instance in a plain AppDomainContext. That would be fully backward compatible, but would either be a hassle or involve duplicating a lot of code and/or force AppDomainContext to be non-sealed.

from appdomaintoolkit.

Gentlemen,

Much appreciate all the work here. Pull request will be merged shortly.

from appdomaintoolkit.

very cool. thanks!
You may have already noticed, but I had to create a temp .snk, which you'll have to change back.
Does that also mean you'll push a new nuget version?

from appdomaintoolkit.

Yeah, I’ll do that later on today.

from appdomaintoolkit.

Awesome thanks :)

from appdomaintoolkit.