I have placed a breakpoint in my F# code to examine the contents of a particular list. The count at the top clearly says that the list contains 93 elements, something I have confirmed separately in SQL. But the debugger gets truncated after the 51st element, as can be seen from the snippet below:
Can someone please tell me why I cannot see the entire list? I don't remember encountering this error before. Do I need to set some configuration variable somewhere?
Thanks in advance for your help.
This is baked into the runtime, and was evidently a deliberate design decision at some point. See the relevant line in prim-types.fs
Not sure why this limit was imposed. You can file a bug on the Codeplex page if you want to see this changed.
Related
I have an error which is occurring only very late in my code (after it's been running for ~20 minutes) and so trying to pinpoint exactly where it is is tricky because I have a lot of recursive function calls and if I go too far the important variable values may have been changed. Is there a way I can set a kind of save point where all the variables have their values saved and which I can jump back to after I've done some exploring rather than having the run the whole thing again from the beginning?
I found this and just wanted to point out that Roger Lipscombe's comment is what I was also looking for:
Precisely: IntelliTrace https://learn.microsoft.com/en-us/visualstudio/debugger/intellitrace?view=vs-2022
and
Historical Debugging (which is part of IntelliTrace) https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/debugger/historical-debugging?view=vs-2015&redirectedfrom=MSDN
Only available on the enterprise version of Visual Studio
I have a workaround for this kind of issue: Using the Data Breakpoint, at least, it could output and save the value manually, and it also can help you check that what value was applied to your code line, I just get this idea from this case I met before:
Visual Studio. Debug. How to save to a file all the values a variable has had during the duration of a run?
If IntelliTrace tool is helpful for you like Roger Lipscombe's suggestion, one idea is that you could use IntelliTrace Standalone Collector tool without the VS in one machine:
https://msdn.microsoft.com/en-us/library/hh398365.aspx
This is not a duplicate question, my question is not answered in other threads. Please read before marking duplicate.
If I mark a breakpoint int Visual Studio 2013, and I leave that in there for several sessions of coding, I find that the breakpoint is duplicated. Sometimes hundreds of times. These are duplicates because they are for the same line of code. I usually click to the left of the line numbers to create my breakpoints.
My question is how do I prevent that from happening? I know how to delete them, I'm just wondering how to prevent them, which I have not seen an answer to.
The only reason I know of (that's not a serious bug) that would cause a line breakpoint in C# to have children is if your application is creating multiple (many by the looks of it) AppDomain's. As an Application Domain is created, not only is that executable code duplicated, but all of the breakpoints in that code are as well.
So, to prevent the excessive procreation of breakpoints, either stop creating AppDomains or do not set breakpoints in code executing in multiple AppDomains. There is no setting in Visual Studio to prevent this intended behavior.
I am using TFS 2012 express. When i try to use get latest version I get so many conflicts(more than 250). When I compare it i found that almost most of the conflicts are due to Case differences. Some times i do i get valid conflicts and which can be manipulated using merge tool. But comparing this lot number of conflicts(more than 250) is very difficult to me. For example in below image you can see changes like MsfgTemp and MSFgtemp(this kind of case differences) . I do get lot of this kind of differences(one more i got is Val and val) . No one has made any changes to those lines actually. But still conflicts are shown. Why this kind of conflicts I get during get latest version? How to solve this?
EDIT:
I have found some thing interesting after some research on it. I did several steps to find reason for it. When i was doing it no other user in my team was using TFS or changing anything.
The server has MsfgTemp(in so many lines of code).
I created new workspace and without changing anything compared with server version. As expected no difference found .
Now I changed some lines of code and saved the project.
Now when I see difference I found lot of differences. All changes are like MsfgTemp and MSFgtemp. Another was val and Val .
So it is sure that the reason is not some one changed or anything else. While saving project something causes these changes. My project is of VB6. I edit projects using Microsoft Visual basic 6.0 only.
So now what may be the reason for this kind of difference and how it can be solved?
You should check the TFS file history or use the annotate option to see who changed those lines and when they were changed.
Since TFS only stores the files it doesn't change the contents you should first find out who checked in the changes and that will lead you to the how and why it changed.
NOTE: from looking at the little bit of code you posted in the example the same variable name is used two lines above in both files without conflict.
TempVar = MSFgtemp.TextMatrix(i, TaxDeductedCol)
the conflict your are noticing just two lines later is for a very similarly named variable but I believe this one is different since it is declared inside the loop, so this might be a bug fix with a poorly named temp variable inside the loop...
TempVar = MsfgTemp.TextMatrix(i, ArrAddColNum(k))
I found a similar question here, but of no help.
I have a solution with nearly 10 projects in it. I am able to edit the code while debugging the solution, but for 1 particular project (say "Defect.csproj"), I am not able to. I am receiving the error as
I have compared the properties of this "Defect.csproj" project ith other project properties and everything is found to be same. In Debug and Build tab in properties, Configuration is Debug. Optimize code is off. Can anyone suggest me whats the problem with my solution?
Are you using any special references on this project?
Using office references or delta lambda expressions can silently break the edit and continue functionality.
Also using some third party component winform items can really play havoc with edit and continue.
Also keep in mind that using linq breaks edit and continue fairly often and editing inside a try catch block on the active function is bad.
I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally