I develop in VB.Net using Visual Studio Community Edition. From version 2015 on I noticed a strange behavior when debugging: if I halt execution with an interruption point and then make some changes in code, no matter how harmless (like editing a string, for instance ) VS will accept my changes but then it will halt again and that's because the variables that contained valid objects are now empty, that is, have the value of Nothing. Is that a known bug or is there something I can do to avoid or circumvent it? Thank you very much!
Editing code while the program is running is generally not a good practice. This is because when you hit the "run" button in Visual Studio, the code is compiled in to assembly language that the computer can read and execute.
If you pause at a breakpoint and edit code, Visual Studio is not able to re-compile while in the middle of executing your program, and this is likely why your variable has "Nothing" in it.
One way to debug certain sections of code is to put the code you want to test into its own subroutine, and then have a button on your form (if using winforms) execute the subroutine.
Each time you edit your code, however, it is best to stop the program and hit run when you done making your edits so that VS will make a fresh build (compile) of your program.
Related
in visual studio 2013 vb.net coding, when you click 'Start' and it gives you a popup message saying that it contains errors would you like to run the last successful build?
How can I really get back the code of the last successful build because I have done several changes and I really want the old runnable build back.
I really appreciate all the help I can get.
thanks in advance!
As Karen advised, if your code isnt under version control, and you dont have backups (or undo history), then the code is gone.
One option, if you are desperate to see the content of the assembly, may be to reflect it. This is the process of turning the assembly from IL back in to source. The code that is produced will not be a mirror image of the original, as it will have been optimized/shuffled by the compiler, but it is often enough. If you are interested check out dnSpy.
I've been using Visual Studio 2010 for years now. I have a fairly complex VB.net project that I routinely make changes to. Recently, whenever I'm making changes in debug mode, it throws a System.InvalidProgramException - Common Language Runtime detected an invalid program error which forces me to stop running the program and then restart it again after I've saved my changes.
This issue only happens when I make changes to a Sub or Function which is called by another Sub or Function. For example, if I make a change to a button click event, it's fine, but if I make a change to a function that button calls, it errors.
A change as simple as adding blank lines in my code will cause this to happen. No code change at all...just literally hitting return to add blank lines between code lines.
I installed Visual Studio 2013 thinking it would solve this. It does not. I still get the same errors.
I tried moving my project files to a different HDD, I still get the same errors.
I thought maybe I have corrupt memory, so I ran a full checkdisk and defrag but I still get the same errors.
I've read where this error may happen with very large procedures or projects with lots of variables (although I thought this was fixed in newer .NET versions) so I've cleaned up my code. The largest Module has 30k lines.
The workaround is to stop the project running, save my changes and then restart it...however, that takes time because my program has to reinitialize everything when it runs, so I'd prefer to be able to make changes while debugging.
Also, I have .NET framework 4.5 installed
Update: I loaded up a backup of my code from a month ago and it runs fine...so apparently some recent changes I've made are causing this error. Once I figure out what's changed, I'll update this just for future reference in case anyone else runs into the same issue.
I am in the beginning phase of a new VB.net Windows Forms project in VS 2013 that is connected to a TFS 2013 application tier. I have updated the VS client using Microsoft Update to include all hotfixes available for it at the current time.
There are 2 problems that I'm having:
Breakpoints are ignored (eventually)
F10 (Step Over) & F11 (Step Into) don't work properly (They work maybe once or twice, then totally step out of all running methods)
The problem morphs as time goes on, but here is essentially what happens (NOTE: I have a breakpoint already set in a method that is called on Form Load, so the expected behavior is that the breakpoint is hit before the interface is usable. Also, there are about a dozen lines after the breakpoint in the method)
F5 to start the project in debugging mode
The form loads and does not stop at the breakpoint
Make a change that calls the method
The application stops at the proper point
Hit F10 once, it goes to the next line
Hit F10 again, it completely steps out of all running methods, bringing me back to the interface (What I expect here is for it to go to the next line)
Repeat steps 3-6 consistently until it just continues and does not stop at the breakpoint again, nor does it allow me to Step-Through or Step-Into any methods
Some additional information:
I have another, larger in size VB.Net application that has never experienced issues with debugging
When I set up VS2013, I chose General Development, and the only change I made from the default settings was to change the color scheme to the dark scheme.
In my research, the only articles I have really found pertaining to 2013 that were even remotely relevant all pointed to this article: VS/2013 Debugger Not Working (MFC/C++/CLI w/ previous version of MFC library)
This article sounds like it has similar behavior, but it's pertaining to projects that contain both C# and C++ code, which mine does not.
Does anyone have any insight as to what could be causing this, and what I can do to work around it? I didn't have these issues with VS2012 and I think I will probably use that for this project until I can get the issue resolved.
Ok, I found the problem.
It stemmed from the fact that each of the lines I was trying to step over or into had an InvalidCastException (I was trying to add an Integer and 2 Strings together, and stick them in another string. When the strings were blank, it was trying to convert them to Double). These errors were NOT causing the application to break, it was silently ignoring them and putting them in the Output window (Which I wasn't paying attention to).
The irony is that I knew there were going to be errors on those lines, and I was trying to figure out what they were so I could do the conversions properly.
The breakpoints failed when I had one of the lines set to break that was generating the error, and the Step Over functions would completely skip past them.
Once I fixed the InvalidCastExceptions, debugging started working properly again.
Having a very odd issue with Visual Studio 2013, curious if anyone else is seeing anything similar. I have VS 2013 Ultimate, it seems like once a day, while I'm working with a file, the compiler just suddenly freaks out and doesn't detect my code anymore in my web forms. Take a look at the screenshot below (I just chose a random spot in the middle of the web form), but out of nowhere, VS starts erroring, telling me that variables aren't declared, that method arguments need parenthesis on lines of code that aren't methods, all sorts of whacky stuff.
I assure you, I don't have any broken references, I didn't forget to close an if statement.. nothing like that. All I'm doing it writing some code, and randomly the whole page just starts to error like this. To resolve, all I can do is copy the code contents, delete the page, recreate the page, and paste the contents back into my "new" file... same exact code, only no errors. I wouldn't even worry about doing this if I wasn't doing this at least once a day.
Any help is appreciated, thanks!
Edit: For what it's worth, I found a slightly easier workaround for this issue. If I edit the properties of the class file to "Do not Compile" and then back to "Compile", the IDE is able to read the file just fine...
It looks like this is simply a bug in the Vb.Net Compiler / IDE. I agree it's unlikely to be a bug in your code because you can see that the error squiggles don't line up with places that would represent the errors you are reporting. This is sometimes a sign of an IDE bug
In terms of fixing the problem though you can probably get them to go away by closing and reopening the solution in question. Baring that restarting Visual Studio. I wouldn't resort to deleted / recreating the page.
Long term though you may want to file an issue on connect so the IDE team can try and fix the problem.
http://connect.microsoft.com/VisualStudio
I'm kind of new to Visual Studio. I've built a few simple programs in it, but now I'm in the process of rewriting a huge system I wrote in VBA. What is frustrating me is the Error List in VS is only listing errors for one .vb File in my project, lets call that VBFile1. Now, when I work on another vb File, VBFile2, which is in the same project as VBFile1 no red squiggles or errors are listed for VBFile2. I don't understand how this could happen. This is what I've tried/checked:
Filter is set to 'Current Project' and I played around with the other Filter settings but no change.
Checked the Text Editor under Options and according to the research that I've already done it is fine. Plus, I have never changed any of these settings anyway.
Closed and re-opened Visual Studio.
Closed all open files in the Project and still displays the same error list
Close all files except the VBFile2 but still shows the same error list of VBFile1.
I have Visual Studio 2012 Ultimate. I feel like this should be an easy fix...I just am really confused what's going on.
Hope this makes sense!
UPDATE: Excluded from project, VBFile1 and finally errors are listed for VBFile2...why would this be?
I am not sure if it has been fixed in Visual Studio 2012, but there is a Connect Request for Visual Studio 2010 with a resolution of won't fix because of performance issues. The effect your are seeing is because you have exceeded the maximum number of errors for that project (what I am used to seeing is 102 as the threshold), it will not show you anymore till you fix the ones that it has already shown you.
According to this MSDN article, which I found through this SO question the limitation is still there for the IDE but has been removed for the command line compiler.
From above MSDN Link:
Limitless (Command-line) Errors!
This is actually a good thing, let me explain. For performance reasons, the Visual Basic IDE maxes out at 101 errors (with error #102 being “Maximum number of errors exceeded.”) This can make it difficult to estimate the amount of work remaining in certain situations, particularly in upgrade scenarios. We have removed this limit from the command-line compiler in this release, though it still there in the IDE. What this means is if you want to know exactly how many errors there are for a project, just invoke the compiler through msbuild.exe or vbc.exe and you’ll get your answer.