Folks, I now know that the instructions on this page Adding unmanaged DLL (or any) file to project’s NuGET package output <https://www.dxsdata.com/2019/02/visual-studio-adding-unmanaged-dll-or-any-file-to-projects-nuget-package-output/> are basically correct.
You pack a '.targets' file and the native DLL into the build\ package folder. At install time you can see the Framework csproj file is modified to include your targets. In a Core project you can't see any file changes and magic plumbing takes place. The 'targets' file element silently copies the native DLL from the build\ folder to the binary output folder. So you can package and silently deliver arbitrary runtime files for both Framework and Core consumers. I'm very angry that this process is not clearly explained anywhere in official documentation or the hundreds of rambling and contradictory web articles on the subject. Placing the native file in special package folders like content\ and contentFiles\ seems to do nothing. There are lots of confusing arguments about this in countless web articles. I can't believe these folders are ignored and I'm still researching the matter. It turns out that I was tricked for weeks by package *caching *which negated my experimental changes. I wondered why package changes would randomly work or be mostly ineffective on different days. I found ~10GB of 40,000 files cached under C:\Windows\<user>\.nuget which included my troublesome package. If I delete my package from the cache before each change, then I get consistent results and I found the answer. I actually had a correct package many times, but caching hid that and tricked me. Ironically, incrementing the version for each test would have skipped this problem, but I didn't bother. *Greg*
