@dsplaisted can you take a look at this on Monday. Seems like the windows failures might be legit.

Still working on this, but this is failing due to the stage 0 update. With the updated stage 0, the PrepareForReadyToRunCompilation task is now including mscorlib.dll and mscorlib.ni.dll in its output items. It is doing that because the newer mscorlib has IL code in it, which is causing InputFileEligibleForCompilation to return true.

The mscorlib.ni.pdb output item from PrepareForReadyToRunCompilation does have ExcludeFromSingleFile metadata set to true. So the issue may be that ExcludeFromSingleFile isn't being handled correctly, rather than that mscorlib.ni.pdb is included in the PrepareForReadyToRunCompilation output.

@fadimounir Thoughts?

@dsplaisted looks like a test bug in the It_excludes_ni_pdbs_from_single_file.
I think it should be fine to change the .OnlyHaveFiles to .HaveFiles
cc @swaroop-sridhar

[Separate issue] If mscorlib.dll now has some IL, should we R2R it like other runtime libs in the runtime package we ship, so that app developers using the SDK won't have to compile it themselves?
What kind of IL got added to mscorlib? I was under the impression that this should have just been a forwarder, and all code should be in s.p.corelib.dll

@fadimounir These are the files in the publish directory with the failing test:

07/01/2019  12:27 PM        69,102,199 HelloWorldWithSubDirs.exe
07/01/2019  12:22 PM            19,456 HelloWorldWithSubDirs.ni.pdb
07/01/2019  11:43 AM               596 HelloWorldWithSubDirs.pdb
07/01/2019  12:27 PM            19,456 mscorlib.ni.pdb

Are you saying that for single file publish, you expect mscorlib.ni.pdb to be in that directory, but no other mscorlib files?

Are you saying that for single file publish, you expect mscorlib.ni.pdb to be in that directory, but no other mscorlib files?

It should have the large HElloWorldWithSubDirs.exe + pdbs. The goal of the test is to verify we don't include pdbs in the single-exe bundle.

Maybe a better fix would be:
foreach(file in output folder)
if (file == SingleFile || file == PdbFile || file == NiPdbFile)
continue;
else
Verify file.extension == ni.pdb

@fadimounir can you push a commit to this PR to fix this issue. This is the last change we are tracking for 3.0 Preview7 and this is blocking our snap.

Assuming @dsplaisted is not already fixing the test.

@dsplaisted I'm assuming you're working on the fix. Let me know if you need help

@fadimounir I'm still not following how it would be expected behavior to include mscorlib.ni.pdb in the publish output here. Is it needed for debugging? Would you get .ni.pdb files for System, System.Core, etc. if the app used APIs from those DLLs? What is the ExcludeFromSingleFile metadata on mscorlib.ni.pdb supposed to do?

@dsplaisted ExcludeFromSingleFile means that a file with that meta-data should not be bundled into the single-file output (but instead left as-is in the publish directory).

When the test was written, only the <app>.ni.pdb was being generated. But looks like now mscorlib.ni.pdb is also output. I'm not sure about what triggered this change; but I'm fine with changing the test to check with .havefiles instead of onlyhavefiles.

I can put out a PR with the change for the test.

Here it is: #3381

Is it needed for debugging

The .pdb's are used for debugging. The .ni.pdb's are used for profiling purposes. Both of these file types are useful for the app developer of an app (which is why they are in the output publish folder), but not useful to include in the single-file bundle that the app developer will distribute to his/her customers (customers will be running the app, not debug it)

Would you get .ni.pdb files for System, System.Core, etc. if the app used APIs from those DLLs?

API usage doesn't impact .ni.pdb generation. These ni PDBs are generated for every R2R image that gets compiled during publishing, if the PublishReadyToRunEmitSymbols property is set.