roslyn icon indicating copy to clipboard operation
roslyn copied to clipboard

EnC: Hot Reload fails with unhelpful error message (CS7038) when there are multiple references to the same DLL (System.Runtime)

Open jaredthirsk opened this issue 1 year ago • 3 comments

Version Used:

.NET SDK 9.0.100

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

Steps to Reproduce:

  1. Use an older Fody DLL (ReactiveUI.Fody I think version 19.5.41) to mutilate a .NET DLL. (Put [Reactive] attribute on a property.)
  2. It adds System.Runtime version 8.0 to the DLL. There is also already a System.Runtime version 9.0 in the DLL. I suspect this is not supposed to be. (I see two separate references in the DLL using dotPeek.)
  3. Debug with VS2022 preview or use dotnet watch and make a hot reload change.
  4. No matter what the change is, it fails with CS7038.

Diagnostic Id:

error CS7038: Failed to emit module 'Xyz.Core': Changing the version of an assembly reference is not allowed during debugging: 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' changed version to '9.0.0.0'.

Expected Behavior:

Hot reload works.

Actual Behavior:

Hot reload fails with this error:

dotnet watch :x: error CS7038: Failed to emit module 'Xyz.Core': Changing the version of an assembly reference is not allowed during debugging: 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' changed version to '9.0.0.0'.

Suggestions for fix:

  • [Suggestion 1] Detect this scenario: the assembly has v8, v9 references of a DLL before Hot Reload, and the same two versions after, so do not fail with CS7038, because this is inaccurate: no assembly versions of references actually changed.
  • [Suggestion 2] Improve the error message in this scenario: "DLLs are not allowed to have multiple references to the same DLL, with different version numbers. Bad IL exception." (...that's if this is true. I have no idea.)

Note on bigger picture: Hot Reload has a bad reputation for not working a lot of the time, so any time Microsoft can detect problems caused by 3rd parties (i.e. buggy Fody mutilations), it would be great, in order to rehabilitate the Hot Reload reputation. I almost gave up on tracking this down but I'm glad I didn't. Hot Reload is so helpful when it works.

Crossposted:

  • I also just filed this issue with the ReactiveUI Fody project that destroyed my DLL:

    • https://github.com/reactiveui/ReactiveUI/issues/3937
  • Old unresolved Fody issue that is related:

    • https://github.com/Fody/Fody/issues/1044

jaredthirsk avatar Dec 05 '24 21:12 jaredthirsk

For ReactiveUI.Fody users, see: https://github.com/reactiveui/ReactiveUI/issues/3937#issuecomment-2657950243 For Fody users, see: https://github.com/Fody/Fody/issues/1044

angularsen avatar Dec 02 '25 10:12 angularsen

In general, Hot Reload does not support IL rewriter tools like Fody. It's difficult to detect all possible ways how it may go wrong when such tool is changing the underlying assembly.

tmat avatar Dec 02 '25 23:12 tmat

It'd be best if Fody packages set SupportsHotReload msbuild property to false in their .props file. We could then report a better error: https://github.com/dotnet/sdk/issues/51981. VS already recognizes this property.

tmat avatar Dec 02 '25 23:12 tmat