I have recently switched from a c# team to a vb.net team. One of the things I have not been able to find an answer to is the differences in compile error / options. Let me explain.
In C# i will, using default settings, get a compile time error when trying to pass in an invalid type to a templated class like below. Here I create an Animal with a string type and afterwards I pass in a datetime which results in an compile error.
IAnimal<string> animal = new Animal<string>();
animal.SetTrainer(DateTime.Now);
I know I will get the same compile time error in vb.net with "Option Strict". There is, however, a lot of legacy (VB) code in the same file that will not compile with "Option Strict". What options do I have. Im thinking this:
Switch to "Option Strict" and fix all errors. Will take some time and may break working code.
Maybe there is an alternate that will ensure compile time check of generics. After all generics are rather new so maybe there is a way of always enforcing this.
?
Thanks in advance
Double click your Project -> My Project.
Goto Compile and look for Warningconfiguration
Now you can change some settings.
Implicit cast
Late Binding
don't make them errors but warnings.
That won't make compile time errors but you can at least see some warnings.
Another solution would be to make your class a partial class and move your code to a new file. You can set Option Strict / Option Explicit on a per file basis.
Switch to "Option Strict" and fix all errors. Will take some time and may break working code.
Yes, do that. It will help you remain sanity.
Most errors that will pop up are probably simple casting issues, which are easy to fix (a CInt here, a ToString() there...).
You don't have to fix your whole solution or project at once, since you can enable Option Strict On at file level. Make it a good habbit to fix every file as you have to touch it.
This will not always be possibly, but you can also just move code that heavily relies on Option Strict On (e.g. COM stuff) to another file without breaking changes.
Related
Hello all (excuse me please if I am in the wrong forum)
I have just bought MS Office Professional 2019 and am using Access 2019.
Previous versions of Access came with "intellisense" (is this what it is called?) which would highlight errors in my VBA code in a module "on the fly". That is, if I wrote a line of code that had syntax errors, the errors in the line would be highlighted. This does not seem to be switched on (or available at all) in the new Access 2019.
I have spent days looking for an answer to this, so you are my last hope. Am I missing a reference file or something?
Thanks in advance for any help you can offer.
Require Variable Declaration checked causes Option Explicit line to automatically generate in header of newly created VBA module. It does not itself cause compiler to look for undeclared variables - Option Explicit does that. For existing modules without this line, it will have to be manually added. Why MS did not make this option checked by default is a mystery.
Auto List Members unchecked disables intellisense. When checked, intellisense should work if appropriate libraries are active. Early binding must be used for declaring and setting object variables. Intellisense is not really a syntax checker, it is an aid to constructing code but does not prevent incorrect construction.
Auto Syntax Check has nothing to do with provoking intellisense. Even when unchecked, syntax errors are red highlighted, such as not using line continuation character where needed. What doesn't happen is a popup notification of error.
Thanks you everyone for your replies. The option settings suggested seem to be working now (intellisense will only look for syntax errors in known procedures or methods - if you type general rubbish there is no syntax to correct. It only does so much for you!). As to the debugger failing to break on an error, I seemed to have had the "USE ACCESS SPECIAL KEYS" checkbox (OPTIONS > CURRENT DATABASE >) unchecked, and this stopped the debugger from breaking on an error (amongst other VBA tools also denied).
I've got a code formatting extension, with format on save enabled. Unfortunately, it annoyingly gives me a warning every time I save but my program fails to parse. This information is redundant, since there are other packages which inform me of the error in a much less intrusive way.
Is there any way to block all notifications/warnings from a particular package?
This is not possible as of VS Code 1.18.
Please file an issue against the responsible extension so that they can fix this
I need the activation of "option explicit off".
I have an old Excel/VBA project in which variables are not declared before use. I know this is not a good practice but the project is old and useful.
I disable the check of undeclared variable in configuration of VBE.
In the new computer the problem persist and on the old one I never get this problem.
Both computer use office 2010.
Is there a other way to force compilation whith goal "option explicit off" ?
You can allow for the implicit declaration of variables by disabling Option Explicit; that is, by changing Option Explicit in your code to Option Explicit Off.
This will allow you to compile without having dimensioned all of your variables.
If this does not solve your problem, we will need more information on the exact line of code your project is failing on. All the best, Dan.
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).
Do you use 'strict off' option, 'explicit off'? Or may be 'strict custom' and some other options like 'Implicit type. Object assumed', 'Late binding', 'Implicit conversion'?
Never. OPTIONS STRICT OFF is the same as OPTIONS BADPROGRAMMING ON.
OPTIONS STRICT OFF relaxes some of the checks that VB.NET makes. It relaxes language rules. Those rules are there to save you from yourself. Don't ever prevent the language from saving you from yourself. This is especially true if you're coming from a more releaxed environment, in which case chances are that you need saving.
Another thing to note is that most programming languages don't have a switch to say: please allow me to shoot myself in the foot.
Always develop in any language with full warnings and restrictions on. No exceptions, ever.
To do otherwise is a false economy, sure it may seem to work, but sure as hell it'll come back to bite you later
(currently debugging a series of PHP web applications where the original 'coder' had suppressed all errors and which, literally, display several hundred errors per page when enabled. "Make sure variables are defined before using them in tests? Why would I do that when i can just suppress the error and not have to think?" )
Generally I leave Option Strict On at the project level because in general I want strict semantic checking. In the cases where I do want to use late binding I will turn Option Strict Off at the file level.
I like to use Strict=On, so my code fails at compile time rather than when it's gone live, and Explicit=On because in a static language it would be kind of weird not to declare your variables.
I always turn Strict ON when I start a new project or when I receive an active project
I will never provide support on a project with that OFF, ever
I have done it both ways. Always have it on. I did not have it on when was doing some quick and dirty vbscripts and it cost me debugging time. Turn it on, keep it on
Option Strict Off and Option Explicit Off are False Economies in production code.
You will spend more time chasing strange bugs than it takes to write your code error and warning free in the first place. My experience has taught me this.
The only exceptions is when I need to use late binding in which case I have to switch it off.
I usually have Strict OFF if I'm doing some quick-and-dirty prototype or spike where I know I won't have to maintain the code in future.
The word "know" is key here though, if there's any chance the code will migrate into something you need to support then set Strict ON and deal with any errors before they come back to bite you.