Unstable mvid when using signature file

[nojaf]

When I have a project with a paired file (impl + sig), my reference assembly mvid should not change when I modify the implementation file where the signature did not change.
I think there are multiple situations where this happens.

Provide the steps required to reproduce the problem:
See https://github.com/nojaf/InstableMvid

Expected behaviour

The mvid should remain the same when the implementation was touched but the signature was not.

Actual behaviour

Adding a new class to the implementation only leads to another mvid value.

Known workarounds

I knew this could happen when you don't have signature files, so that was my whole reasoning for betting on them.

Related information

Provide any related information (optional):

• dotnet 7.0.100-rc.2.22477.23

I'm very interested to contribute to this.
@TIHan could you point me in the right direction?

[nojaf]

Could we do something with the

fsharp/src/Compiler/AbstractIL/il.fsi

Line 1098 in 9d9c6c1

member IsHideBySig: bool

to generate the mvid value?

Or figure out on the ILTypeDef level if it was backed by a signature file?

[vzarytovskii]

Mvid depends on signature and optimization data, there's no "easy" fix for it.

This issue is pretty much a duplicate of #13222

[nojaf]

Thinking out loud but if you know a file was backed by a signature, could you not trim code, data and meta for that file in

fsharp/src/Compiler/AbstractIL/ilwrite.fs

Lines 4135 to 4141 in 8cd8973

	let hCode = sha.ComputeHash code
	let hData = sha.ComputeHash data
	let hMeta = sha.ComputeHash metadata
	// Not yet suitable for the mvidsection optimization
	let deterministicId = [| hCode; hData; hMeta |] |> Array.collect id |> sha.ComputeHash
	let deterministicMvid () = deterministicId[0..15]

Well, I wouldn't trim the existing stuff, just collect less when you can, purely for the mvid value.
I'm aware of the complexity of trimming the sigdata in #12674. but doesn't that go away when a user has a signature file where it is explicitly stated what is public and what is not?
Where again, I'm not saying we should trim the existing data there today, just don't use the full set to determine the mvid.

[vzarytovskii]

Thinking out loud but if you know a file was backed by a signature, could you not trim code, data and meta for that file in

fsharp/src/Compiler/AbstractIL/ilwrite.fs

Lines 4135 to 4141 in 8cd8973

	let hCode = sha.ComputeHash code
	let hData = sha.ComputeHash data
	let hMeta = sha.ComputeHash metadata
	// Not yet suitable for the mvidsection optimization
	let deterministicId = [| hCode; hData; hMeta |] |> Array.collect id |> sha.ComputeHash
	let deterministicMvid () = deterministicId[0..15]

Well, I wouldn't trim the existing stuff, just collect less when you can, purely for the mvid value.
I'm aware of the complexity of trimming the sigdata in #12674. but doesn't that go away when a user has a signature file where it is explicitly stated what is public and what is not?
Where again, I'm not saying we should trim the existing data there today, just don't use the full set to determine the mvid.

Tricky, we might want to experiment with it, however sigdata now has all members - internal and private.

I am unsure what will consequences of this be - how it is used by existing tooling (if at all).