Duality nuget packages have the wrong folder structure under lib

[Barsonax]

Summary

Currently the dll's in the duality nuget packages are directly in the lib folder. This is wrong and can cause annoying problems. One of these problems is that you cannot reference duality in .Netstandard1.1 project (version 2.0 and higher do work).

The lib folder should contain a folder for each target framework (even if its only 1). So in the case of a pcl with profile111 the lib folder should contain a portable45-net45%2Bwin8%2Bwpa81 folder with the dll

Why is this important? Nuget uses these folder names to figure out the target framework and uses this to resolve compatiblity issues. If you put the dll directly under lib then nuget will identify it as a .NETFramework, Version=v0.0. Obviously this is prone to cause problems when it needs this version to resolve something.

How to reproduce

Try to reference a Adamslair.Duality from a netstandard1.1 project through nuget. It should work but it doesnt. Putting <PackageTargetFallback>$(PackageTargetFallback);portable45-net45+win8+wpa81</PackageTargetFallback> wont fix this as it cannot identify the library.

Workaround

2 options:

• Add the dll manually without nuget.
• Add <PackageTargetFallback>$(PackageTargetFallback);net00</PackageTargetFallback> to your csproj. This will fix adding the nuget package.

Analysis

• nuget pack SomeDuality.csproj seems to generate a correct nuget package. Not sure what the ci server is using for duality but its doing something different for sure.

[ilexp]

Duality internal NuGet packages currently do not specify a target framework and do not use framework folders. This hasn't been a problem in old NuGet via VS, but it is becoming one when working in the more modern netstandard / netcore area. It's not an issue of binaries or building, but how things are packaged and labeled in the end.

It will need to be addressed before switching Duality to .Net Standard, see also this comment and also this one, but fixing this would be a great idea in any case. As a first step, the Duality package manager needs to properly support / consume multi-framework packages and, when this is done, Duality binaries can be packed specifying a proper target framework as well.

[ilexp]

Note that the Duality package manager should now be smart enough to handle multi-framework packages, both regarding their payload and dependencies - meaning this issue is no longer blocked by preconditions.

[Barsonax]

Solution seems to be to simply use 'nuget pack' right? Since we are planning to move away from the older nightly build tool this could be solved at the same time.

[ilexp]

Solution seems to be to simply use 'nuget pack' right? Since we are planning to move away from the older nightly build tool this could be solved at the same time.

We'll still need .nuspec files to explicitly specify package contents for samples, and to keep the automated semantic version updater tooling operational, so there will be some manual work involved to update their package lib folder targets.
We'll also need to update non-Duality AdamsLair dependencies, such as our OpenTK fork, or AdamsLair.WinForms. Some of those might actually be fine without nuspecs, will have to investigate on a per-library basis. The others will need updated nuspecs as well, but those will be minor changes as well.

So for the sake of simplicity, I'd keep the two issues separate. Better two small, self-contained steps with a small gain each, than one bigger, riskier one.

Rough outline of the steps to investigate:

• Update nuspecs in Duality main repo to use proper lib folders.
• Update nuspecs in Duality dependency repos to use proper lib folders.
• Bump all dependency versions and publish them.
• Update all dependencies in the Duality main solution (and nuspecs!)
• Bump all Duality package versions.
• Do a full offline / local repo test run to ensure we didn't screw up the dependency graph after all those version bumps.
• Merge and trigger a binary release.

[ilexp]

Progress

• Updated and published dependency packages to use framework lib folders:
  • AdamsLair.WinForms.PopupControl
  • AdamsLair.WinForms
• Found that some of the packages contain both framework-dependent and lib-root files, which are a combined version of explicitly specified contents and csproj-derived contents. Aligning explicit with implicit content for now.

ToDo

• Update nuspecs in Duality dependency repos to use framework lib folders, bump their version numbers and publish them:
  • AdamsLair.OpenTK
  • AdamsLair.OpenTK.GLControl
  • AdamsLair.NVorbis
  • AdamsLair.TreeViewAdv
  • AdamsLair.DockPanelSuite
• Update all dependencies in the Duality main solution (and nuspecs!)
• Update nuspecs in Duality main repo to use framework lib folders.
• Bump all Duality package versions.
• Do a full offline / local repo test run to ensure we didn't screw up the dependency graph after all those version bumps.
• Merge and trigger a binary release.

[ilexp]

Progress

• Updated all dependency nuspecs and released patch versions for all dependency packages.
• Moved to branch feature/package-frameworks-696.
• Updated all dependencies in the Duality main solution.
• Updated all Duality nuspecs to use framework folders.
• Bumped all Duality package versions.

ToDo

• Do a full offline / local repo test run to ensure we didn't screw up the dependency graph after all those version bumps.
• Merge and trigger a binary release.

[ilexp]

Duality and all of its dependencies now use framework folders in their packages. Closing this.