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.

t4 template processing finding another copy of EntityFramework.dll

I have an issue where, when I run a T4 template, it is picking up another copy of the EntityFramework.dll in the VS Common7 folder. That causes it to think that my DbContext class does not inherit from System.Data.Entity.DbContext.
When I debug the T4 template I get the following in the Immediate window.
typeof(System.Data.Entity.DbContext).Module.FullyQualifiedName
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\EntityFramework.dll"
However that path is absolutely nowhere in my Modules window. The proper EntityFramework.dll shows up there from my build output for the project I'm referencing.
I understand I'm leaving out some detail here, and I'll fill in more to answer questions, but I am just at a total loss as to what would cause Visual Studio to pull in another EntityFramework.dll instead of using the one that I'm providing it. This all runs fine, by the way, if I directly run the code in a command line app or if I set the templating tool to TextTemplatingFilePreprocessor and run the generated class.
The line of code this is all erroring on is:
Database.SetInitializer<FakeDbContext>(null);
FakeDbContext being nothing more than:
public class FakeDbContext: DbContext
{
}
The error I get is, given the dll issue, predictable:
Method System.Data.Entity.Database.SetInitializer: type argument
'FakeT4Dependencies.FakeDbContext' violates the constraint of type
parameter 'TContext'.
It thinks FakeDbContext is not a DbContext. Which it thinks because of the dll issue. Interestingly, the issue is a run time error, not an error at compilation of the text transform class. I can tell that by the stack trace, the type of exception (VerificationException), and the fact that it's an exception and not a compile error.
If I run the code straight through my command line, by the way, you get what you would expect for the type. And everything works fine.
typeof(System.Data.Entity.DbContext).Module.FullyQualifiedName
"C:\\Users\\jeffreyvest\\Code\\TestT4Dependencies\\TestT4Dependencies\\bin\\Debug\\EntityFramework.dll"
The issue only comes up when running it through the custom tool by saving the .tt file. Somehow VS loads things up just a bit differently and it wants to go off and use a different copy of the dll that I do not want it using at all. Incidentally, that copy is the same version of EntityFramework.dll. Just the fact that it lives in another assembly, and not the one referenced by my code, is throwing it off. The deepest mystery for me is the fact that it does not show that dll anywhere in my module list. It shows the other copy in my bin/debug of the project whose output I'm using. So it appears that's all getting bound up correctly then suddenly at the last minute somehow the type itself gets associated to a different dll. It would even be ok if it used nothing but that other dll in Common7 folder. It's the mix that's making it all go wonky.
EDIT
As an added fun twist, changing the assembly referenced in the T4 to use that Common7 copy of EntityFramework fixes the issue only when debugging the T4. When running it straight (just saving the .tt file) it still has the issue described.
I also put this together that I think really illustrates the issue.
typeof(FakeT4Dependencies.FakeDbContext).BaseType.Module.FullyQualifiedName
"C:\\Users\\jeffreyvest\\Code\\TestT4Dependencies\\FakeT4Dependencies\\bin\\Debug\\EntityFramework.dll"
typeof(System.Data.Entity.DbContext).Module.FullyQualifiedName
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\EntityFramework.dll"

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.

Get Visual Studio to highlight Razor syntax with a custom host factoryType

