Auto build new binaries on commit #1
Description
With custom actions since you have to commit the results of the "build" (ncc in javascript world, dotnet publish in .net world) it's very easy to commit a code change and forget to build and commit the new binaries.
I was trying to figure out a way to have a CI build that could catch this when it happened. My first thought was to hash the binaries in the repo, rebuild them, then has the new ones and make sure they match. The problem is .net binaries have a new guid and/or timestamp in them each build, so they never hash to the same thing. There is a Deterministic compiler flag that sounded like it would solve this problem, however it doesn't work if you want to also use the PublishSingleFile flag (I confirmed this with the Roslyn team directly).
For the time being I'm not going to try to tackle this problem, and the onus will be on the developer to remember (just like everybody creating javascript/typescript actions today). But it would be nice to revisit in the future.
One easy option may be to just rebuild and recommit the binaries on every commit. This means that every time a developer commits a change, there will be a 2nd auto-generated commit with new binaries (even if the developer did remember to include the binaries on the first commit).
Another option that feels overly complex may be something like this: https://www.codeproject.com/Articles/501631/Compare-Two-DLL-Files-Programmatically-Using-Hash This could probably be wrapped up in a custom action if we went this route.