A few things here -

1. In the InstallerViewModel, this is called before the InstalledPackage object has been added to the settings, so this will throw an exception unless they had a previous install of the same package (in which case it'd be using the wrong paths anyway).

2. It is possible to have two different installs of the same package, so using .Single() with the PackageName here could possibly throw. If possible, its best to use the Guid Id when trying to find an InstalledPackage.

3. Since the name property is all that's used from the BasePackage, could the method parameter here just be the name of the package instead of the full thing?

We've been using System.Text.Json for our json parsing, as it has improved quite a bit since the initial release. So that we don't have two different json parsing libraries involved, would it be possible to redo this using System.Text.Json? I believe it should have a similar class to JObject called JsonObject

nit: could you please put curly braces around these statements? According to our style guidelines:

Only omit curly braces from if statements if the statement immediately following is a return.

Thank you!

I wonder if it may be better to implement an abstract method, along the lines of ExecuteSharedFolderStrategy instead - we could inject the ISharedFolders to the implementations of this, so that the packages without custom strategies can just call the original SharedFolders method without the is LinkedFolderSharedFolderStrategy check.

You could still inject the strategies to the classes that need them, we just wouldn't expose the whole strategy object to the callers. You might also need to pass in the directory as a parameter, since the BasePackage doesn't know where it's installed (most of the time).

It might also eliminate the need for LinkedFolderSharedFolderStrategy and avoid the circular reference shenanigans.

I hope that made sense 😅