Error CS7038 (failed to emit module) only in Edit and Continue

Question

I'm debugging a .NET 4.0 application in Visual Studio 2015. My application builds and runs fine, but when I try to edit and continue while running under the debugger, regardless of what changes I make or where I make them in my main project, I get a dialog that says:

Edits were made which cannot be compiled. Execution cannot continue until the compiler errors are fixed.

As an example of the sort of change I'm talking about, I've tried adding this line in various methods:

Console.WriteLine("foo");

When I look in Visual Studio's Error List pane, I see only one error, CS7038, with the description "Failed to emit module '<my app name>'." No filename, line number, or character is given. There are no squiggly red underlines in my code. If I stop the running application, build with the changes, and run again, everything builds and runs just fine. So there seems to be some discrepancy between what the build-time compiler and the edit-and-continue compiler consider acceptable.

Does anyone know of a way to get more information about why the compile fails in Edit and Continue mode? I read something about attaching to and debugging the VBCSCompiler process, so I tried that, but even with all exception types set to break when thrown, the attached VS never broke.

I'm not sharing any code because this isn't a question about my code but rather about strategies for finding out what the Edit and Continue compiler thinks is wrong, and for all I know the source of the compiler error could be anywhere in my entire project.

Edit:

As mentioned in the comments, I was able to attach a debugger to Visual Studio and break when an exception was thrown upon clicking "Continue" after editing code. The exception was a System.NotSupportedException with the following message: "Changing the version of an assembly reference is not allowed during debugging". It listed the name of the assembly in question, which was a small VB.Net project used by my application, which is mostly in C#. I'm trying to build up an MCVE to submit to Microsoft, but currently I'm unable to reproduce the problem in a smaller solution with just one VB and one C# project.

Edit 2:

I've found a workaround and self-answered the question in case anyone else ever encounters this weird problem, but I'm reserving the "Answered" check mark for anyone who can explain what's going on (why the compiler thinks the version number of the referenced project has changed during the edit).

Dionisio

Have you killed all instances of VS and restarted? Have you reset VS settings? If not, I'd start there. – Gluttonize

I've restarted VS, yes. Haven't reset VS settings, which sounds scary. Is there a way to save your settings so you can reinstate them if that doesn't solve the problem? – Dionisio

Yes. Go to Tools -> Import and Export settings. From there you can save current settings (export), reload old settings (import) or reset all. If you choose reset all, the next screen will ask if you want to export your current settings first (recommended). – Gluttonize

Excellent. Thanks. I'll try it. – Dionisio

Attach a debugger to VS and look for exceptions. – Westleigh

@David, resetting VS settings didn't seem to make a difference. – Dionisio

@SLaks, I started a second instance of VS 2015, attached to the first instance, set to break on thrown for all exception types, started debugging my project in the first instance, paused execution, edited a file, and clicked Continue. I got the same error dialog as described above, but my second instance of VS never broke. Am I doing it wrong? – Dionisio

No; that sounds correct, but very surprising; VS always throws exceptions. Make sure Just My Code is disabled. – Westleigh

@SLaks, okay, I had Just My Code checked. I unchecked it. It's loading symbols and I need to get home, so I'll pick this up tomorrow. Thanks for your help. – Dionisio

@SLaks, I stuck around till symbols were loaded and clicked Continue. It threw an exception caught by the second instance of VS. Says "Changing the version of an assembly reference is not allowed during debugging" and told me which assembly is the problem (another project in the solution). This gives me something to go on tomorrow. Thanks again for your help. – Dionisio

You should file a bug on github.com/dotnet/roslyn/issues – Westleigh

Thank you, I have mixed solution c#/vb.net and I had the same problem with the asterisk in vb assembly version. After make it equal to the same value of c# assembly version, the editing during debug is ok, failed to emit module error is disappear. Thanks again. – Choriamb

Answer 1

I found a workaround for the problem, but I don't fully understand what was going on. In the VB.NET project whose assembly version the Edit and Continue compiler said was changing, there was a file called "AssemblyInfo.vb". That file contained the following line:

<Assembly: AssemblyVersion("3.0.*")>

The assembly version can also be set in the Project Properties, via the "Assembly Information" button in the Application tab:

When I removed the AssemblyVersion line from AssemblyInfo.vb, my Edit and Continue problem went away. At first I thought this was because the fields in the Assembly Information window were saved to a different file from AssemblyInfo.vb and there was some conflict between the two, but now I see that the Assembly Information window is just a handy way to edit AssemblyInfo.vb: if I delete the line in AssemblyInfo.vb, it gets cleared in the Assembly Information window.

After some more experimentation, it appears that the asterisk in the version number is the culprit. If I fully specify the assembly version, my Edit and Continue problem goes away. And the referenced project has to be a VB.NET project. I tried the same setup with a C# project, and I could Edit and Continue just fine.

This appears to be very much an edge case, and I'll submit a bug report to Microsoft, but in the meantime I'd love to know what is actually going on with the compiler--why it's getting two different assembly versions of an assembly that really shouldn't need to be recompiled during the debugging.... If you have a good explanation for what's happening, please add it as an answer.

Edit: here's the bug report I filed.

Dionisio

Apparently, your bug report has been removed... :-( – Gluttonous

BTW the asterisk provides a number which is based on the time of the day - see, e.g. this – Limoges

Annoyingly, This happens for me in a mixed vb/c# project, even if the project with a version-"*" did not change - but is in the "other" language. – Eliseo

Answer 2

This happened with me in a .net 4.8 app with Visual Studio 2019.

I have a mix vb and cs projects, here the problem appears when a vbproj references a csproj that uses the wildcast operator '*' to specify the version of the assembly.

As commented above by @Wai-Ha-Hee, the wildcast uses the current time, I belive when VS rebuild the application to apply the edits you have made, the version of the assembly changes causing the error.

In assemblyInfo file (of the project present in error) Change:

[assembly: AssemblyVersion("1.0.*")]

To:

[assembly: AssemblyVersion("1.0.0.0")]

It Solved for me.

An important thing to say is the use of wildcard '*' makes the assembly non-deterministic, it means each build produces a different assembly. This has been considered bad practice because build the source code in the same conditions generates different assemblies.

In Visual Studio 2019:

New csproj/vbproj with non-sdk style projects file are generated with:

<Deterministic>true</Deterministic>

And new csproj/vbproj with Sdk style projects file omits this line but assumes deterministic as default too.

I recommend considerate other ways to version the assembly.

More about Deterministic:
https://blog.paranoidcoding.org/2016/04/05/deterministic-builds-in-roslyn.html https://reproducible-builds.org/

Zamudio

Answer 3

One of my C# projects in a mixed solution was .NET Framework 2.0 (while others - both C# and VB.NET - were .NET Framework 4). After I changed it to .NET Framework 4 it began to work.

Stalnaker

Answer 4

Happened to me on VS2019 on csharp .NETFW 4.8 project (and no other project in the solution). None of the earlier answers in this page works for me. The fix for me is to remove this line in .csproj file:

<Compile Include="Properties\AssemblyInfo.cs" />

Bumgarner