Fix linker incrementalism

[SteveSandersonMS]

The Input/Output values previously specified on _BlazorCopyFilesToOutputDirectory could lead to corrupted builds, because this kind of incrementalism skips processing files where the output is newer than the input. The incrementalism we really want here is skipping items where the output is the same as the input (so we do copy if it's either older or newer).

As an example of how it was broken before:

• Build with linker enabled
• Now set <BlazorLinkOnBuild>false</BlazorLinkOnBuild>
• Now, during the next build, there will be an item with input=<somenupkgdir>/mscorlib.dll, output=bin/.../mscorlib.dll.
  • Since there's already a file at bin/.../mscorlib.dll, and you just generated it using the linker in step 1, the output file will be newer than the input, hence it will skip copying this
• You now have a corrupted build, in which some of the dlls have been linked and some have not. It will fail at runtime if you start using any APIs that were linked out when you did the build in step 1.

It could even break when you upgrade to new packages, even if you're always using the linker. Example:

• Make a build with some version of packages and linker enabled
• Now change to different dependency versions
• Now, during the next build, there will be an item with input=<somenupkgdir>/SomeDependency.dll, output=bin/.../SomeDependency.dll.
  • Since you just generated bin/.../SomeDependency.dll on your previous build a few minutes ago, its timestamp could be newer than the file from your NuGet package cache
• Now you have a corrupted build because it's randomly using some older versions of package assemblies than you have declared

I think the fix is to copy whenever the file is different, regardless of whether it's newer or older. This is already handled by the <CopyTask>, since we specify SkipUnchangedFiles by default. So we just have to remove the input/output declarations from _BlazorCopyFilesToOutputDirectory and let <CopyTask> take care of the incrementalism.

[SteveSandersonMS]

@pranavkm This is an entirely separate issue I noticed while looking at this. Previously, we never wrote the unlinked.output file to disk, which I guess is an unintentional omission, since some other code does try to read that file. Adding this line means we do write it to disk.

However, it's unclear to me that this achieves anything. The "input" items for _ResolveBlazorRuntimeDependencies include @(IntermediateAssembly), which is treated as changed on every build, even if you didn't modify your sources. As such, _ResolveBlazorRuntimeDependencies is never skipped, and hence we regenerate unlinked.output and @(_BlazorResolvedRuntimeDependencies) on every build.

So, what's the intention for unlinked.output? If we know the info will be recreated on every build, does that make it pointless to write it to disk?

[pranavkm]

include @(IntermediateAssembly), which is treated as changed on every build, even if you didn't modify your sources.

That seems really suspect. I'll have a look at it, but the rest of the change here looks great.