This is actually another part of this question.
Error settings breakpoints but only on some lines while debugging
I'm remote debugging a CRM 2011 plugin in vs 2010.
I'n one of my source files I can set breakpoint all throughout the code except in a few places.
When I try to set a breakpoint I get this error
"The following breakpoint cannot be set:" and "The Common Language Runtime was unable to set the breakpoint."
protected override void ExecutePlugin()
{
SetStateResponse response = new SetStateResponse(); // Breakpoint works
// Message switch
switch (_crmMessage) // Breakpoint error
{
case CrmPluginMessageEnum.Create:
Entity pimage = null; // Breakpoint error
if (_context.PostEntityImages.ContainsKey("postcreate")) // Breakpoint works
pimage = _context.PostEntityImages["postcreate"]; // Breakpoint error
break; // Breakpoint error
}
} // Breakpoint error
UPDATE
Also, in the modules window it shows the dll as Optimized: No User Code: Yes Symbol Status: Symbols Loaded
Two possibilities, already kind of referenced by the other answers:
Make sure you are using the Debug build of the assembly instead of
the Release build, because the Release build will remove or optimize
your code.
Make sure you are updating the version each time you
deploy the assemblies in Visual Studio (on project properties tab).
When you increment the version, CRM will be sure to unload the old
assembly version and reload the new one without an IIS reset.
I had this same issue when I had the project open in two instances of Visual Studio. The project which I was not debugging had a lock on the file and notifying me "This file has been modified outside of the source editor." After accepting the changes in my non-debugging solution, I no longer received the error and my breakpoints were hit in my solution I was debugging.
It sounds like there is a lot of possible causes to this error, but this did it for me.
I got this problem when I created a breakpoint using the Ctrl+B shortcut (see image attached), and I entered a name of a function which doesn't exist, so the breakpoint was added but caused an error. then each time I started the project it appeared that error.
Solution:
I deleted the breakpoint from the breakpoints list (see left bottom in image attached), select the breakpoints section, then select the item and click delete.
If you don't see the breakpoints section
You can retrieve it by hitting Ctrl+Alt+B
Further to your update about the DLL being optimised the lines you have indicated where breakpoints don't work will likely be optimised away as your entire switch statement does not do anything other decide whether or not to assign a value to a variable that is never used and does not live beyond the scope of the switch statement. As such the compiler will simply not generate any code for the switch statement as it does not do anything at all or the jit just gets rid of it at run time for the same reason.
I just had a similar experience and the way I worked through it was to put a breakpoint at the spot where the routine was called and then single-stepped into the routine until I saw exactly what it thought it was doing. In my case, there was a return that was preventing all the code in the routine from running, so the optimizer tossed it all out. Sometimes it's the stupid things, right? Anyway, if you start at a level higher in the call stack and step into the routine where the problem is, the reason for the problem might become more obvious.
Another cause of this issue I have just found if you are debugging against CRM is not updating the plugin registration points. Even if you copy the new DLLs to the target machine and attach remotely to that process that is not the DLL CRM will use. CRM will try to take a copy of an old version from its database until you rerun the plugin registrations.
An error which wasted a day and a half for me!
I got this error when start run debugging the project, and I solve it by Clean All Project and Rebuild All Project, after rebuild the error disappear.
Related
I have a line of code string managerFirstName = "test#test.com"; that is flagging as NULL. How is this NULL....its a string that is populated when its created....is there an error with my VS2013? or a setting I need to change?
It's not the highlighted line that is crashing - the IDE is highlighting the wrong line.
The stack trace you posted mentions RFS.DotNetNuke.Service.ActiveDirectorySynchronise.something. Try and look for a line of code that uses that object - probably the line of code above the highlighted line (GetManagerForOrgUnit). Examine each of the parameters for that call and see if you can find a null reference.
If the problem is code related, not build, this looks like a threading issue. Try wrapping the whole function in a lock, and looking for how contexts could be getting mangled.
I have had this issue with VS 2022. Where this happens I get null reference and errors. I have found that this was because my debug configuration was set to Release and not debug.
Try after removing Visual Studio component cache.
Close Visual Studio (ensure devenv.exe is not present in the Task Manager) Delete the directory:
%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache
Restart Visual Studio
This used to happen to me in VS2k13 a lot. Basically your code is not getting rebuilt. Even after a clean/rebuild, some code refuses to compile. What used to work for me was1. Clean/rebuild. 2. Make a code change in the area of code you are looking at. 3. Put a breakpoint in the calling method. 4. Debug and f11 step line by line to your code change.
Would just like to say thank you to everyone who helped me out with this Q....I found the cause...just above the
ADUser managerUser = GetManagerNameForOrgUnit(coreData.OrgAssignment_0001.OrgUnit.ID, coreData.PersonnelNo);
there is an if statement, which during testing always stops the code from hitting GetManagerNameForOrgUnit(), I have been manually stepping over this if.
I commented it out and the code works fine.
Thanks again
I faced this problem when I was manually skipping execution of few lines (apparently unrelated code section).
Here is the error
Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.
I am writing a simple console app and the first line of code is this:
List<MyObjectModel> list = MyObjectModel.GetNonCompletedReturns();
and the code for the function is:
public static List<MyObjectModel> GetNonCompletedReturns()
{
MyObject service = new MyObject();
List<MyObject> entities =
(from recs in service.Retrieve() where select recs).ToList();
List<MyObjectModel> models = new List<MyObjectModel>();
foreach (MyObject entity in entities)
{
models.Add(BindModel(entity));
}
return models;
}
and if I try to step through the code, as soon as I get back to the main of my app and hover over the list, I get the error message that I showed.
Can anyone help?
If your project is compiled in release (with optimizations turned on), you may see this. Have you tried the DEBUG configuration?
This error fires only when you are trying to use Watch dialog during debug.
Try to use some other technique to output the variables, like Debug.WriteLine, Console.WriteLine and so on.
None of the answers solved my problem so I'm posting the solution that helped me.
"If there is to much data in the parameters then this error can occure,
a simple solution is to make an object, not a struct because that's a dataobject.
Put this object in your parameters instead of all the different variables,
normally the problem will no longer take place."
Here's a little trick just in case you want to examine some objects and you are not able to change the parameters:
I've created a call to a new temporary function, inside the function from where I was unable to watch my object. Then, inside that new function I was able to watch my object. After the job is done, just delete the function.
While it's true that the "Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized" error appears when in release mode, most developers just ensure that their projects are configured to compile as a debug build. BUT to be sure that you have no release-DLL issues, you also must check the references to DLLs that are in your solution and make sure that you don't have a reference to a release-build DLL. If you find that this is the case, delete the DLL reference and then add a project reference rather than a DLL reference. The project reference will ensure that your solution references debug or release versions of the DLL as specified in your build configuration.
Note that the above advice applies, of course, to only those DLLs to which you have source code and which are built from a project in your solution.
I got this too, when I hit a NullReferenceException from a 3rd party control.
In this one case, I found that if I set a breakpoint before I hit the exception, I could then single step through the rest of the code without seeing the problem.
No idea why, but this worked for me - in this case at least.
For what it's worth, this error can also be caused by an infinite loop in a property getter (simplified version below). When the debugger attempts to evaluate the property (e.g. in the watch window) the UI will hang for a few seconds and the "Cannot evaluate expression..." error will appear for many of the other properties in the same class.
public int MyProperty
{
get
{
while (true) { }
return 0;
}
}
First make sure that you're running your code in DEBUG mode and with code optimization turned off. you can turn that off from the properties of your project.
If you made all of the above and the problem persists, then it's probably a problem with the stack having Debug.Break() on top of it. The solution for this is very easy, just press F10 to move to the next line and you should be able to evaluate the expression.
You can check this SO question for more information about this issue.
I was experiencing the same error message in the Visual Studio debugger when evaluating a linq expression.
Disabling the VS debugger config setting 'Enable Just My Code' resolved the issue for me:
To enable or disable Just My Code, choose the Tools > Options menu in
Visual Studio. In the Debugging > General node, choose or clear Enable
Just My Code.
https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code
I was having same issue in Visual Studio 2017. Going to Debug> Options> Debugging> General and checking "Suppress JIT optimization on module load(Managed only)" fixed my issue
I use breakpoints in debugging my C#/.Net programs. Very often I use many "When hit" breakpoints to display messages in the Output window and keep going, so I can examine what the program is doing while it's executing.
But I often find that after editing code my breakpoints get moved, producing spurious or incorrect results and I have to go and delete my old breakpoints and make new ones.
Searching for this on Stack Overflow I find other programmers having this problem when building in Release mode, but I'm building with a Debug configuration.
How do I make my breakpoints stay put?
Do you "share" files such as .csproj.user, .suo... with other developers of the project ?
If you are using a SCM exclude them from it, these files are not intended to be shared between different machines. To send them to another user with slightly different sources may cause this kind of funny mess.
More details about these files here :
Best practices for Subversion and Visual Studio projects
This kind of thing could also happen if you manually edit files, outside of VS (with Notepad++ for example) : try to avoid this when you want to keep breakpoints at the right place, VS doesn't like it at all.
There are many ways to examine the execution of program. Make sure you are generating full Debug Info for your project. Also check that csproj.user, .suo files aren't set as Read Only.
If these thing doesn't work, for your case I suggest you to use some console based output providing methods.
Try this one
Console.WriteLine("Currently executing this...");
The console here is the output window of VS. Select Debug from 'Show output from:'.
If you want to halt the execution, use this code
Console.WriteLine("Currently executing this...");
System.Diagnostics.Debugger.Break();
You should do conditional compilation of your code so that this doesn't get released with the final product. Console.WriteLine() will not cause any problem but System.Diagnostics.Debugger.Break() will break application.
This is baffling me, I am unable to find this setting if it exists.
I am 90% sure that my code used to compile on save before.
I only started having this issue when using C#, .net worked fine.
But now I am only able to get rid of error lines etc, when choosing to enter debug mode.
For example when I have a method
public bool Method1(){
//No code added yet so I get a blue line saying return something
}
Even when I add what to return inside the method the line remains there on save. It only goes away when I build.
(This is just one example it seems to happen with lots of other things)
EDIT - In regards to options to compile on save.
The options in Build and Run are set Correctly
That should produce a red underline and an entry in the Error List window: "not all code paths return a value". It is produced by the IntelliSense parser, not the compiler. Saving the file does not remove the error hint, only opening another project does. And fixing the code of course.
There is a bug of sorts in this logic, in some cases the Error List doesn't get purged. The only workaround I've seen is to restart Visual Studio. I've only seen this with certain IntelliSense warnings and it only affects the Error List, not the editor. I can't remember the exact type of warning that triggers this, it only ever happened when opening a project with code I didn't write. These messages don't normally last long when I'm editing code. Which is by far the best solution.
Should it not be the other way around? Save on compile.
Anyway, you can simple change the ctrl+s key combination to build and save in the settings menu.
Trying to debug a controllers action method, and when I attach to process the debug icon goes hollow and says the 'current breakpoint will not be hit'
But I am doing a response.write at that point and when the page renders it does output the test text.
So that section is indeed being executed, why does debug mode not work?
Your source code may be different than the version of the corresponding process that you are attaching to. Your other process may also be built in release mode, i.e., there is no debug info.
There are a few reasons why you may see this message:
You are attached to the wrong process
You are attached to the right process but the AppDomain hasn't loaded the assembly yet
You are attached to the right process but you have forgotten to build so the source code and the PDB file are out of sync
I've noticed this happen when using reflection and dynamically loading .dll projects. If the code isn't specifically reference (i.e. you are using interface animal but dynamically loading implementations of animal such as cat/dog) it will say it won't hit the breakpoint, but actually does.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
Another reason is when you attach to the process to quickly.
For example, when I attach to Excel to debug a VSTO add-in (I am using Add-In Express), if I Build, then Start > Run > Excel, then quickly press Ctrl+Alt+P to attach to process, then press E to highlight Excel and press Enter I see this, before Excel has loaded:
The result is no Breakpoints will be hit.
However, if I give Excel a couple of seconds to load and then press Ctrl+Alt+P, notice the Title is showing:
The result is Breakpoints will be hit.
It also tells me your source code is different from the version but it is not true. I build the whole solution, then attach to process, but still it says the breakpoints won't be hit because the source code is different. Maybe it is a bug?