Roslyn: 'BC36970 Failed to emit module' error occurs after changes in edit and continue

Created on 29 Jun 2018  路  9Comments  路  Source: dotnet/roslyn

Version Used: VS Enterprise 15.7.4, Roslyn 2.8.3-beta6-62923-07

Steps to Reproduce/Description:

(This isn't easily reproducible.)

The affected solution is a mixture of VB.NET and C#, and WinForms and WPF. Occasionally, VS's metadata appears to get stuck where _any_ change made using edit and continue causes VB.NET's compiler to fail with BC36970. After stopping and relaunching the debugger, the same code compiles fine, but again, further changes via edit and continue will fail.

Restarting VS doesn't help, but deleting the .vs metadata folder does.

I've only observed this behavior with VB.NET, not with C#.

Expected Behavior:

Edit and continue should be possible, and should refuse resumption only if the code doesn't compile.

In addition, more diagnostic information would be helpful (MSBuild project build output verbosity is set to Detailed, but this setting doesn't appear to affect the build process during edit and continue). For example, could the module not be emitted because there's a lock on the file?

Actual Behavior:

Execution won't continue until I revert my changes or stop the debugger.

Area-Interactive Interactive-EnC Need More Info

Most helpful comment

I got this 'BC36970 Failed to emit module' error this morning all of a sudden, in a VB.NET class module using VS2015. Turns out I had a statement like Const X as Int16 = Y + 1, where Y was defined by a Dim statement. Y was originally defined by a Const statement and everything compiled just fine. After changing Const to Dim is when the BC36970 error occurred. It didn't tell me a line # though - I had to hunt and peck around to find the problem.

All 9 comments

(@tannergooding asked me to tag @tmat and @jinujoseph on this)

A few questions

  • Does the error list not contain any other information than "Field to emit module"?
  • Any chance any of the projects contains AssemblyVersion attribute with * in the version value, e.g. 1.0.*?
  • Could you collect a memory dump of VS process at the point when the debugger can't continue?

Sorry, it's been hard to reproduce, and I just ran into it again.

Does the error list not contain any other information than "Field to emit module"?

It contains warnings, but none that appear to pertain to this error.

In particular, it contains:

  • VB warnings BC40000, BC40004, BC40005, BC40008, BC40056, BC42104, BC42328, BC42357
  • C# warnings CS0162, CS0168, CS0169, CS0414, CS0612, CS0618, CS0649, CS1066, CS1998, CS4014.)
  • perhaps more relevant, a few reference warnings like these two:

The explicit binding redirect on "System.Runtime, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" conflicts with an autogenerated binding redirect. Consider removing it from the application configuration file or disabling autogenerated binding redirects. The build will replace it with: "".

The referenced component 'NLog' could not be found.

(While these are real issues i should fix, debugging otherwise does work fine.)

Any chance any of the projects contains AssemblyVersion attribute with * in the version value, e.g. 1.0.*?

Yes. Some of the projects in the solution have a fully qualified version, but some are indeed simply 1.0.*. However, the assembly in which I'm making changes has a fully qualified version (but depends on some assemblies that don't!).

Could you collect a memory dump of VS process at the point when the debugger can't continue?

Is a minidump enough? See attachment.
devenv.dmp.gz

However, the assembly in which I'm making changes has a fully qualified version (but depends on some assemblies that don't!).

I suspect that's the problem (https://github.com/dotnet/roslyn/issues/9000). Can you try replace the versions containing * with full versions to confirm?

I will try. Is there any way I can get more verbose edit and continue diagnostics?

(No, I'm afraid that's not it. It turns out all AssemblyVersion attributes with a * in them were actually commented out.

I also checked the Modules window's Version column while debugging, and none of the versions from my code are auto-generated.)

I got this 'BC36970 Failed to emit module' error this morning all of a sudden, in a VB.NET class module using VS2015. Turns out I had a statement like Const X as Int16 = Y + 1, where Y was defined by a Dim statement. Y was originally defined by a Const statement and everything compiled just fine. After changing Const to Dim is when the BC36970 error occurred. It didn't tell me a line # though - I had to hunt and peck around to find the problem.

I got this 'BC36970 Failed to emit module' error this morning all of a sudden, in a VB.NET class module using VS2015. Turns out I had a statement like Const X as Int16 = Y + 1, where Y was defined by a Dim statement. Y was originally defined by a Const statement and everything compiled just fine. After changing Const to Dim is when the BC36970 error occurred. It didn't tell me a line # though - I had to hunt and peck around to find the problem.

Thanks lionfan! I just got this error and your post pointed me in the right direction to fix. I'm sure this saved me an awful lot of time trying to figure it out.

I reproduced this issue on a mix of VB and C# projects with [assembly: AssemblyVersion(1.2.3.*")]. Once a VB project references a C# project with this setting things start collapsing. It looks like it has the same problem the other way around.

Was this page helpful?
0 / 5 - 0 ratings