We Keep Coding

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

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).

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.

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 wildcast '*' make 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:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/

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.

KryptonForm not showing in designer - Visual Studio 2013

I've added the toolkit.dll as a reference, inherited KryptonForm instead of Form, successfully built the application, everything is working fine, but designer mode fail to display the form. I am getting this error:
Could not find type 'ComponentFactory.Krypton.Toolkit.KryptonForm'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.

I found the issue: I renamed the dll thinking that will not affect in any way the application, and it didn't !
But somehow affects the designer: when I renamed the dll back to ComponentFactory.Krypton.Toolkit.dll Visual Studio's designer worked aswell. I am curious why behaves this way

Weird: C# Type or Namespace name could not be found - Builds successfully

I have a weird error showing up in my project when it is open in the VS2012 IDE. Everywhere where I make use of another referenced project it suddenly says "Type or Namespace name could not be found". And by "says", I mean it has the text underlined in red with the error when I hover over it. The intellisense doesn't work for that code. BUT (and here's the weird part), the errors do not show up in the error console and the project builds and runs fine.
I can even debug and step through the code and it works perfectly fine. So at runtime the project is referenced fine but at design time the IDE can't find it. This worked for the past 2 weeks, and only then suddenly went a little bonkers. It's really annoying because I am rubbish at coding without intellisense!
Has anybody ever seen anything like this or have any suggestions?

I had this. I referenced assemblies whose "Target Framework" were set to ".Net Framework 4" in the "Application" secion of the projects properties. I changed this to ".Net Framework 4.5" not just in the referenced assembly's project but also the project I was building and it worked. Give this a try.

I have found this is a known problem with VS2012. Check to see how you are building, 64 bit or 32 bit. It won't work with 64 bit but it will with 32 bit. It will say things are missing and design will not work, however the program will run fine. I have heard the new VS update that hasn't been released yet will fix it.

Manually delete all the references to the libraries of the other projects and re-add. Intellisense rebuilds whatever it needs at that point and doing this has helped me in the past.

Another source of this problem is a solution with multiple projects containing code for the same namespace. The compiler can handle this. Intellisense won’t.

Related to a couple other answers here, I had a "Data" project using a "Data" namespace. Built fine, but just started recently showing errors from intellisense (even though it continued building fine.) (VS 2015.)
I fixed this by changing my "Data" project and namespace to "MyCompany.Data".
Oddly, the problem didn't seem to show up until recently, but making the change did fix it. Presumably there was a conflict in namespace with another project or reference, which can build fine, but intellisense can't handle.
You can change this in the Application tab of Project properties. You can also open up an EDMX diagram, right click, choose model browser, choose the second collapsable item in the model browser tab, hit properties, and there you'll find the Namespace option for generated Entity Framework entities and contexts. (Similiarly, if you modify an Entity Framework Model's namespace, you might also need to change the related connection to match [in Web.Config for ASP.Net and MVC.])

Make sure that there is no class with the name same as Project default namespace.

make sure that you don't reference .net framework 4.5 projects in .net 4 projects!

Examine your .proj files in a text editor and make sure the paths to your references are correct.

This can also happen if you set the Build Action to "None" on the referenced file and forget about it.

I had the same problem, where it would build and run fine, it just would always show that error and I couldn't use intellisense with the class.
I actually used the automatic method of creating the class in a new file to resolve the issue, then just copied the code over from the real class. I deleted the old file, renamed the new file, and now it works.

"Base class could not be loaded" - for no clear reason

I'm using Visual C# 2008 Express. This is the first time I've had this error in years, the last time I had it was around the time I started programming.
I have no idea what it actually means or why it suddenly came up, it seems rather ambiguous for what the error message says. All I know is that throughout my app, I inherit a lot of the main windows from a ThemedWindow class I came up with to give them a custom appearance, there are no errors in that code and everything was working 100% perfect 20 minutes ago.
The error in full:
Warning 12 The designer could not be shown for this file because none of the classes within it can be designed. The designer inspected the following classes in the file:
InheritingWindow --- The base class 'ThemedWindow' could not be loaded. Ensure the assembly has been referenced and that all projects have been built. 0 0
I get that for every form that inherits from ThemedWindow, and several other errors because the project won't build far enough for everything else to work.
Just before this happened I updated the font on all forms and sub-controls, the project even built and ran after I did that, then this happened for absolutely no clear reason.
I've tried the classic rebuild it, delete build files, reopen Visual Studio etc, but nothing seems to work at the moment.
Does anyone know how to fix this?

