2

We have several VS 2008 solutions with close to 90 dlls + exes in all. They all use .NET 3.5.

I'd like to convert the solutions & projects to VS 2010 (not ready for the leap to 2012), but maintain the same framework version.

If I generate a hash of the dll compiled using VS 2008, and another hash of the dll generated using VS 2010 will the hashes match?

Are there cases where I would get a false negative? In other words, would the hash not match even though the underlying source code hasn't changed?

Couldn't find any authoritative reference that would help me figure this out.

Naraen
  • 3,240
  • 2
  • 22
  • 20
  • 1
    possible duplicate of [Compare compiled .NET assemblies?](http://stackoverflow.com/questions/652432/compare-compiled-net-assemblies) – SLaks Nov 03 '13 at 03:28
  • See also http://stackoverflow.com/q/2940857/34397 – SLaks Nov 03 '13 at 03:28
  • Also see http://stackoverflow.com/questions/5836449/check-to-see-if-a-compiled-dll-has-changed – Scott Chamberlain Nov 03 '13 at 03:29
  • Why do you need to compute or compare DLL hashes in order to migrate your projects from VS2008 to VS2010? – dthorpe Nov 03 '13 at 04:14
  • 1
    No. This is by design. See this http://blogs.msdn.com/b/ericlippert/archive/2012/05/31/past-performance-is-no-guarantee-of-future-results.aspx – Mike Zboray Nov 03 '13 at 06:33
  • @SLaks, thanks for the link it had many alternative ideas for me to look into. – Naraen Nov 03 '13 at 15:41
  • @mikez. Thank you for the reference to Eric's blog. That is exactly what I was seeking. – Naraen Nov 03 '13 at 15:41
  • @dthorpe. The ideas was to ensure that the two versions are identical & hence narrow the amount of regression testing we have to do. It's not a new idea... some federal govt code handoff processes require something similar - for a different reason - and it works well for C++ binaries. – Naraen Nov 03 '13 at 15:47
  • Oh, I misread the question a little I guess. I thought you were trying to use the hashes computed by the compiler for the DLLs, but you're talking about an externally computed hash just to see if the DLLs are the same. When comparing binaries produced by two different compiler versions, the binaries almost never match bit for bit. Compiler bug fixes, runtime library bug fixes, changes in embedded string data (copyright notices), etc will all cause the DLLs to be slightly different even when compiled from the same source. – dthorpe Nov 04 '13 at 23:37
  • Plus, if you're rebuilding the same source with a different compiler, you really can't make any assumptions about whether the code works the same way as when compiled with an older compiler. You might get away with this if you linked in the DLLs that were compiled with the old compiler (and already tested), but if you're building from scratch with a different compiler you're changing the landscape significantly. – dthorpe Nov 04 '13 at 23:39

1 Answers1

2

No they will not, in fact, just compiling a dll twice one right after another will have a diffrent hash. There are some pieces of information that causes the hash to change every compile.

However there are many alternatives, see the links to the other questions that where posted as comments to your question.

This link provides details of why & what is different. http://blogs.msdn.com/b/ericlippert/archive/2012/05/31/past-performance-is-no-guarantee-of-future-results.aspx

This link has several suggestions for alternative approaches to solve the underlying requirement. Compare compiled .NET assemblies?

Community
  • 1
  • 1
Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431