Fix plugin dependency loading and remove excess duplicate package references #160
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- For all plugin library projects we do not output referenced project assembly dll such as Flow.Launcher.Plugin - Output all PackageReference dlls for plugins
if the assembly already referenced in Flow.Launcher.Plugin then ignore it
- since we have fixed how dependencies are resolved for plugins, these excess or duplicated package references can be safely removed - for example Newtonsoft.Json can be removed from default plugins as it is included in Flow.Launcher.Plugin project, and external plugins will be resolved to use the reference there
Member
Author
|
TODO: |
JohnTheGr8
approved these changes
Nov 12, 2020
Member
JohnTheGr8
left a comment
JohnTheGr8
left a comment
There was a problem hiding this comment.
Awesome. Apologies this took so long to look into... ;(
Member
Author
All good bud :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem:
Currently in PluginLoader method, we are using AssemblyLoadContext.Default.LoadFromAssemblyPath to load plugin assembly dlls. The Default.LoadFromAssemblyPath loads assemblies into the default assembly load context and as a result the program looks for assembly dlls in the main application directory not in the plugin's own directory.
Consequently for an external plugin, in order for its dependent assembly to work you have to duplicate your assembly's PackageReference to the Flow.Launcher.Plugin library, or for default plugins you have to duplicate it with the main project:
Solution:
Add a custom assembly loader for plugins and resolve any of the plugin's dependent assemblies to load from the plugin's own directory, or if the assembly exists with Flow.Launcher.Plugin then use the assembly there.
Add Directory.Build.targets so default plugins will automatically make project reference to Flow.Launcher.Plugin not available for build.
Use
CopyLocalLockFileAssemblies=truein project file for both default and future external plugins so all referenced assemblies in the plugin are outputted and available for the main application to point to.Result
Plugins no longer need to have the same package reference in Flow.Launcher.Plugin, duplicates can be removed and plugin assemblies are resolving correctly.