Get or load plugin assembly (instead of always loading) #499
Conversation
…y loaded in the current AppDomain instead of calling AppDomain.Load right away. This prevents AppDomain.Load from failing in cases when the plugin assembly is already loaded in the AppDomain and not present in the standard search locations.
|
Thanks a mill @ivvacula for this PR! I'm flagging it as pending v2.x. Basically I'm in middle of porting FakeXrmEasy to .net core and all these PRs will reviewed as soon as v2.x is published. |
Thank you for the quick response, Jordi! Do you know when roughly will be the v2.x available? I don't need an exact date just a rule of thumb estimate (days, weeks, months?) I plan on creating a few more PRs for small issues similar to this, so I'm wondering if it makes sense to wait with them for v2.x |
|
Can't confirm yet, but looking like a matter of weeks hopefully, not days, and not months definitely. Please keep them coming, the codebases will be slightly different but because 2.x will initially support client applications only (what the new CdsServiceClient nuget package supports), both 1.x and 2.x will have to coexist for some time... so still makes sense to keep adding the same features to both, until there is full parity. |
When loading plugin type, check whether the plugin assembly is already loaded in the current AppDomain instead of calling AppDomain.Load right away.
This prevents AppDomain.Load from failing in cases when the plugin assembly is already loaded in the AppDomain and not present in the standard search locations.