We Keep Coding

Why do I occasionally get this issue with breakpoints not being hit when trying to debug?

I recompile my solution, and when it starts in debug mode I get this warnings around my breakpoint saying that it won't be hit.
There is a copy of the source code file that is different.
Why would there be multiple versions of my source code loaded when trying to debug?
I even do a clean compile and still get this error.

Visual Studio is usually pretty good at detecting when your source code doesn't match the code signature of your attached exe or dll process. So I suspect that it is one of two possible issues:
Your debug session's Platform/Configuration (e.g. Debug/x64) doesn't match the .exe or .dll compiled architecture. OR
What you think is a "clean compile" isn't really clean.
The only source code that Visual Studio knows about is the one in front of you. But when Visual Studio is debugging an .exe or .dll, it is attaching itself to the .exe or .dll process, using reflection, and analyzing the code of that .exe/.dll. It determined that your .exe/.dll doesn't match the Platform/Configuration you wish to debug, or its reflected source code doesn't match the written code that is in front of you in Visual Studio's IDE.
When you say that you do a clean compile, make sure that it is really really clean (don't rely on the Visual Studio "Clean" feature. It's not reliable in all cases. For example, if you have created Build Events that copy contents pre- or post-compile. Instead, delete your project's /bin and /obj folders, then recompile. That will ensure your binaries always match your latest code for debugging. Do this a few times, and see if you still get the issue.

I had same error in VS 2019 .I solved that way;
Tools->Options->Debbuging->General and "Require source files to exactly match the orginal version" deselect that option

Setting up C# editorconfig Code Cleanup on build/save and commit

Our team want to enforce styling rules in our C# project. I read somewhere some time that Microsoft said that ".editorconfig is the future" so we want to use this. NOTE: We don't want to use ReSharper.
C# has a lot of great rules that can be defined in editorconfig now, see Microsofts own editorconfig guide
We want to use this, and enforce that the rules set in the editor config is followed both when coding in Visual Studio and enforce that the code commited to git is following the rules.
When adding the .editorconfig rules, we get great linting on our files like this:
Running a fully enabled "Code Cleanup" in Visual Studio 2019 it completely formats our code as desired:
Question 1: How can we make the "Run Code Cleanup" run automatically on save/build? Even if we set certain rules as severity ":error" the compiler still don't complain about issues in C# files on build.
NOTE: I have tried the plugin for Visual Studio called Format document on Save but it does not follow all the rules set in the editorconfig (only a few, like fixing tabs/spaces and end of file newline)
We would also like to make sure that all commits to our git repository gets formated.
There is a tool called dotnet-format that is supposed to format the code according to the editorconfig rules.
We would like to add a pre-commit hook that runs the following 2 commands:
dotnet tool install -g dotnet-format
dotnet-format
This would work fine, but the issue is that dotnet-format also don't fix the issues in files with code giving severity ":error".
dotnet-format behaves the same way "Format document on Save" does, only fixing a few things like tabs/spaces and end of file newline.
EDIT: dotnet-format appearently only supports a few of the rules for now as per their Wiki
Question 2: How can we, from a command line, run a command behaving the same way as the "Code Cleanup" command in Visual Studio 2019 does?

I am able just to answer the your first question:
I have been looking for this and I found a extension called Code Cleanup on Save, you will just have to install it and configure it at Tool->Options->Code Clean up on Save, decide what of your profiles you want to set and that's all,
I hope it will help you!

visual studio: How to ignore pdb not loaded warnings during debug?

While debugging, I do not want visual studio to be looking for *.pdb files from 3rd party *.dlls. For example I use Jetbrains Resharper TaskRunner for unit testing. To use it requires a reference to Jetbrains.Resharper.TaskRunnerFramework.dll. When I debug my application via the TaskRunner, I end up with something similar to this picture below:
Well, I'm not debugging the task runner. That isn't my code anyhow. I want Visual Studio to be "smart" enough (or have a setting) to automatically know to NOT concern itself with *.pdb files for anything that isn't my code. Is this possible?

Have a look at the Just My Code setting in Visual Studio. From the documentation, there's a section that sounds relevant, which discusses one of the effects of having this setting applied:
When you Step Into (Keyboard shortcut: F11) non-user code, the debugger steps over the code to the next user statement. When you Step Out (Keyboard: Shift + F11), the debugger runs to the next line of user code. If no user code is encountered then execution continues until the app exits, a breakpoint is hit, or an exception occurs.
You can enable Just My Code in the Visual Studio options under Debugging > General:

Add a .gitignore file to your solution and add all extensions you want to ignore
Add this in your .gitignore file *.pdb

Warning given when debugging source code in visual studio 2010

I had set breakpoint in source code but it will give me warning that source code is different from original one. It will not hit breakpoint.Hit location to allow change in source code. can anybody explain me waht is problem?

Checksum of source code file doesn't match checksum into the PDB file.
To solve that rebuild the solution.
Workaround: In Location property of a breakpoint check Allow source code to be different

This can happen when you compile & run a release build. In Release builds the compiler makes optimizations that may change or delete portions of code, take this example:
static void Main()
{
int x = 10 + 5; // <---- BREAKPOINT HERE
Console.WriteLine("Foo");
}
If you compile & run that code in a debug build, the breakpoint will be hit as usual. In a release build, the compiler will see that 'x' is never used, and will "optimize away" the entire line, which means the breakpoint will never be hit!

Do a Build -> Clean Solution, then Build -> Build Solution. Then try debugging again, ensuring the active config is debug.

You source code is not the same as on compiling time. You can stop, clean and rebuild your project.

I had this issue when I had a class library in one solution and a web project in another solution. While stepping through code in the websolution, it stepped into my class library. This caused the class library files to be opened in my web solution.
My problem occurred when I changed some code in my class library. As normal I did a build on both projects in the correct order. However, i would get the message saying the source code was different. This was because I had the older "view" of the class files still open in my web solution caused by the following option having been turned off.
Options > Environment > Detect when file is changed outside the environment
Closing the class files in my web project solved my problem. I am now changing that option.
Hope this helps someone.

The above suggestions didn't work for me when running unit tests--I was performing a clean and rebuild for the whole solution but the DLL and PDB files were not being deleted in the ~\UnitTests\bin\Debug directory, so I had to manually delete those files, then right-click on the UnitTests directory and choose "Build."
Please note that in my case I am using Visual Studio 2013 with update 3.
UPDATE:
Ended up creating a batch file to clean and build my solution, so that Visual Studio does not incorrectly leave certain project without rebuilding them:
msbuild.exe "MyClassLibrary\MyClassLibrary.csproj" /t:Rebuild /p:Configuration=Debug
msbuild.exe "UnitTests\UnitTests.csproj" /t:Rebuild /p:Configuration=Debug

Cannot obtain value of local or argument as it is not available at this instruction pointer, possibly because it has been optimized away

Visual Studio 2010 kills (there is no other word) data in one of the arguments of the function in the unsafe block.
What could cause this error? The following message shows by the debugger.
Cannot obtain value of local or argument as it is not available at this instruction pointer, possibly because it has been optimized away.

Go to Project Properties and under Build Make sure that the "Optimize Code" checkbox is unchecked.
Also, set the "Debug Info" dropdown to "Full" in the Advanced Options (Under Build tab).

Also
In VS 2015 Community Edition
go to
Debug->Options or Tools->Options
and check
Debugging->General->Suppress JIT optimization on module load (Managed only)

If you compile with optimizations enabled, then many variables will be removed; for example:
SomeType value = GetValue();
DoSomething(value);
here the local variable value would typically get removed, keeping the value on the stack instead - a bit like as if you had written:
DoSomething(GetValue());
Also, if a return value isn't used at all, then it will be dropped via "pop" (rather than stored in a local via "stloc", and again; the local will not exist).
Because of this, in such a build the debugger can't get the current value of value because it doesn't exist - it only exists for the brief instant between GetValue() and DoSomething(...).
So; if you want to debug... don't use a release build! or at least, disable optimizations while you debug.

In visual Studio 2017
goto Debug->Option then check Debugging->general->
and check this option

I just ran into this and I was running under Release build configuration instead of Debug build configuration. Once I switched back to Debug my variable showed in the watch again.

For web applications there is another issue which is important and it is selecting correct configuration during application publish process.
You may build your app in debug mode, but it might happen you publish it in release mode which omptimzes code by default but IDE may mislead you since it shows debug mode while published code is in release mode.
You can see details in below snapshot:

I have faced the same issue and the solution for me is change Solution Configuration from Release to Debug. Hope it helps

When I was faced with the same problem I just had to clean my solution before rebuilding. That took care of it for me.

Regarding the problem with "Optimize code" property being UNCHECKED yet the code still compiling as optimized: What finally helped me after trying everything was checking the "Enable unmanaged code debugging" checkbox on the same settings page (Project properties - Debug). It doesn't directly relate to the code optimization, but with this enabled, VS no longer optimizes my library and I can debug.

In my case, I was working on a web api project and although the project was set correctly to full debug, I was still seeing this error every time I attached to the IIS process I was trying to debug. Then I realized the publish profile was set to use the Release configuration. So one more place to check is your publish profile if you're using the 'Publish' feature of your dotnet web api project.

I found that I had the same problem when I was running a project and debugging by attaching to an IIS process. I also was running in Debug mode with optimizations turned off. While I thought the code compiled fine, when I detached and tried to compile, one of the references was not found. This was due to another developer here that made modifications and changed the location of the reference. The reference did not show up with the alert symbol, so I thought everything was fine until I did the compilation. Once fixing the reference and running again it worked.

As an additional answer for those experiencing this issue when debugging an Azure websites' web app:
When deploying from GitHub, for example, the code is compiled in Azure server optimized by default.
I tell the server to compile in a debuggable way by setting SCM_BUILD_ARGS to /p:Configuration=Debug
but there are more options. See this:
http://azure.microsoft.com/blog/2014/05/08/introduction-to-remote-debugging-on-azure-web-sites-part-3-multi-instance-environment-and-git/

In Visual Studio 2017 or 2015:
Go to the Solution right click on solution then select Properties-> select all the Configuration-> Debug then click OK.
After that Rebuild and Run,this solution worked for me.

Had the same issue before with a WPF application and all the solutions here did NOT solve the issue. The problem was that the Module was already optimized so the previous solutions DO NOT WORKS (or are not enough to solve the issue):
"Optimize Code" checkbox un-Checked
"Suppress JIT optimization on module load" checked
Solution configuration on DEBUG
The module is still loaded Optimized. See following screenshot:
To SOLVE this issue you have to delete the optimized module. To find the optimized module path you can use a tool like Process Hacker.
Double click your program in the "Process panel" then in the new window open the tab ".NET Assemblies". Then in the column "Native image path" you find all Optimized modules paths. Locate the one you want to de-optimize and delete the folder (see screenshot below):
(I blurred my company name for obvious reasons)
Restart your application (with check box in step 1 correctly checked) and it should works.
Note: The file may be locked as it was opened by another process, try closing Visual Studio. If the file is still locked you can use a program like Lock Hunter

Check to see if you have a Debuggable attribute in your AssemblyInfo file. If there is, remove it and rebuild your solution to see if the local variables become available.
My debuggable attribute was set to: DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints which according to this MSDN article tells the JIT compiler to use optimizations. I removed this line from my AssemblyInfo.cs file and the local variables were available.

In Visual Studio 2012:
Go to the project properties -> Debug -> Uncheck "Enable the Visual Studio hosting process"

I had the same issue. Tried all the above and found I also had to delete everything inside {PROJECT_ROOT}\bin\Release\netcoreapp2.2 and {PROJECT_ROOT}\obj\Release\netcoreapp2.2 for my project. Its definitely releated to publishing because although I use Deployment tools / bitbucket on my Azure Web App, I did try the Build >> Publish >> Publish to Azure because I wanted to inspect which files were actually deployed.