Here's the scenario, I've extended MvcWebRazorHostFactory so I can do a little bit of extra view magic at build time. The exact magic doesn't matter.
The registration in my ~\Views\Web.config looks like so:
<host factoryType="StackExchange.MyNamespace.MyFactory, StackExchange.MyNamespace" />
There's to the appropriate assembly in the project, a copy of the assembly in a \lib folder, and I've confirmed that it's copied to \bin as expected. Furthermore, the actual view magic does happen when views are built so ASP.NET itself is actually finding everything.
What doesn't work in Visual Studio (2012)'s Razor Syntax Highlighting.
Above is a snapshot of how the syntax highlighting fails. As a rule, anything not in a namespace directly #using'd cannot be found (and thus gets the red squiggly underline) and the #model directive doesn't works. This points to some trouble getting at our automatically included namespaces in the Web.config.
The tooltip for the error on #model is "The name 'model' does not exist in the current context".
Through trial and error I've narrowed the root cause to the above host config section, although we have some other tweaks around Razor (a custom pageBaseType for example) it's that one line that breaks everything.
Things I've tried thus far:
Strong naming the assembly
Installing the assembly in the GAC
This page hints at this being necessary.
When strongly named my ~\Views\Web.config ended up looking like so:
<host factoryType="StackExchange.MyNamespace.MyFactory, StackExchange.MyNamespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b61d663b67b05bd2" />
I checked the Version, Culture, and PublicKeyToken against the GAC using "gacutil -l".
I suppose one other possible point of failure is the GAC itself, as there are ton of .NET versions on my box. Both the assembly and the web site are built with .NET 4.5 (both referencing MVC 4, Razor 2, and so on). The path to the gacutil I've been using while debugging is Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe.
Occasionally during my winnowing to a root cause I'd get an error message to the effect "StackExchange.MyNamespace.MyFactory could not be found" on the first line of a view. The underline would be in the "Other Error" color (Purple in VS2012 Dark Theme). I could not reliably reproduce that, so I can't get a screenshot.
So my question is, does anyone know how to get Visual Studio (2012 again) to properly handle Razor Views with a custom host factory?
My current best guess at a fix is doing some really hacky Web.config replacements so I have one config while editing and another while debugging. Really not a fan of that idea though.
It seems like this should work, and that Visual Studio is just having troubling finding something it needs. I just don't know what that is.
Update after some more experimentation.
I've got more developers to reproduce that it's the <host pageFactoryType="...">, including in a vanilla MVC4 application (the above examples are, somewhat obviously, from the StackOverflow solution; which might have had some cruft).
We have found a work around though, it's to buy a ReSharper license. Not a great (or cheap) work around, but a work around none the less.
With ReSharper installed everything works with one caveat. If you have a custom <pages pageBaseType="..."> registration the type must be in the same project, or you don't get intellisense for #this.Model reference (the #model directive works though).
More updates.
Looks like a no-op HostFactory (one that extends MvcRazorHostFactory but doesn't override any methods or contain any other code) works fine if you strong name it and install it in the GAC. I believe I was using the wrong GAC when testing that earlier, but (with some outside prodding) was able to get it working using the explicitly x64 gacutil.
Now the trouble is figuring out what's wrong with my particular host factory; more details coming as they're discovered.

After some discussion with Microsoft, we found the root cause of this problem.
As usual, it was my code.
The root error was an MVC3 reference in the custom factoryType, despite the project (and everything around it) being MVC4.
To sum everything up, to get Visual Studio IntelliSense working in .cshtml files with a custom <host factoryType>:
You must strong name your assembly
You must install the assembly in the GAC
We still debug and deploy against a local copy, but VS will look in the GAC
You must have all the right references*
Be aware that you'll need to restart Visual Studio after installing into the GAC, simply reloading the solution is not (usually) sufficient. We've also found that some (but not all) ReSharper installations will need their cache's cleared, to be on the safe side clear the cache.
One minor trip up when adding a reference to an assembly that resides in the GAC is the Visual Studio won't copy it to your output directory by default, this may work for you but caused problems for us. You can change this in the properties of the reference.
Also, Visual Studio will give you a number error messages (the "Other Error" purple underline I was unable to reliably reproduce earlier) if your custom factory throws any exceptions; except perhaps in it's constructor (that seemed a little inconsistent).
Where you get no help is the case we were in, where the type itself has serious issues. It was just a coincidence that things worked at runtime (the interfaces we're playing with didn't change between MVC3 and MVC4, and weak naming did the rest).
*If you're like us and have MVC beta 1 through 4 installed, be aware of the PEBKAC in this step.

WinForm designer error open designer

I work on VS 2010 .net 4.0 , my app had winForm with many controls.
sometime i occur very starnge designer error:
Could not find type 'Namespace.TypeName'. 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.
The variable 'ControlName' is either undeclared or was never assigned.
i click Ignore and Continue the control disappear from my form.
if i look in designer.cs the controls are exists..
I read this : link text but it is in vs2003 and i can not sucess solve this problem..
Thanks..

This problem can be caused in a number of ways, usually by custom controls/components that:
Do not have a default constructor
Depend on variables that are set at run-time (singleton instances, data sources, etc)
Fail to compile (you can't use a control in the designer until it compiles successfully)
Have been significantly changed/rewritten since they were added to the form
It can also happen as a result of a glitch in Visual Studio - this is much rarer, but can usually be fixed by cleaning and rebuilding your solution and/or restarting the IDE.