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.
Related
I am a total noob with Application Insights, and sadly for a whole day of trying I have been unable to get it working at all. I tried with the following code:
this.telemetryClient = new TelemetryClient(TelemetryConfiguration.CreateDefault());
this.telemetryClient.TrackTrace($"Test", Microsoft.ApplicationInsights.DataContracts.SeverityLevel.Warning);
But when I go to the application insights window and show all telemetry from the current debugging session there is nothing logged. One user said an ApplicationInsights.config file is missing (and that an empty one would do fine for debugging), I created one but it changed nothing.
Then I tried the simplest console app I could find - https://learn.microsoft.com/en-us/azure/azure-monitor/app/console . I don't have an instrumentation key, and from the hundreds of forums I read today, if you leave it blank it should still appear in the debugging telemetry. Alas, still nothing in Application Insights.
How can I get it working? I just want to see a single Trace message in the Visual Studio Application Insights window when queried for "debugging telemetry".
I used to work on this stuff and the way it generally works, the extension tries to figure out if it should watch for debug output, and if it doesn't recognize the project type, we do nothing (to avoid doign work in the debugger when we don't need to). in this case, console apps aren't a "known" supported project type.
IIRC, to get debug output I believe you need to do 2 things, of which you've done 1:
1) add an ApplicationInsights.config file at the root of that project
2) add an application insight resource id to to the csproj:
<ApplicationInsightsResourceId>/subscriptions/abc</ApplicationInsightsResourceId>
i don't think the resource id even needs to be valid, but if it does even better, because then other things can light up, like exceptions codelens, various links to the portal/etc.
you migth only need to do #2?
i think that if you do the above and restart vs/reload the solution, you should see the debugger integration try to do work when the debugger starts. (it used to!)
As far as I understand, System.Console will write to STDOUT by default, but what about System.Diagnostics.Trace and System.Diagnostics.Debug? What are the default behaviors, and are they configurable in any way?
It also seems that different people use different things (on the internet), but I'm assuming that most of what I've found is wrong, since there should be specific semantics for each of these, right? And if so, are there any frameworks (like ASP.NET or WPF) that make special use of these?
Also one last question, what are the rules of thumb for picking which one of these to use?
Debug and Trace both write out to the same location, the Listeners collection. By default it is routed to Visual Studio's Debug window, however you can put code in your app.config file to redirect it to other locations when you are not debugging.
The difference between Debug and Trace is all of the methods in Debug only write out when the DEBUG compilation symbol is set (default on for debug, off for release) when the symbol is not set the methods are never called in your code. Trace looks for the TRACE symbol (default on for both debug and release). Other that that, the two classes are identical. In fact if you modify Debug.Listeners to add a new listener it will also modify Trace.Listeners as both just point to the internal static property TraceInternal.Listeners
As for picking which one to use, Do you want diagnostic information to show up in release and debug mode? use Trace, Debug only? use Debug. Do you want it to be visible to a end user without a debugger attached? use Console or add a console trace listener.
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.
Currently I'm programming an application to record data. The data will be stored clustered to a file.
This data can be analyzed by the user or the program displaying the data. By analyzing large amount of data the program ends suddenly, i.e. there is no exception, any other error message or any process at the task manager just no more program.
By analyzing the program with perfmon I found lots of i/o (460 events/s and 15MB/s) at this moment as expected. Is there any limit reading data from different places of a file? (I'm seeking positions and read complete clusters.)
Make sure you're wrapping your code with a try..catch. Then set a break point in the catch. (#Paolo makes a good point, be sure the try..catch is in the thread that is doing the work.)
Also, you could try setting visual studio to break on all exceptions. "Debug" / "Exceptions" / Select relevant "Thrown" check boxes.
Also, try checking the Event Viewer for some hints.
Finally, you can also do Debug.WriteLine or Trace.WriteLine in certain places (esp if running on a system w/o visual studio) and monitor output with Sysinternals DebugView
Note: Be sure to make code production qual (i.e., add logging, program defensively, etc) after/while finding the source of the issue.
Use try..catch.
Subscribe to AppDomain.CurrentDomain.UnhandledExceptions.
Use NLog.
Watch the process' working set.
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?