We Keep Coding

Visual Studio doesn't show me the red squiggle Intellisense errors [duplicate]

My Visual Studio (2008) Editor has stopped to underline Errors (this nifty wavy red lines). I can't really tell when, but it can be related to the installation of .Net Framework 3.5 SP 1 or the MVC Beta (which I guess is unlikely). Furthermore have I installed and uninstalled both CodeRush and Resharper for evaluation purposes (decided not to keep either one of them).
Does anyone know the problem and how to restore this functionality again?

Have you checked Tools→Options...→Text Editor→C#→Advanced→Underline errors in the editor?
I usually like to reset my settings after messing around with plugins, as they tend to mess with settings: Tools→Import and Export Settings...→Reset all settings.

About possible causes.
For VS 2012 and 2013 if you have more than one instance of Visual Studio on different machines binded to one "live" account and have installed ReSharper on one of them, it disables the native IntelliSense and error underlines (to replace by it's own rules) that will be synchronised through your account to another machine without ReSharper.

Found it in Visual Studio 2019 as: Tools > Options > Text Editor > General > Show error squiggles

This is generally called Disable Squiggly or Wavy lines in Visual Studio.
How you will do in Visual studio 2013?
TOOLS -> Options... -> Text Editor -> C/C++ -> Advanced -> Disable Squiggles: True/False (Under IntelliSense) -> Press OK

I know its an old question, and with various solutions, but I have fixed it in different way. I'm working with Unity3D on my C# code using VS2017, when suddenly VS decides to stop underlining error while im typing. However, if I close the file tab and reopen, it suddenly undelines the error.
For example:
class A {
public int x;
s;
}
should obvsiouly give an error for that lonely 's' symbol. But, VS doesn't underline it until I close and reopen this file tab.
Solution:
Copied the entire Unity Project folder (which is like a regular VS Solution folder basically) and worked with the new folder, which issue was gone there.

For visual studio 2017 act according to HeeJae's comments in:
https://developercommunity.visualstudio.com/content/problem/113112/design-time-error-checking-isnt-working.html
i.e:
Hi. you are probably hitting a known issue. can you try this?
1.Update to latest release If that doesn’t solve it
2.Go to Tools\Options\Projects and Solutions\General and uncheck “Allow parallel project initialization”.
3.Close VS.
4.Delete the “.vs” directory beside their solution file.
5.Reopen VS.
..
thank you
You can re-enable the "Allow parallel project initialization" option after the issue was solved.
I tried to upgrade VS, reset VS settings, clear VS cache and everything people do conventionally but none of them solved this issue! At the end the mentioned solution worked for me magically.
Good luck

Unloading and loading same project again from the solution does the trick. Just right click on the project and click "Unload Project". Once unloaded, again right click the same project and click "Reload Project". Error highlighting will return.

I had the same issue with 2017. There was a 'disable intelisense' option, make sure that is set to false.

For everyone wondering in 2021..
search for "C_Cpp.errorSquiggles" in the settings.
Make sure to have it active for the user, as well as the workspace.
No need to restart Visual Studio.

For me (VS 2019) , after trying the other answers also, setting the scope of analysis from "Current document" to Open document" brought back the missing error markers

Just go to settings and search for errors and Image in Error Squiggles. You can see the Error squiggles (Modified: Workspace - Right now you can't see it because I modified it). Just click on modified and you will see the disabled option. If by mistake you disabled it, just enable it and you can see the red line errors again in your code.

In latest edition, check for .vscode folder in same project folder. There will be a setting.json file in that. Delete the key value pair of "C_Cpp.errorSquiggles": "Disabled". Restart the vs code.

Visual Studio 2012 issues opening solution [duplicate]

I have an ASP.NET MVC4 application solution (.sln). When I close Visual Studio and then reopen it and my solution, my tabs and my navigation structure in the solution explorer do not restore to the way they were.
The solution is big and it takes me a long time to reopen many tabs and open lots of folders in the solution explorer.
Is there an option in VS that would allow me to restore the solution to where it was when I left it?
I've already done "Reset all settings" in the Import and Export Settings Wizard, but it didn't help.
I've also tried booting VS in /SafeMode which disables any extensions. No difference.
Searching around I can't see anyone have similar issues.

As far as I know the .suo-File saves which files are opened. Try to delete this file (VS will generate it new) and make sure that windows-file-permissions are set correct (read, write access).

I had the same problem with Visual Studio 2013, and I solved it by doing this:
Export my current settings, making sure to UNMARK General Settings > Window Layouts.
Re-import the settings I just exported, but making sure I left General Settings > Window Layouts MARKED now (so it would overwrite the current Window Layouts with the "clean slate" of the imported settings.

Perhaps you can try the Workspace Reloader plugin that Scott Hanselman blogged about?
http://www.hanselman.com/blog/IntroducingWorkspaceReloaderAVisualStudioAddInToSaveYourOpenFilesAcrossProjectReloads.aspx
You can install it from here - http://visualstudiogallery.msdn.microsoft.com/6705affd-ca37-4445-9693-f3d680c92f38

Got this issue also for Microsoft Visual Studio 2022 Community Edition.
How to fix :
First, be sure, that tools->Project and solutions->General:'Reopen documents on solution load' and 'Restore Solution Explorer project hierarchy state on solution load' enabled
Second, just close VS and delete .vs folder, then re-start VS.
Works fine for me

"Publish Now" button doesn't work, but Build>Publish does

In Visual Studio 2010, I have just one project that cannot be published using the "Publish Now" button.
If I publish using the menu option instead, it works fine. I can then increment the version number, click "Publish Now" (or use "Publish Wizard..."), and get this error:
Cannot publish because a project failed to build.
However, no other error message is given. I managed to get screenshots of the output screen before it clears and flips to the Error List tab, but there is no mention there of any error. Clean & Rebuild doesn't fix the problem.
What do these two options do differently? Why is the build failing one way but not the other?

Since "rebuild solution" and "clean Solution" are not solving these issues, it might be either logs or assemblies in Bin.
This error seems to be caused by various issues :
Solution 1. set the build log verbosity to Diagnostic from the menu Tools->Options->Project and Solutions->Build and Run in Visual Studio 2010.
After that, if you build and publish your project, you can see the detailed build log from the Output window. From there, we should get futher information about why it failed to build.
Solution 2. Do you have Google Desktop by chance? If you do, close the sidebar and try once.
Solution 3. Click here for an another solution
Solution 4. Do you work with people from other timezones ? Files modified in future time may also cause this issue. check this utility
Solution 5.
I suggest you to try running the Visual Studio in safemode that will force the visual studio loading only the default environment and services, and shipped versions of third party packages. If the problem disappears you may stuck with some version of IDE tools with bugs. update them then.
If nothing seems to work, try this.
*Solution 6*
After researching it, it appears that the built in build/publish script that Visual Studio (2010 in our case) uses has a flaw in the order that it does things. Most importantly it runs a cleanup on the OBJ directory deleting the target EXE file before the publish step can grab it.
The solution
This is somewhat of a hacky workaround, but it solved the problem for me.
The fix is to copy the file back to the /obj/ folder from the /bin/ folder right before the publish step. Unfortunately there is no way that I know to specify a BeforePublish event through the IDE, so you will have to edit the .vbproj file in a text editor.
Add the following section just before the final tag.
<Target Name="BeforePublish">
<Copy SourceFiles="$(TargetPath)" DestinationFolder="$(IntermediateOutputPath)" />
</Target>

Clean and Rebuild worked for me. It seems like Google desktop and some browser extenstions causing this bug often. looking for a security update is good way to go with this.

I eventually created a new branch, and that branch did not have this problem. I never discovered what the actual cause was.

Visual Studio displaying errors even if projects build

I have a problem with Visual Studio on a C# solution. It displays totally random errors, but the projects build. Right now, I have 33 files with errors, and I can see red squiggly lines in all of them.
I tried cleaning / rebuilding the solution, closing Visual Studio and even restarting my computer. I can modify .cs files and I see the changes in the solution.
Does anyone have an idea about why it does that?

If you have ReSharper, try emptying the ReSharper cache:
In menu, ReSharper > Options > Environment > General > Clear Caches
and disabling and re-enabling ReSharper:
In menu, Tools > Options > ReSharper > General > Suspend / Restore

Clearing Resharper's cache did not help in my case, tried suspend/restore, and also Repair Resharper, using latest download off JetBrains' website - neither of these helped. This is after I tried close/reopen VS, restart my machine, repeat, Build/Rebuild and combination thereof.
It's interesting that suspending Resharper seemed to solve the problem after the 2nd restart of VS, but it was back after I enabled Resharper <-- I tried to do this sequence 2-3 times to ensure the pattern.
Anyway, I was still having issues when I found this article:
Quick tip: What to do when Visual Studio freaks out and everything is red
So I deleted the hidden .SUO file on the same folder level with solution, and it magically solved all reds.
Note - for Visual Studio 2015, the .SUO file is in .vs/[solution_name]/v14 hidden folder.

tldr; Unload and reload the problem project.
When this happens to me I (used to) try closing VS and reopen it. That probably worked about half of the time. When it didn't work I would close the solution, delete the .suo file (or the entire .vs folder) and re-open the solution. So far this has always worked for me (more than 10 times in the last 6 months), but it is slightly tedious because some things get reset such as your build mode, startup project, etc.
Since it's usually just one project that's having the problem, I just tried unloading that project and reloading it, and this worked. My sample size is only 1 but it's much faster than the other two options so perhaps worth the attempt. (Update: some of my co-workers have now tried this too, and so far it's worked every time.) I suspect this works because it writes to the .suo file, and perhaps fixes the corrupted part of it that was causing the issue to begin with.
Note: this appears to work for VS 2022, 2019, 2017, and 2015.

I cleaned solution, closed VS, reopened it, build solution, and red unresolved lines were cleaned and build succeeded.

I found that happens frequently when using Git in Visual Studio 2017, switching branches where there is dependent code changes. Even though the project will build successfully, there will remain errors in the error list.
These errors are often namespace issues and missing references, even when the library reference exists.
To resolve:
Close Visual Studio
Delete the {sln-root}.vs\SlnName\v15.suo file (hidden)
Restart Visual Studio

I have tried all the 6 options, nothing worked for me. Below solution resolved my issue.
Close VS.
Delete the hidden ".vs" folder next to your solution file.
Restart VS and load the solution.

Here's a collection of popular answers. Upvote the OP of the answer if it helped you:
Option 1: Clean, Build and Refresh (#Mike Fuchs option)
As #Mike Fuchs mentioned, try the following operations:
In menu, Build > Clean Solution
And
In menu, Build > Build Solution
and select the project in question, and click on the refresh button:
Option 2: Clean, Close, Restart and Build (#Pixel option)
As #Pixel mentioned, try the following sequence of operations:
Clean the solution
Close Visual Studio
Open Visual Studio
Build solution
Option 3: Clear ReSharper cache (#GammaOmega option)
If you have ReSharper, try emptying the ReSharper cache:
In menu, ReSharper > Options > Environment > General > Clear Caches
and disabling and re-enabling ReSharper:
In menu, Tools > Options > ReSharper > General > Suspend / Restore
Option 4: Delete the .suo file (#Neolisk option)
As #Neolisk mentioned, deleting the .suo file might solve your problem. For Visual Studio 2015, the file is located in:
[Path of Solution]/.vs/[Solution Name]/v14/.suo
And for Visual Studio 2017:
[Path of Solution]/.vs/[Solution Name]/v15/.suo
Note that the .vs directory is hidden.
Option 5: Unload and Reload Project (#TTT option)
As #TTT mentioned, try unloading the project that causes problems:
In Solution Explorer, right-click on project, Unload Project.
And re-loading it
In Solution Explorer, right-click on project, Reload Project.
Option 6: Remove and add Microsoft.CSharp reference (#Guilherme option)
As #Guilherme mentioned, try removing and adding the reference to "Microsoft.CSharp" from the projects that have problems.
In Solution Explorer, expand the project, expand "References", right-click on "Microsoft.CSharp" and Remove.
Then, right-click on References > Add Reference, select "Microsoft.CSharp" from the list and click OK

Delete the hidden file path = your solution\ .vs\ your solution Name \v15\ .suo

I had a problem like this where Intellisense didn't seem to recognise the existence of one project (lots of "can't find this type", "this namespace doesn't exist", etc. errors).
Removing and re-adding the project reference in all the referencing projects would fix the issue, but the underlying cause could be fixed by editing the .proj file of the problem project.
Near the top of the "missing" project' .csproj file is an element:
<ProjectGuid>{GUID}</ProjectGuid>
and in all of the referencing projects .csproj files were project references:
<ProjectReference Include="..\OffendingProject\OffendingProject.csproj">
<Project>{ANOTHER-GUID}</Project>
<Name>Offending Project</Name>
</ProjectReference>
The referencing GUID didn't match the project's GUID. Replacing {GUID} above with {ANOTHER-GUID} fixed the problem without having to go through every referencing project.

So many things that could cause it, as evidenced by the long list of answers here. Here's what fixed it for me, having tried pretty much everything else first.
Build your sulution in DEBUG mode. Then build it in RELEASE mode (it shouldn't build when it has red wavy lines, but in my case it was just warnings that should have had green wavy lines but it was getting in a muddle and giving them red wavy lines, and it built anyway even in release mode). Then build in in DEBUG mode. Spitting on your hands and turning around three times optional.
Worked for me, when nothing else did.

for VS-2017, deleting .vs folder worked for me.

Following solution worked for me
1 - Close VS
2 - Delete .vs folder
3 - Open VS
4 - Build solution

I've noticed that sometimes when switching git branches, Visual Studio (2017) will not recognize types from some files that had been added in the second branch. Deleting the .vs folder solves it, but it also trashes all your workspace settings. This trick seems to work well for me:
Solution Explorer -> Find the file with the unrecognized class in it.
Click Show All Files at the top of the Solution Explorer.
Right-click the file -> Exclude from project.
Right-click the file again -> Include in project.
This causes Intellisense to parse the file that it missed when switching branches.

Occasionally I have to do a custom clean by going through all of the projects and manually deleting the "bin" and "obj" folders. To see them in Visual Studio, you'll have to enable hidden files and folders for each project. After this is done, rebuild the solution.

My symptoms in VS2019 were that I would build with some errors. Then I'd fix the errors, and the build would work, as shown in the Output window. But the Errors windows still showed the old errors. I could run it just fine. Closing VS2019 and reopneing fixed the issue, but only for a little while. This started happening on version 16.4.3
This solution seems to work for me:
Uncheck Tools->Option->Projects and Solutions->General->Allow parallel project initialization
I found this fix buried way down in the comments here: https://developercommunity.visualstudio.com/content/problem/483450/vs-2019-intellisense-reports-compile-errors-when-r.html

Perhaps you try to reset your intellisense cache. I've had a similar issue in visual studio 2012 when working in a large project with many partial class definitions.
Reducing the partials solved the problem partially, clearing the intellisense cache also - for a while.

Deleting .vs folder solved my problem.
But it also reset my solution's current settings in VS. Like, my unloaded projects in the solution were re-loaded and all the pinned and opened documents were also closed when I restarted the VS.

0 - Right click on the Solution and clean solution
1 - Close VS
2 - Delete project's .suo file
3 - Open VS
4 - Build solution

A colleague of mine experienced this issue today. We tried many of the recommendations here and none worked except the solution described below.
Problem:
Project builds fine but Intellisense fails to recognize certain types and marks particular using statements as invalid.
Solution:
Change the 'Solutions Platform' (in VS 2017 this is the dropdown next to the Solution Configuration dropdown and has values such as x86, x64, AnyCPU, Mixed Platforms, etc.) to AnyCPU.
The platform for your project may vary, but it seems as though some references may not be valid for all platforms.

In my case helped a combination of things:
deleting all old not needed files which were previously excluded from the project
closing VS
deleting all the bin folder contents
deleting .vs folder
Clean/Rebuild
after that I still had some spurious errors, however the amount was significantly lower (from 200 to around 8) and the errors referred only to a resource dictionary path in Generic.xaml e.g. <ResourceDicitonary Source="example/path/somefile.xaml"> when I played around with the path trying to change it to a wrong one re-building then correcting it and rebuilding again, then this finally cleared all errors. It was specifically WPF project if that's relevant.

For my specific case it was a service reference another developer merged into the main branch. Which was perfectly fine except syntax highlight failed to resolve the generated service class and source was all red underlined. Cleaning, rebuilding, restarting did nothing.
All I had to do was refresh the service reference and VS managed to put the pieces together behind the scenes. No changes in the source code or generated files.

I've just ran into this issue after reverting a git commit that added files back into my project.
Cleaning and rebuilding the project didn't work, even if I closed VS inbetween each step.
What eventually worked, was renaming the file to something else and changing it back again. :facepalm:

After trying all of the options listed I discovered yet another reason why this can happen. If somebody sent you the source code as a zip, or you downloaded a zip, Windows may have blocked all files. 2 ways to solve this:
Method 1:
Right click on the original Zip file -> Check 'Unblock' -> Click apply
Method 2:
If that's not an option, rather than opening properties on every file in the solution folder simply open power shell and unblock recursively using the following:
Get-ChildItem -Path 'C:\<ROOT FOLDER OF SOLUTION>\' -Recurse | Unblock-File

first close the solution.
then solution cache file delete( in location C:\Users\Documents\Visual Studio\Backup Files/project cache file)
then .suo file delete
then solution open and build.
I hope solve your problem

Had this issue at work (running VS2017). Tried all of the answers here. No joy.
The project would build just fine, but was complaining that namespaces / types couldn't be found. Red squiggles all over the place. Lots of errors in the Error List window.
My solution contained 3 projects.
Discovered that 3 of the NuGet library references for one of the projects was out of line.
Consolidated the referenced library versions, and Bingo.
Hope this helps someone.
Brett.

Unload & reload the project fixed this problem.

I've been struggling with this issue for over a year and none of these solutions helped me:
Delete .suo
Delete .vs folder
Delete any or all cache / temp folders
Delete obj / bin folders
Unload / reload project
I finally fixed this issue - I opened the vbproj/csproj file in notepad and noticed that in the ItemGroup section, there was a reference back to my main project dll. I deleted this reference, reopened my solution and the problem was fixed.

Sometimes if you just clean solution the errors are disappearing, but they may eventualy come back afer a while or at the next build.

Ran into this issue with a single type not being recognized by Visual Studio which showed the red squiggle even though the solution built successfully. I noticed in the Solution Explorer the file did not have the expand arrow on the left which shows classes and properties on expansion.
The fix was to Exclude the file from the project and save/build which produced an expected error and then Include the file in the project and save and build.
After performing these steps Visual Studio started to recognize my type again. Looking at the diff in git it appears the issue was due to line endings not matching on the <Compile Include="..." /> line of my .csproj file.

in my case vs was never retaining the imported namespaces in the project properties > references
when I tried to add/check them again I couldn't and vs threw an error and when saved project vs crashed. When I reopened all the standard imported namespaces (system.data etc...) were all ticked again and it then was recognising everything without error

Edit and continue feature stopped working in Visual Studio 2010

The Visual Studio Edit and Continue feature stopped on Visual Studio 2010, and I don't know what has caused the problem.
I am working on a Windows application program using C#. This application was initially developed in Visual Studio 2008, and later upgraded to Visual Studio 2010.
Everything was working fine, including Edit and Continue, until I upgraded the .NET Framework from 3.5 to 4.0.
Now when I use debug mode, changing any line of the code in the IDE results in the following message:
Edits were made which cannot compiled. Execution cannot continue until
the compile errors are fixed.
Actually, there are no compilation errors, and I must restart the Visual studio to get the updates to run.
How can I get Edit and Continue to work again?

In the Solution Explorer view, right-click on each reference of References, choose Properties. In the Properties view, sign False to the field of Embed Interop Types. This works for me.

The Edit and Continue feature does not work with the dynamic keyword.
I tried to remove the method that uses a dynamic parameter, and the converted project now works on Visual Studio 2010.
Internet research reveals that is is a bug that has been reported to Microsoft. The link below has more details:
Dynamic object as method parameters breaks edit and continue for the class and the project

I had some Excel file "embed interop types" == true. When I changed it to false, edit and continue started working.

I had used Microsoft's profiler yesterday and afterwards my "Edit and continue" feature got away. I finally realized after hours of frustration that I needed to execute VsPerfCLREnv /globaloff command from command prompt and restart my computer. Now I have my Edit and continue future back. It has nothing to do with target platform by the way. It works with target platform set to Any CPU without any hassle.

I understand this post is old, but I had this issue lately, and this blog post shows me how to fix it.
Delete the obj folder
Delete the bin folder. You can copy and paste libraries, data files, etc...back to the folder after removal.
From VS, menu Solutions -> Clean solution.
This works for me multiple times.

I had this problem in Visual Studio 2013, and :-
Sometimes just closing and reopening the solution works, but when that doesn't
restarting Visual Studio (Close solution, exit Visual Studio, Re-open Visual Studio, re-open solution, re-try debugging with Edit & Continue) fixes it.
In my case, I didn't have any Interop types that were embedded, nor did any of my code have the dynamic keyword, and I had performed a full solution clean without success. I had been running, debugging and re-starting many times, however, so it may have had something to do with memory -- it took Visual Studio more than one minute to close, during which time the disk was thrashing (presumably memory paging at play).

I'd try cleaning out all the files that are generated by VS. So I'd delete the bin and obj directories and I'd also delete the *.suo and *.user files. Since those files are auto-generated this shouldn't affect anything (though I'd obviously make a backup of all files just in case there's some other files that have been put in there by mistake).
Sometimes those files can get corrupted (it used to happen quite a lot in the old VC++ etc) and then VS can start acting very funny.

I tried all the above solutions none of them worked for me. However, when I deleted the bin and object folders in visual studio and run again, it start to work.

In my situation, someone added a Reference to the Project's output into the Reference list: in Solution Explorer look under [ProjectName]\References for [ProjectName*] and remove it.
If the project is relying on code from a copy of itself, you can't 'Edit and Continue'. In the warning list you may or may not (more likely to in a larger project) have 'conflicts with imported type' messages if this is the cause of the problem.

working with VS2017 community I had this aggravating problem: if you port an existing project the tag EmbedInteropTypes may not be in the .csproj file yet, a search is futile. If that's the case, add the tag at the end to the property group Debug|x86 (or whichever you use) to the .csproj with a text editor:
before:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DocumentationFile>bin\Debug\MyProject.XML</DocumentationFile>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
after:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DocumentationFile>bin\Debug\MyProject.XML</DocumentationFile>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<Prefer32Bit>false</Prefer32Bit>
<EmbedInteropTypes>false</EmbedInteropTypes>
</PropertyGroup>
This must be done with all projects that belong to the solution!

In VS2013 I had to enable "Use Managed Compatibility Mode" in the debugging options. I think it is because I have a .Net 4 project referencing a .Net 2 assembly.
For another project in the same solution I had to uncheck "Define TRACE constant" in the project properties.

In Visual Studio 2015, I've deleted the .vs folder (where the new style .suo file is), deleted all bin and obj, and also uninstalled Resharper 2015.
Edit and Continue is back.
(side note: intellisense is now showing autocomplete almost instantly, whereas it was taking 2 to 5 seconds before, maybe resharper's fault, and maybe unrelated...)

For me this was caused by Nuget failing to download a package (built for Net Framework) to a Net Standard project that was being referenced.
Nuget entered an infinite loop (look in the output window).
The solution was to turn off the 'automatic package restore' setting see: https://developercommunity.visualstudio.com/content/problem/26638/nuget-infinite-loop.html
to access this setting
Tools > Options > NuGet Package Manager > General

I had to uncheck "Enable Native Edit and Continue" in Tools -> Options -> Debugging -> General:

Reading the above, my UI project has Shell32 with "Embed Interop Types" == true. I changed it to false, and "edit and continue" started working.

In the Solution Explorer view, right-click on each reference of References, choose Properties. In the Properties view, sign False to the field of Embed Interop Types. This worked for me.

For who still gets this error even with Visual Studio 2017
No dynamic/Portable Class Libraries/Nuget packages or dependancy problems. No errors or warning highlighted by Visual Studio.
After hours spent trying all the solutions posted in this and other threads and webpages, the only solution that worked for me was to check-in, remove the Workspace and Map&Get again.
To remove the Workspace, Source control → Advanced → Workspace → Remove.
I'm using Visual Studio 2017 Community up to date and after a relatively fresh install on a new machine (one week and few work hours).
Methods I've tested with no success prior to the solution above
Made sure Edit & Continue was enabled in Visual Studio options. Untick and tick it back again
Deleting bin and obj for all project in solution
Clean and Rebuild all, restart VS / reboot in combination to the above
Checking compile options and Nuget packages and dll compatibility for the projects, inspired by this
Unloading the projects in various combinations to test dependancy problems or other issues (inspired by this)
Deleting solution an re-downloading it (without removing the Workspace)
Sign False to Embed Interop Types
Set <_ResolveReferenceDependencies> to true as explained here
Combinations of the above with restart of VS and reboots
After this, I made a check-in and downloaded the Solution on another machine running the same version of Visual Studio (2017 Community). As I didn't get the Edit&Continue issue there, I went for the Workspace removal.

In my case, what worked was unchecking "Require source files to exactly match the original version" in Debugging options. VS Community 2017 here.

Removing the * from the assembly versions of my referenced projects solved the issue for me.
From Github:
"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." -rhuijben
https://github.com/dotnet/roslyn/issues/28224
(At risk of being flagged, seems we have been suffering from VS Edit and Continue issues for over a decade. It's shocking to me that the Microsoft Visual Studio team hasn't cared enough to help developers by providing more verbose info when this occurs)

I tried all the above, none worked. It was apparently due to enabling some low-level debugging options (view registers...)
Tools -> Import and Export Settings -> Reset All Settings
resolved it

What worked for me was similar but not exactly like the accepted answer. I had an anonymous type created as a result of a LINQ query; i.e.
var thingy = (from thing in things select new { thing.Property1, thing.Property2 }).First();
When I changed the anonymous type to a tuple, the problem went away:
var (thing1, thing2) = (from thing in things select (thing.Property1, thing.Property2)).First();

I figured out one of the reasons my project was not letting me continue and edit while in debug mode.
You can not have two c# files with the same filename even though they are in different folders and different name spaces and might have different class names. I changed the class name and that still didn't fix it. You have to change the .cs filename.
.Net Framework 4.8 doesn't have this issue so .net core added this feature.

In VS 2015 this error was caused by a nuGet package I had recently installed. By uninstalling this package and reinstalling, the bug was fixed.