Make PackageManager More Reliable Across Various Package Configurations

[ilexp]

Summary

The current PackageManager implementation does not explicitly handle NuGet target framework folders, causing some packages to fail installation in Duality. The PackageManager should be extended to have a clear framework and version preference, leading to more reliable and predictable results for those packages.

How to reproduce

• Attempting to install a package where all files are located in a target framework folder with a defined version number exceeding 4.0 will result in no files being copied to the Plugins folder.
• Other cases may apply as well.

Workaround

• For Duality specific packages, do not use NuGet target framework folders for the time being.
• For non-Duality or shared packages, ensure that there is a net40 or lower target framework folder.

Analysis

• The outlined problems are entirely caused by the PackageManager not evaluating target frameworks the way it should do. It is essentially a not implemented feature behaving like a bug. Implement this.

[ilexp]

Progress

• Started working on this in the feature/package-framework-selection branch.
• Extended the internal file mapping algorithm to actively select the target framework to use, as well as differentiate between framework dependent (lib) and framework independent (content, source) files.
• Added more PackageManager tests to verify the correct behavior.
• Patched an unrelated threading bug in PackageManager sometimes causing a License Acceptance dialog to be displayed on install for unrelated packages.

ToDo

• Check if the newly added internal operation locks are a viable option for long background operations in UI updates blocking an install. If not, consider a different solution.
• Thoroughly test the new installation behavior:
  • A fresh Duality install, but with the new binaries
  • Installing and uninstalling various sample packages, preferably with dependencies
  • Uninstalling an re-installing editor module packages
• Merge to master
• Merge to release
• Post-release testing

[ilexp]

Related: Issue #696

[Barsonax]

Hmm I was under the impression we needed to upgrade nuget in order to support targetframework folders but it seems you have a solution that can do this without upgrading nuget? Nice work!

[ilexp]

Hmm I was under the impression we needed to upgrade nuget in order to support targetframework folders but it seems you have a solution that can do this without upgrading nuget? Nice work!

Limited support only, so you're correct when thinking about the full deal.

What we get is an explicit priority decision between "old" frameworks such as .NET Framework or PCLs profiles, as well as explicit handling of per-framework files within a package. However, new frameworks such as .NET Standard will only show up as "Unsupported, Version 0.0" and while it would be possible to do custom parsing of the lib folder to distinguish them, a NuGet upgrade would solve this properly.

Usually, a .NET Standard library would still be consumable, since as far as I recall the official recommendation is to multi-target most of them with both .NET Standard and the equivalent .NET Framework.

[ilexp]

Progress

• Tested the previously mentioned concurrency fix via internal operation locks and found that this introduces long freeze times in the PackageManager UI, since it now has to wait for lock release on the background worker thread a lot.
• Reverted the concurrency fix and instead implemented another one that uses multiple internal pooled dependency walkers instead of a single one, avoiding the need of an exclusive lock that is held for long time periods.
• Implemented support for multiple, framework-dependent package dependency sets, although tests showed not a single package that actually used them. Might be a NuGet v2.x issue, or the packages in question simply did not need them.
• Implemented an optimization to avoid expanding dependencies of "NETStandard.Library", instead treating it as opaque.
• Tested the new package installation behavior as described and found no issues.

ToDo

• Merge to master
• Merge to release
• Post-release testing

[ilexp]

Merged and released.