Building this repo at v3.0.1+ creates M.Ext.FileProviders.Embedded.3.0.1 without lib/ contents (source-build?)

[dagood]

Describe the bug

When I clone the repo at v3.0.1 and run ./build.sh, artifacts/packages/Debug/Shipping/Microsoft.Extensions.FileProviders.Embedded.3.0.1.nupkg contains only these dirs:

build
buildMultiTargeting
package
tasks
_rels

Microsoft.Extensions.FileProviders.Embedded.3.0.1 on NuGet contains a lib/ dir with the actual assembly.

I am running my build in a CentOS 7 Docker container, but it probably repro'd on every source-build CI platform such as macOS. (We notably don't build on Windows.)

During a 3.0.1 source-build, this repros as well. I can't test it on the v3.0.2 tag here standalone because it doesn't build.

To Reproduce

./build.sh at v3.0.1. Linux may be necessary.

Expected behavior

The nupkg should be the same as the released one (modulo determinism and capability issues).

Additional context

I believe this is breaking source-build, with a last-minute workaround of not crossgenning the outputs: dotnet/source-build#1452.

/cc @crummel @dseefeld

[dagood]

@JunTaoLuo, can you help with this source-build issue?

[JunTaoLuo]

Looks like there's something wrong with the logic at https://github.com/dotnet/extensions/blob/v3.0.1/src/FileProviders/Embedded/src/Microsoft.Extensions.FileProviders.Embedded.netcoreapp3.0.nuspec#L14-L16. Though I'm not sure what could have changed here between 3.0.0 and 3.0.1

[dagood]

Interesting... building from v3.0.0 also has the behavior. I assumed it didn't because of the connection to the source-build issue that only showed up in 3.0.1+. Sorry for the misdirection, I'll look more for why crossgen was working in 3.0.0 source-build.

This behavior still seems strange to me, but it doesn't seem to be the cause of the source-build problem. Feel free to close if this generic issue isn't worth looking into without the source-build link.