Upgraded nuget to 5.4

[Barsonax]

Not ready to merge yet. Prerequisites:

• Remove duplicate package.config logic (duality already has such logic).
• Fix any remaining bugs

[Barsonax]

Is there any equivalent in NuGet 5, which we can query for project "status quo"

If I understand correctly you want a list of all packages needed including all dependencies. Nuget provides a API for this and the PackageConfig.xml itself can be used as input for this. With some logic you can then figure out what packages to install and what to uninstall.

I believe the nuget class we need for this is called DependencyResource or similar.

[ilexp]

If I understand correctly you want a list of all packages needed including all dependencies.

Ah, no, not the needed ones - I might have explained it all a bit convoluted. I'll try again, in short.

This is what we have now:

• PackageConfig.xml: Which Duality packages the project wants.
• Source\Packages via NuGet API: Which (NuGet) packages are installed right now.
• Duality triggers NuGet to un/install so the list of Duality packages matches in both.

What we need now, since the packages folder no longer seems to play that role in NuGet:

• PackageConfig.xml: Which Duality packages the project wants.
• ???: Which (NuGet) packages are installed right now.
• Duality triggers NuGet to un/install so the list of Duality packages matches in both.

That second ??? part is what I meant. Is there some sort of NuGet-managed package lock file or something else that tells you what is actually installed right now? If not, we could probably write our own in some bookkeeping file inside the Source\Packages folder.

[Barsonax]

Rebased on the latest master. Changes are now down from 39 to 9 files :)

[Barsonax]

???: Which (NuGet) packages are installed right now.

Isn't this something duality could provide based upon the files present in the plugin folder? Might need to split it up to prevent ambiguity between packages and dll's that were just copied there?

Not depending on nuget for this would make future updates easier so design wise this be would be preferable. Nuget doesn't have logic for this anyway so the only way is to add another layer in between.

[ilexp]

In that case, I'd probably go with an InstalledPackages.xml inside Source\Packages that gets updated immediately after an individual package install / uninstall is complete. That way, NuGet would be out of the equation for bookkeeping here, and we don't risk falling into ambiguity traps when checking plugin, lib and sample files. For a first iteration, behavior would also be equal to what we have right now, which is nice. Could also be an opportunity to clean up a bit of local package setup code.

I can look into this, provided I manage to carve out some time, fingers crossed 😄

[Barsonax]

Yup might be better that you look into this particular part.

In the current commit of this PR there is still the package config on the nuget side that is not needed anymore I think btw.

[ilexp]

Okay, so right now I'm the bottleneck for moving this forward, but I'll try to briefly summarize what I think needs to be done here before we can merge:

ToDo

• Get the basics for unit testing of package management back up and running.
  • Respect repository URLs specified in Duality PackageSetup, including local folder paths.
  • Check out if packing dummy packages for testing still works, fix if necessary.
  • Ensure the most basic install / uninstall tests succeed.
• Sandbox NuGet settings used in Duality package management.
  • Use a default, then modify local instance.
  • Do not rely on system or user settings for NuGet to avoid interference in various dev setups.
  • NuGet settings links for research:
  • https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior
  • https://github.com/NuGet/Home/issues/3972
  • https://github.com/NuGet/Home/wiki/%5BSpec%5D-NuGet-settings-in-MSBuild
• Introduce a Duality InstalledPackages.xml in Source\Packages to reflect which (NuGet) packages are currently installed, to replace the previous "local repository" mechanic that was based simply on existing folder structures. (See above)
• Gradually fix things until all tests are green again.
• Do a full DualityEditor test locally.
  • Fresh install from local repository
  • Fresh install from remote repository
  • Package restore, install, uninstall and update via PackageConfig.xml changes and restart.
  • Package install, uninstall and update via package manager UI
  • Test performance now that PackageCache is gone and re-introduce some equivalent if it's too bad.
• Final cleanup, API and style tweaks.

I'll report back with progress and help requests as soon as I get to it.

[Barsonax]

@ilexp do you still have time to implement this? If not maybe we should make it clear that somebody else can take it over.

Not that I have much time lately though...

[ilexp]

@ilexp do you still have time to implement this? If not maybe we should make it clear that somebody else can take it over.

Good call - I'm honestly a bit overwhelmed with real life stuff lately and since I'm clearly the bottleneck here, I'd be happy to let someone take over, and try to help with advice.

[Barsonax]

Upgraded to nuget 5.4 so we stay up to date. Currently working on getting the unit tests working properly again. Turns out we still referenced the old nuget 2.14 in the unit tests (FIXED). Also its currently not using the test repository that the unit tests sets up which breaks many tests.

[Barsonax]

Seems like PackagePathResolver and PackageIdentity truncate the revision number. Meaning a version like 1.0.0.0 will end up as 1.0.0. Seems nuget doesnt want you to use 1.0.0.0? Needs some more research to be sure.

EDIT: nuget is normalizing the version numbers: https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#normalized-version-numbers

[Barsonax]

Closing this as we have decided to take a different route in #786