Build your base usercontrol class with AnyCPU option.

These problems were caused by an unfortunate bug in Visual Studio. I had other errors (not warnings) in some code, even though nothing else directly depended upon it, which played a part in this whole situation.
I could be wrong in explaining it but here's what I think went wrong: for some reason (bug), it totally forgot about unchanged objects it had already compiled before, gave me the actual errors I had in my code, and a bunch of other warnings because it wouldn't go past that point. I couldn't get into the designer for forms that depended upon ThemedWindow because I'm guessing ThemedWindow hadn't recompiled before these errors occurred.
Once I commented out the erroneous code as a quick fix and rebuilt the solution, everything compiled successfully.

As of writing this, this seems to be working properly in VS 2019 16.11.13.
It is not, however, working in VS 2022 17.1.6...
In VS 2022, I tried all the other fixes mentioned here, or they were not relevant:
AnyCPU is already set on the solution, never changed from that
The base class was never modified since it last worked, and so wouldn't need to recompile (plus this seems a moot point since it works fine in VS 2019)
While changing the base class temporarily to System.Windows.Forms.Form did get rid of the original error, it popped up a load of other errors of missing framework references and other non-problems.
The project is referencing .Net 4.8, (latest at time of writing this) and is not different from VS 2019 to VS 2022. Either way, can't reference non-existent newer version, and I doubt referencing an older version would fix this without breaking much more.
I saw a fix somewhere else of running VS as administrator and then rebuilding. This also did not fix the issue.
So I guess my fix for this is to downgrade from VS 2022 to VS 2019...

In my case (VS 2015 Pro) none of the above helped. Only after changing the target framework to different (specifically newer, from 4.5.1 to 4.5.2) and recompiling did the Forms Editor load the form.
Before changing the target framework I tried cleaning the solution, removing and adding the references (the base user control was in different dll), manually deleting all bin and obj folders after cleaning the project, restarting VS, all to no avail...

I have this problem too, with VS 2019 version 16.11.2, so I guess this bug will never be fixed.
My workaround, since my BaseForm class does all its work through code at runtime and has no functionality that would affect the designer, is that when I need to use the designer, I just temporarily change my window's base class. That is, change--
partial class MainWindow : BaseForm {
to
partial class MainWindow : Form {
then do the design stuff, and then once the designer is closed, put BaseForm back.
This may work for you if your base form class also doesn't do anything that would have an effect in the designer.

Error running aspnet_compiler on websites user controls

My builds and runs fine in Visual Studio, however when I run a Nant task to compile the website, it gives me an error:
[path]\ContactView.ascx
error CS0117: 'System.Web.UI.Usercontrol' does not contain a definition for 'Name'
I have a UserControl called ContactView that has another UserControl called ContactForm. Contact Form is the one who has the Name property (declared inline, there is no .cs file). I don't get why the error is on the parent UserControl, or even why it is complaining at all.
The code seems to run just fine when VS2008 builds and compiles it.
Any ideas?
I know the nant build scripts work for my 2.0 website, and in this websites web.config I added the 3.5 compilers. Is there anything I'm missing?
Edit: This error is actually showing up for every property on this user control and a few others. I don't know if it a single instance of this error is causing multiple failures or if all user controls are really invalid.
Update: The error has to be related to v3.5 of the framework, because it's also complaining about auto properties. When I switch them to have a backing field, it'll work.

It looks like you'll either need to use NAnt 0.86 Beta 1 or go with Palermo's fix. Use the -t option on the command line to target the right version. You'll also want to insure you have .NET 3.5 (and probably SP1) installed on the build server.
It's often easier to shell out from NAnt to MSBuild, since the latter supports .sln files.

It looks like the problem was that when you compile a website in updateable mode, you are not allowed to call public methods/properties in a user control with no code behind.
Once the code was moved to a .cs page, it worked.