visual studio 2017 slow at renaming textbox - vb.net

I have a medium size project coded in vb.net using latest version of 2017 visual studio.
The problem that I am having right now is that when I edit a textbox say txtCarType to txtCarType2 it takes about 15 seconds to process.
I am also having the same issue with labels or renaming any control. how can I fix this issue this lagging its killing productivity.

Visual Studio is trying to be generous and refactor the new name throughout your project. This indeed helps as if it does not refactor you could be left with some errors. When you rename controls a refactor window pops up as it churns through files to refactor the name through-out the whole project. This indeed can be dreadful, irritating and possibly a long process depending on your solution/projects.
Please give this a shot...
Tools --> Options --> Windows Forms Designer (expand node)
General --> Refactoring (set "Enable Refactoring on Rename" to False)
Hope this helps!

Off the top of my head it could be one of 2 things.
It's just running a bit slower because of the size of your application. Trying to sort through all that data takes time, so it's just gonna take a few seconds to find what it needs and change it.
Refactoring for all references to the object in your code to prevent errors.

Related

retrieve last successful build in visual studio vb.net

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.

Visual Studio getting 'InvalidProgramException' when making changes while debugging

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.

How to prevent Visual Studio from displaying double values with 18 decimal places

Recently I noticed in my current vb.net project that sometimes (depending on the value), if I enter a double value the editor changes my input, for example:
When I type ...
Dim x As Double = 0.6
...after commiting the line by pressing Enter it becomes:
Dim x As Double = 0.59999999999999998
If I directly undo the action, then it gets reverted back to the original value I typed in. Any future edit in that line will again produce the undesired results.
I'm aware that internally 0.6 is calculated as 0.59999999999999998 so it doesn't make a difference for the running application, but it's very annoying and the strange thing is: this hasn't always happened and, if I create a new project, it doesn't happen there either.
So my questions are: How can I prevent VS from doing this? Why does it happen at all? Why isn't it always like this (previously in my current project or in a new one)?
I'm running 64bit-Windows 8.1 on an Intel CPU - if that has anything to do with it.
Has anyone got any ideas?
EDIT: I'm using Visual Studio 2013 Professional (12.0.31101.00 Update 4) and, yes, the project has been migrated from several earlier VS versions. There are no relevant Add-Ins or extensions installed. Disabling "Pretty Listing" does indeed prevent the problem, but of course then the other highly useful aspects of the option are disabled as well :o(
EDIT2: After the tip leading to "Pretty Listing" I found the following SO article, but there also no solution was found: Visual Studio VB pretty listing settings
Several years ago I had a project where this was happening. As you wrote, the reason for the number is that some numbers can't be represented exactly in a binary floating point variable. More on this here.
My project had been upgraded through several versions of Visual Studio. It was also shared with developers using VS Express.
If I ran into this problem again today I would open and check the project-file manually, or just simply create a new project and re-add the files if I could not quickly locate the problem and the project was small enough.
If you have upgraded the project through multiple versions of Visual Studio like I had, it might be dragging some settings along that are no longer visible in the projects options dialog.
Just as an interesting experiment you could also try to turn off Visual Studio's Pretty Listings to see if that is what is actually changing your code.

Only Shows Error List For One vb File

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.

INotifyPropertyChanged.PropertyChanged implemented and not implemented; Visual Studio build error

I'm seeing a strange build bug a lot. Sometimes after typing some code we receive the following build error.
Class 'clsX' must implement 'Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs)' for interface System.ComponentModel.INotifyPropertyChanged'.
And
'PropertyChanged' cannot implement 'PropertyChanged' because there is no matching event on interface 'System.ComponentModel.INotifyPropertyChanged'.
Those error should never go together! Usually we can just ignore the exception and build the solution but often enough this bug stops our build. (this happens a lot using Edit and Continue which is annoying)
We're using Vb.net and c# mixed in one big solution.
Removing the PropertyChanged event and retyping the same code! sometimes fixes this.
Question:
Has anyone else seen this problem and has some suggestions how to prevent his?
We're using a code generator that causes this error to surface but just editing some files manually triggers this exception too. This error occur's on multiple machines using various setups.
Someone had the same exact issue discussed here. It sounds like there is an issue with this build picking up an old version of a binary. I would try the following in order:
Verify all assembly references use project references where possible within the Visual Studio solution.
Disable build parallelization in case there is some weird file locking issue with concurrent project builds. Go to Tools -> Options, Projects and Solutions -> Build and Run, then set "maximum number of parrellel project builds" to 1. Not the best solution but it may help narrow down the problem.
Disable the Hosting Process in case it's locking some file causing an assembly to not get rebuilt correctly. For C# project go to Project Properties, Debug tab, and uncheck "Enable the Visual Studio hosting process". For VB.NET project you'll need to Unload Project, Edit the project file, and add <UseVSHostingProcess>false</UseVSHostingProcess> to the PropertyGroup of each configuration. Again, not the best solution but you probably won't notice a difference.
Lastly, try doing a Clean + Build to try and resolve the issue when it occurs (I know this is not a fix but it's easy enough to do), also Rebuild may be slightly different than Clean + Build so try the latter if the former doesn't work.
As I can not comment due to lack of appropriate points.
But I would like to share one of my experience:
In an aspx.cs page I was working, used to compile fine and some time gave mysterious error of a variable not defined or function not defined or sometime variable or the function defined two times. I changed possibly each and every variable and function name but there seemed no effect , but after entering a simple space or a new line at any place in the file used to solve the compile error. At one time I tried to save the file (in a different encoding as i am used to experiments) and found that the file was not saving in the correct encoding (i.e. the ansi encoding because the file had a unicode character ), I removed the unicode character and that compile error didn't bothered me again.
This unicode character problem could be (not a hard and fast rule) there so you could check it.
Nuke & restore using source control (TFS instructions here):
Make sure you have everything checked in
Exit Visual Studio
Rename the project directory to .Bak (effectively deleting it)
Reopen Visual Studio and in source control:
Get Specific Version
check 'Overwrite... not checked out' and 'Overwrite ... even if local version matches'
Re-open project
Another problem: Make sure some source files are not newer than the current date (or your date is set back). Often this happens in apps where you are doing logic that requires certain things to happen differently on certain dates. You change your clock to test it, make a revision to the source with the date advanced, set the date back, and viola, rebuild does not rebuild that file.
You say 'typing it in again' - can you try just saving? After 40 years since MULTIX the .net build still decides what has changed by checking the file timestamp.
good luck!
When you get the error, is it always on the VB calling C# side, or vice-versa, or does it work both ways?
If the answer is either of the first two situations, try building the "callee" project within the solution before building the "caller" project to see if it stops the situation.
Also, just in case it may jog something for you to think about, does this error crop up when you change a VB file or a C# file, or is there no correllation?
Oh, and sorry this looks like an answer instead of a comment, I cannot post comments yet (need 50 rep).