Can i specify the module version id (MVID) when building a .net assembly?

Question

We have some shared assemblies that get build automatically every night. When there are no changes made to the sources, i would expect the assembly binaries to be exactly the same as a previous version.

However, there seem to be minor differences between assemblies.

I have done some effort to determine the difference between two builds. I used ildasm to generate an il version, and compared the resulting text versions. The only difference (in IL) is the MVID (a random guid) in the module.

Some googling tells me that the module version id gets generated by the compiler, so it is possible to determine the build source, even when everything else is the same.

This MVID creates an artificial diff betweeen builds of the same code, and an artificial checkin of the resulting assembly.

Is it possible to supply the MVID to the C# compiler?

Tynes

It's not the only difference, the PE32 header has a timestamp for example. This problem really started when you decided to check-in binaries. – Gilman

@Hans: i agree that checking in binaries is not a best practice. I asked this question because i would like to know why there are differences between binaries that are build of the same code. – Behrens

@Hans: i modified the question to reflect this. – Behrens

You're still blowing right past my argument. So what if the MVID changes? The file changes anyway. Your assumption that the exact same source code should generate the exact same binary file just isn't correct. You can't make it correct, abandon all hope. – Gilman

@Hans: Why should the exact same source not result in the same binary? – Behrens

In my opinion the exact same source should result in the same binary if the same compiler, linkers, ... (incl. options) are being used. The timestamp and MVID (module version identifier) make things more complicated. It would have been more convenient if the timestamp was dropped and the MVID would be a SHA2 of the binary (assuming MVID is 00). If the binary is 100% equal, then you don't need retesting. Now, there is no way to determine if this is true. – Everyday

OBR: Then why build then if the source didn´t change? – Bashee

OBR -> Old But Relevant – Bashee

@AhmedAlejo You may want to confirm the DLL is up to date. – Decima

Answer 1

The ECMA-335 standard says:

The MVID is a Guid used to distinguish between two versions of the same module

Based on this description, supplying this is an argument to C# compiler will defeat it's purpose since you can pass the same MVID for different builds so I would say No.

I think the easier way would be to build only when something changes not necessarily every night.

Lubricious

+1 for the idea of doing builds based on check-ins instead of "just because" An alternative is to not worry about it at all. – Ongun

Answer 2

I realize this is a 5 year old question, but I made a Fody addin that allows you to specify a custom MVID for an assembly (needed for my own tests)

You can get it via nuget:

Install-Package Mvid.Fody

You can then specify a custom MVID like this:

[assembly: Mvid("your-guid-string-here")]

When the assembly compiles, it will have an MVID with the Guid you specified.

More info here: https://github.com/hmemcpy/Mvid.Fody

Gustavo