I have just got a new work PC and am moving a solution from VS15 to 17.
When I edit existing source files, I get a bunch of errors relating to option strict, which include:
Option Strict On requires all variable declarations to have an 'As' clause
Option Strict On disallows implicit conversions from 'Object' to 'Integer'
Option Strict prohibits operands of type Object for operator '-'
Option Strict On disallows late binding
In addition to this, I am getting errors about System classes not being found, for example Attribute, NotImplementedException, etc.
Option Strict is turned off for all solutions in the project.
The errors relating to Object to Integer are caused by i variables within loops, where the for line also has an error about late binding being disallowed.
I have tried deleting the vs folder within the solution but it made no difference.
The project compiles without issue. How can I fix the Intellisense errors?
I think that there is a problem with the .suo files (or sqlite3 files) and VB.NET in Visual Studio 15.5.
Deleting .suo file manually or even the full .vs project subfolder doesn't solve it.
You need to open the solution, go to My Project -> Properties -> References.
You'll see that the Imported Namespaces in the bottom are all unchecked.
Scroll to System and enable it (mouse double click or space).
You'll probably receive an exception "Index was outside the bounds of array". Just ignore it but the intellisense problem should be solved now.
You have to do it for every VB.NET project is loaded with the solution.
It is the only workaround I found. I hope that they will fix it in the next release.
Another workaround: Disable Parallel Project Initialization
I found another workaround in the Visual Studio Feedback page (https://developercommunity.visualstudio.com/content/problem/160241/errors-reported-when-none-exist.html). Credits to Peter van den Berge.
Uncheck option "Allow parallel project initialization" (Tools > Options > Projects and Solutions > General). Reopen the solution.
Probably it is the VS 2017 bug (v. 15.5.0) described here.
Occurred today with me after I updated VS from 15.4 to 15.5.
The workaround has already been posted in Drake's answer.
Uncheck option Allow parallel project initialization (Tools > Options > Projects and Solutions > General). Reopen the solution.
EDIT
This has been fixed with the latest update (v. 15.5.1).
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).
After updating from VS 2015 Update 1 RC to VS 2015 Update 1, I keep getting the following error message:
Analyzer
'Microsoft.CodeAnalysis.VisualBasic.CodeFixes.SimplifyTypeNames.VisualBasicSimplifyTypeNamesDiagnosticAnalyzer'
threw an exception of type 'System.ArgumentNullException' with message
'Value cannot be null. Parameter name: source'
on one of my projects. Code Analysis is disabled on that project (as it is on all of my projects in the solution), so I tried to turn it on and off but still the same issue.
It seems that I can still build and run my solution, but things don't really seem to work properly after the upgrade:
everything is running really slow
after making changes and building it doesn't apply the changes
Did anyone else have this issue after the recent update or maybe even before?
Potential work-around found in here: https://github.com/dotnet/roslyn/issues/6682 posted by user dpoeschl.
And this is his original text:
Workaround: Check this checkbox: Tools | Options | Text Editor | Basic
| Code Style | Qualify member access with 'Me'
This workaround has two side-effects (that I can think of so far):
1. You will no longer get a visual indicator of the superfluous Me. or the associated code-fix, or the "Fix all occurrences in" options for
easily achieving compliance.
2. Any code generation features that generate fully qualified member accesses and depend on the Simplifier to remove them if appropriate
(or that explicitly check this option) will now generate non-compliant
code by default.
Enabling this option is particularly non-invasive in both VS2015 &
VS2015 Update 1 because this option is only enforced in one direction.
That is, the checkbox being unchecked means the analyzer runs, does
some deeper analysis (that fails in this case), and offers you a
lightbulb when you have qualified member accesses, while the checkbox
being checked means that we opt out of the deeper analysis very early
and you don't get any lightbulbs telling you to add Me. qualification.
It has worked for me, it might as well fix the problem for others.
This is a defect introduced in Update 1 and it is already tracked at Roslyn GitHub as #6682 since 2015-10-11.
Check there for status updates.
Update: Visual Studio 2015 Update 2 is now out and the problem is fixed there.
Update:
Apparently, the general issue is the code assistant is flagging calls to Shared class types when the class name is used.
For example
Private Shared Property Instance as Class1
Public Shared Function DefInstance1() as Class1
' This causes the warning
Return Class1.Instance
End Function
Public Shared Function DefInstance2() as Class1
' This is okay
Return Instance
End Function
For example, I assigned a value to the Synchronizing Object when inheriting from System.Timers.Timer as:
MyBase.SynchronizingObject = value
Instead of
SynchronizingObject = value
The VS Code Assistant detected this as a type name that can be simplified.
Note also, that a new warning is added each time VS starts.
Update:
It looks like another culprit is in the code generated by Visual Studio in the Application.Designer.vb:
this
Global.Microsoft.VisualBasic.ApplicationServices
is tagged for simplification to
ApplicationServices
It seems that Code Assistant has become a bit over-aggressive without QA noticing the issues at hand.
On March 30th, 2016, Microsoft released a new update for Visual Studio.
After installing Visual Studio Update 2 the issue seems to go away. This is the VS Update 2 and VS Update 2 Release Notes
Checking the Release Notes, this is the only thing they have touched with regards to the Analyzer:
We made Analyzer API improvements, including enabling Analyzer writers to mark their analyzers for concurrent execution, and providing control over whether analyzers run in generated code.
I have a fairly simple one solution project in VS2012. Standard windows forms, no special DLLs.
I get to a point were if I add more code to any form, or add a new control, the build fails in DEBUG mode. If I remove the line or the control, it works.
If I switch to RELEASE, the build succeeds.
If I create a new configuration and copy RELEASE, then that too fails.
If I revert to VS2008, all is fine. If I then re-convert the solution, it will be fine for a while.
Anybody else see that? I have researched the cases about missing DLLs and locked files, but that doesn't seem to apply. Neither does renaming the assembly work.
After many hours of looking at the options, a workaround is to turn on optimisations in "Advanced Compile Options".
I do not know what optimisations actually optimise, but they are turned off in debug by default because the debugger doesn't like them. Apparently, they will move code around.
This is obviously only a workaround and not the cause, so any other suggestions are welcome!
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 have a VB.Net solution that another developer created and I'm trying to compile it on our build machine (it compiles on their machine) but with one of the projects I get an error saying something along the lines of:
Imyinterface is ambiguous in the namespace anamespaceassembly.
I have tried with no success:
examined the references to see any obvious errors
removed and re-added the assembly in question
searched the system for the same dll
attempted to compile the original deve's src (.v the source control version)
examined the assembly with ildasm.exe
I usually code in C# and have not seen this error before (in this form at least), not that it is VB.Net specific but the UI for adding/viewing references is slightly different so I thought maybe VB.Net might do something different with references.
I also tried to compile on another machine, and it compiles ok. So I assume it is something with the build machine but I'm not sure what. Other conflicting assemblies somehow not referenced by the project, is that possible??
Any ideas?
Check your references if you have two versions of the same reference (eg. Microsoft.ReportViewer.Webforms version 10.0.0.0 and Microsoft.ReportViewer.Webforms 8.0.0.0) You will get this error. Delete the oldest and you should be good. I do this to myself all of the time.
There can be a few causes for this error. In VB, you should be aware that more names then you're used to from C# are available without class specification. Also, case does not matter in VB, which can further liken the chances on collisions.
Even in the event that you don't find the actual conflicting issue, you can resolve this in the same way you would in C#: rename it in the Imports statement:
Imports IM = yourAssembly.Imyinterface
Then change the code such that uses of Imyinterface are replace with IM.
NOTE: If the error does not point to a particular line, the conflict may be out of your hand. Normally, a full Clean Solution and Rebuild helps a lot, but occasionally a misbehaving file (i.e., another error) causes this error to popup first without clear source. Try to rollback recent changes to the place where it did work.
You also say it worked on another machine. Chances are that your machine is having a different version of MS Visual Studio or .NET. Check and compare the exact versions.
I was facing same issue. I upgraded my application from vb6 to vb.net and when i change the build configuration from DEBUG to RELEASE then i got AMBIGUOUS errors.
I found dulicate references folder in solution Explorer. I removed those duplicate referecnces and Build sucessfully. I Hope it may help others.
Thanks for the responses! I tried each but still was having issues.
One point of info I left out of the original question was that the VB.net projects are upgrades from VB6 projects. At the time I did not think that was relevant.
After investigating further the build machine was used to build the VB6 projects also. So I ran 'reg32 /u' on the vb6 dlls and that seemed to fix the VB.net issue.
Not exactly sure why this fixed it since I was not referencing the VB6 dlls, I'm guessing something to do with ambiguous entries in the registry confusing the vb.net project.