0

The problem is that rebuilding exactly the same code generates a different assembly when compared with the result of the previous build.

Why do I need this? I have a T4 template that generates certain source code from the given contract assembly. That source code is checked in into VCS, even though it is generated. This is because the contract assembly changes relatively infrequently. However, when it does change, I would like to fail the build as long as the aforementioned T4 template is not reevaluated.

My plan is to plant the hash code of the contract assembly in the generated source file, for example:

// 1B-D0-06-48-02-C2-C5-C5-48-37-AA-61-66-6B-6D-01

There would be an msbuild task that runs when the project containing the template is built. That task is going to compute the contract assembly hash and compare it against the one baked into the generated source code. Inequality means the contract assembly has changed and we need to rerun the template.

Storing the assembly version does not help - it is the same during the development.

Another solution would be to evaluate the template at run-time into a temporary file and copy it over the generated source file if it is different - no hash required.

However, I want to attract dev's attention to the fact that the contracts changed. At this point I want the developer to reevaluate the template manually. But only when it is needed.

I think I could write a complex code that reflects on the contract assembly to create some kind of a canonical representation of its types. Taking the hash of this canonical representation should be it. However, this is not trivial and I would like to see if it can be avoided.

fuz
  • 88,405
  • 25
  • 200
  • 352
mark
  • 59,016
  • 79
  • 296
  • 580
  • 1
    The right way to do this is to give your assembly a strong name, which includes cryptographic signing. This feature is built into .NET. See https://stackoverflow.com/questions/1436879/what-is-strong-naming-and-how-do-i-strong-name-a-binary, for example. If you want a different approach, your question is way too broad, as there are lots of different ways to go about it. – Peter Duniho Sep 28 '16 at 03:04
  • You could check what is the difference caused by recompilation. Most probably it is only compilation time mentioned somewhere in assembly metadata. – max630 Sep 28 '16 at 07:06
  • @PeterDuniho - signing is not a problem. What is the next step? – mark Sep 28 '16 at 13:05

1 Answers1

2

I think I could write a complex code that reflects on the contract assembly to create some kind of a canonical representation of its types

Actually, ildasm can do this. If called with following arguments:

ildasm /text /pubonly _dll_

it will print to stdout the assembly's public interface

max630
  • 8,762
  • 3
  • 30
  • 55
  • 1
    It is better, than comparing the DLLs. Although, one will have to remove the `// Image base:` and `// MVID:` lines from the output. So, it could be used. I wonder if the result can be improved, since `ildasm` produces too much output for me. I just need the signatures along with the custom attributes, of course. No need for method bodies, for example. – mark Sep 28 '16 at 13:48