What are these differences in two DLL file generated from the same source code

Question

All my code is under source control, so I'm 100% sure that the source code hasn't changed. But if I build a C# DLL two times their content is slightly different. I can reproduce the problem 100% of the time by just building, and then building again.

This doesn't seem to impact the program at all, but tools like MSIMSP, used for creating patches from two MSI files are thrown off by these minute changes. Making patches (for my product) 40x bigger than they should be.

I've decompiled both DLLs and their assembly information, classes, etc... are exactly the same. The files are also exactly the same size, but of course have a different creation time. So I really cannot fathom what has changed.

So I dug a little deeper.

I've used WinDiff to find the changes and then cross referenced these in a hex editor. WinDiff shows a change in the second 'line' and in a line at about 80% of the file.

In the hex editor I see that the first byte that is changed is byte 0x088 (byte 136). This seems to be the only byte changed on this 'line'. I trouble finding the second change as WinDiff doesn't tell me the exact byte offset of the change.

Here is an image of the changes, the right file is the contents of the newer file.

Does anybody familiar with the make-up of (C#) DLL files know what the changed byte might mean? Or better yet how to make sure that DLL files stay exactly the same when you rebuild them?

Brut

Sometimes there is a file named $RANDOM_SEED$ in my bin/release folder, and the content of that file changes every time I rebuild. I have not gone into detail, but I can imagine that being one of the two changes. Someone will need to do some reserch. EDIT: (its nunit, probably has no influence into the dll, so forget my comment) https://mcmap.net/q/728852/-what-is-the-random_seed-file-generated-by-visual-studio-build-of-c-solution – Protease

It may be worth your while to try out a good text/hex editor like Vedit. I've been using it since 1989. It is a good tool to have at your disposal even in these IDE & intellisense days. www.vedit.com – Woodley

How can I tell whether two Net DLLs are the same seems to approach the same issue from a different angle. – Murielmurielle

#8928058 – Margaux

@Matteo's link should clear it up! – Oviduct

It is IMAGE_FILE_HEADER.TimeDateStamp. – Viral

Answer 1

This might have something to do with differences between Build and a ReBuild

Difference between Build Solution, Rebuild Solution, and Clean Solution in Visual Studio?

if it doesn't think it needs to rebuild a project, it won't. It may also use partially-built bits of the project if they haven't changed

Performing a build uses metadata behind the scenes and thus your dll's can be different

Why is a different dll produced after a clean build, with no code changes?

SOLUTION:

You will need to perform a deterministic build as described here

Tremayne

Ye but building multiple times should produce the exact same binaries everytime, no? – Protease

@Protease Unfortunately there is always something going on behind the scenes... metadata it looks like #107696 so No they would not produce the same binaries – Tremayne

@Tremayne any way to ignore those metadata bytes for creating patches? (Maybe I should ask that as a separate question) – Brut

@Roy T Not that I am aware of sorry, I would try a rebuild over a build and if that did not work then yes I would be asking how to strip out the metadata etc... might be another compiler that allows you to do what you need maybe? – Tremayne

@FuzzyBear I stumbled upon blog.paranoidcoding.com/2016/04/05/… which says there is a /deterministic build parameter for Roslyn. Hope that works :D – Brut

Amazing find @RoyT. and his first line : "It seems silly to celebrate features which should have been there from the start" going to add link to my answer – Tremayne

Answer 2

If you have made changes to the dll then the size will be affected I added a few extra properties to an enumeration and the file became about 3kb larger. It could also be an unseen change due to decompression which causes the file to appear different.

Scythe