Description
I'm running into this issue while working on adding better support for VSIXes in the fast-up-to-date check. I added support to create an additional set "VsixItems" that has as inputs and outputs the inputs to the VSIX (as gathered by the task that runs before VSIX packaging). This works and ensures we get successful builds, but creates a new problem. The VsixItems set has as inputs things produced during the build, like the DLL being produced by csc. So after a full build, this DLL will be newer than the start of the last build. So when the next build happens this VsixItems set will be seen as needing a build, even though the VSIX was then built after that output file.
One potential fix is to exclude the output files from the VSIX inputs, but this involves a bit of whack-a-mole to know what those could potentially be. Chatting with @drewnoakes we had a few other ideas:
- Just exclude the comparison of files against the last-build time for sets that aren't the default set. That way it's more obvious the set is just an input-and-output rule.
- Allow that to be opted-out, but only if there's specific metadata on the input item to say you want to opt out of the check. That way it's not a breaking change.
- Have some extra smarts to prune the input entries in a set based on the presence of other outputs in other sets. So if we know the DLL is the output of the default set, then we shouldn't check the timestamps for the input item. This is in effect doing the filtering we could do manually, but ourselves.