Enabling "Pretty listing" in Visual Studio 2010 for VB.NET, causes autoinserting of ByVal in front of all the parameters which have it implicitly.
This is an issue since, working on a big project, when we need to review the code, all this non-changes are highlited in the comparison with the version control base.
Is there any way to have "Pretty listing" to continue formatting the code, but not to touch the rest of the code or not to force explicit ByVal?
(We also use ReSharper, in case this might have some functionality to resolve this issue)
Cannot update to SP1 as it's not been approved on the internal software centre.
I believe the answer is you can't avoid the insertion of ByVal without either turning off Pretty Listing, or upgrading to a more recent version of Visual Studio.
As a workaround, perhaps you can create a version of the unmodified code that has had Pretty Listing applied to it (e.g. cut and paste the entire code) and compare the modified code to that.
Related
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.
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.
A very strange, presumably meant to be helpfull behaviour of Visual Studio 2012.
When I enter a double in vb.net like:
Dim myD as Double = 1.4
When I hit enter of move my focus another way, the formatting kicks in and changes the above to:
Dim myD as Double = 1.39999999999999998
or 1.6 as
Dim myD as Double = 1.6000000000000001
This behaviour does not appear to happen for all doubles. 1.3, 1.5, 1.7 and 1.8
See this youtube movie for the behaviour in action:
http://youtu.be/afw4jg58-aU
Why, and more important, how can I prevent this?
Edit:
Extensions installed are:
Second Edit
The behaviour seems to have gone away. I do not know what has caused this so for future reference this is useless to anyone, but for now, I'm happy that I don't have to go troubleshooting as suggested.
The exact same issue is also reported in this question. Which applied to VS2010, otherwise without a usable answer.
This is an environmental problem, code is getting loaded into Visual Studio that messes with the FPU control word on your machine. It is a processor register that determines how floating point operations work, it looks like this:
The Rounding Control bits are a good source of trouble like this, they determine how the internal 80-bits precision floating point value is truncated to 64-bits. Options are round-up, round-down and round-to-nearest. The Precision Control bits are also a good candidate, options are full 64-bit precision, 53 and 24 bits.
Both VS2012 and the .NET Framework rely on the operating system default, with the expectation that this will not change afterwards. Pretty hard to diagnose trouble arises when code actually does change it, your observation strongly fits the pattern. The most common troublemakers are:
code that uses DirectX without the D3DCREATE_FPU_PRESERVE option. DirectX reprograms the precision and rounding control bits to squeeze out a bit more perf.
code that was written in an older Borland language product. Its runtime library initializes the FPU control word in a non-standard way. Otherwise a generic problem with software that relies on old runtime library or an old legacy initialization that was carried through in later releases.
in general, any code that uses a media codec or media api. Such code tends to reprogram the FPU to squeeze out perf for the same reasons that DirectX does. Especially notorious in a product I worked on which uses such codecs heavily. The codebase was peppered with calls that reset the FPU control word after making a call into external code.
Finding and eliminating such code can be very difficult. DLLs get injected into another process by a large variety of well-intended malware. The SysInternals' Autoruns utility can be very useful, it shows all the possible ways code can be injected with an easy way to disable it. Be prepared to be shocked at what you see and readily disable stuff that doesn't carry a Microsoft copyright.
For dynamic injection, you'll need a debugger to see what is loaded into VS. Start VS again and use Tools + Attach to Process to attach to the first one, selecting the unmanaged debugger. Debug + Windows + Modules shows you what DLLs are loaded. Do beware that the DLL can be transient, a shell dialog like File + Open + File will dynamically load shell extensions into VS and unload them again afterwards. Good luck with it, you'll need it and sometimes the only fix is a rather drastic one.
I had the exact same issue with Visual Studio 2012.
The "solution" if it happens to you is:
write your number in your code
let VS screw it up, e.g. when you move to another line
CTRL-Z to revert VS mess
continue writing your code
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).
I don't need this declaration because it only makes my code big and unreadable.
Is there a way to make Visual Studio (VS) not add it automatically. Every time I remove it, it is added back by VS.
Function DoStuff(Tom As String)
NOT
Function DoStuff(ByVal Tom As String)
It actually makes your code more clear to the non-believers. I don't think they hurt readability of the code, rather the opposite.
Install Visual Studio 2010 Service pack 1. It doesn't insert the ByVal declaration.
Turn off pretty formatting at Tools/Options/Text Editor/Basic/VB Specific/Pretty Listing (reformatting) of code.