Subsequent write operations create different outputs

tom-englert commented

2022-06-16 10:45:17 -05:00

(Migrated from github.com)

Calling ModuleDefinition.Write multiple times generates different outputs.
The first output is binary different from all subsequent outputs.

This is not a blocking issue, since both outputs seem to work fine, but might be a hint to some inconsistency in the write operation.

Calling `ModuleDefinition.Write` multiple times generates different outputs. The first output is binary different from all subsequent outputs. This is not a blocking issue, since both outputs seem to work fine, but might be a hint to some inconsistency in the write operation.

Zastai commented

2022-06-17 16:08:31 -05:00

(Migrated from github.com)

I suppose I'm surprised it becomes stable after the first. I could understand each Write generating a new MVID (in fact, arguably it should, just like recompiling does even though everything else remains the same).

I suppose I'm surprised it becomes stable after the first. I could understand each `Write` generating a new MVID (in fact, arguably it should, just like recompiling does even though everything else remains the same).

ltrzesniewski commented

2022-06-19 17:07:57 -05:00

(Migrated from github.com)

I could understand each Write generating a new MVID (in fact, arguably it should, just like recompiling does even though everything else remains the same).

The MVID can be made deterministic. See #810.

> I could understand each `Write` generating a new MVID (in fact, arguably it should, just like recompiling does even though everything else remains the same). The MVID [can be made deterministic](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/code-generation#deterministic). See #810.

vitek-karas commented

2022-07-14 04:44:27 -05:00

(Migrated from github.com)

As per @ltrzesniewski comment - you need to ask for deterministic behavior. But if you still get different outputs after that I would be very interested (as it would break lot of things in our usage potentially).

jbevain commented

2022-09-30 13:05:43 -05:00

(Migrated from github.com)

Interesting. Thanks for the test @tom-englert. Did you have a chance to look at what's happening?

tom-englert commented

2022-10-01 10:53:38 -05:00

(Migrated from github.com)

I once tried to dig through the code, but gave up.

I remember for one experiment that there were some blocks shifted in the file, and an empty block with only 00 had appeared after the second save

However in the test that I've added in #860 the difference is more subtle:

Looks like it's not the MVID that changes.

I once tried to dig through the code, but gave up. I remember for one experiment that there were some blocks shifted in the file, and an empty block with only 00 had appeared after the second save However in the test that I've added in #860 the difference is more subtle: ![image](https://user-images.githubusercontent.com/10229954/193417517-800ac0ca-5073-4551-8073-319896073c56.png) Looks like it's not the MVID that changes.

Zastai commented

2022-10-01 11:11:47 -05:00

(Migrated from github.com)

Given that second file has a high(ish) value at the start makes me wonder if there's a static or instance field somewhere that does not get reset.

Rows
Columns

Subsequent write operations create different outputs #859