I have a solution written in VB with some C# components. The solution uses some libraries from 2 outside sources. I have been working on this project for several months without issue. I cannot identify anything specific that I did to change my system or configuration. I was just working through the code, transitioning from an old set of library calls to the new library calls. The new library calls require complete rewrite so I change sections of the code and test to that point. Visual Studio 2013 debugger as of Friday morning will no longer recognize or show my local variables in this solution. The only things that appear in the Locals window are under Me. The code does work and I have it writing out to a text log file to confirm the values of variables at certain points, but the debugger has gone blind. When I add any of these local variables to Watch the response is " is not declared. It may be inaccessible due to its protection level."
Steps I've taken so far with no permanent success:
looked online and tried the few matches I found with no success
deleted the bin and obj folders and had the solution rebuild with no
success
recreated solution from scratch, copied over base files and rebuilt
solution and project (which worked for a few hours), until I did a
rebuild project and problem appeared again
updated to pack 5 and no success
I have opened my older projects and checked them. The debugger runs just fine and shows the variables. It is obviously something that happens during the rebuild process.
Any assistance would be greatly appreciated.
Thanks
Update:
Let me try to explain a little more clearly the situation.
I have an application I have built and am selling to some customers. Version 1 is installed and running at several locations. It is written in VB and uses some older COM libraries for a particular integration process.
The vendor is retiring the COM libraries. Their new libraries are in C#.
I created a new copy of my entire application (solution) and imported the new C# libraries. I have been going through and replacing the old code with the code for the new calls.I recompiled the solution and everything ran fine in debug.
The objects used with the new calls are completely different and there is limited documentation so I update a section of code and test to that point. Each time I "Save all Files", rebuild the project and test the changes. Everything worked fine for a few days. On Friday morning I started working on more changes and got an odd error. The system was not getting a proper value for a certain variable. When I went to check it in the WATCH window, debugger said it could not evaluate it. I figured something was hung up so I shut everything down and rebooted my machine. When I tried it again later, the same problem.
After several hours of no success I exited VS, renamed the folder to "OLD" and recreated the solution from the older version. Immediately everything was looking fine. I started making the changes and testing. Each time I did a rebuild, everything looked fine until the last change. Here I am again.
The code works fine up to the point I have updated. The only issue is that the debugger windows are not working correctly. If a variable is declared at the Class level outside the Sub, they can be seen. The only variables the debugger is blind to are the local variables within the running Sub.
I looked for anyone else with this issue and only found a few items. I tried the suggestions but no joy. I am left with having to temporarily define the variables outside the sub so I can see them while debugging.
I am on VS 2013 Update 5.
Do I need to move to VS 2015 to get around this?
Thanks again for your time and assistance.
I am assuming that you haven't changed versions of visual studio since the last time a rebuild worked for you.
recreated solution from scratch, copied over base files and rebuilt solution and project (which worked for a few hours), until I did a rebuild project and problem appeared again
Based on this, you create it from scratch and everything works until you do the rebuild right? But you are copying the base files still and you have new library calls since the last time a rebuild didn't mess up the locals window. So one of those is almost assuredly the culprit.
Since the library calls seem to be the thing that changed based on your post start there. If you go back to the old code and do a rebuild does it fix it? Assuming so, put the library calls back one at a time until it breaks.
If going back to the old code doesn't fix it, create from scratch with the old code and copy over the base files and rebuild. If that fixes it, add new library calls one at a time and rebuild after each until it breaks.
If that doesn't fix it either, then you will need to dig deeper on what else might have changed.
You are copying base files so eliminate those as the problem if you can:
Are you able to use placeholders instead of the base files or something that won't necessarily work as a finished product but that will allow you to debug, rebuild, debug again to see if the problem is related to one of them? Check the dates on the base files and ensure that they haven't changed since the last time a rebuild worked.
Something you could do concurrently could be to have have a colleague do a rebuild on their machine and see if the same issue comes up for them. It would (almost) completely eliminate the possibility that it is a configuration / program corruption issue on yours. Alternately, there are some free vb.net compilers online that you can upload files and code to. I'm not sure if that would be practical for you (due to the components of your program and/or sensitivity of the data) or not and haven't ever tried any where there is C# code in there but I wouldn't think that would be an issue.
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.
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.
I'm working on a big Access 2003 project with Microsoft Access 2007. Recently, some users have started to experience problems with the buttons in my forms. For example, without any specific reason, clicking on a button or trying to execute any code will return the error:
File not found
There is no way to go into debug mode. When this happens the only thing to do is to restart the database. I tried adding the Stop command at the beginning of the executed block to try debugging it, but no code is executed at all. It's like a compilation error but it's only happening 5-10% of the time, which is really weird.
After some research, I found other people are having the same problem, for example this and this link. There are other examples too, with no real solutions yet.
My database can be okay for a week and then the problem starts to happen again. Half the time and users can't do much; they need to restart the database once or twice to get it back working, and after a few minutes the error might happen again.
Because this is Access 2007 and there are a lot of people experiencing this bug, I can't believe it isn't more documented.
What's the problem? Is the database somehow partially corrupted? What should I do? This is really annoying.
If I was in this situation one of the first things I would try would be to do a complete decompile+compact+recompile operation on the front-end database file, and then distribute that updated front-end out to the users to see if that improves things.
Detailed instructions on the decompile+compact+recompile steps are available here. Note: Be sure to read David W. Fenton's additional recommendations in his answer.
I had just experienced this for the first time. I had been making extensive coding changes in a form, and was required to reboot my PC without finishing debugging the code. When I opened the app, I immediately got the "file not found" message (it auto-starts a different form).
On a whim, I went to the form in question and commented out that entire module's code and the problem went away. After I went back in and uncommented that code, everything still worked as normal. I was able to continue debugging that code and lived for the rest of the day happily.
though this thread is over a year old I would like to share another very helpful observation.
This error "File not found:" may be caused by differing save behavior of Office versions and may not have anything to do with your code! In case of this error, try to open and save your troubled file in another Office version and it may work fine back in your main Office version.
Details:
Though programming VBA for years now, I had never had an unsolicited "File not found:" error. Weird also that the error message does not give a file name for the file not found. (Reminded me of another nasty error VBA sometimes shows on startup for no obious reason and erratically.) Luckily this error started after my first edits in PowerPoint 2010 after having tested the file in PowerPoint 2016. The error occurred when opening the .pptm but I had no startup procedure involving a file. So I've got the idea of some file in the .pptm zip archive not being found. Started to do a quick search on the internet and found only "shooting in the dark" suggestions. As I could start PowerPoint 2013 more easily (virtual machine) than PowerPoint 2016 (different Windows 10 boot partition), I tried to open the troubled file in PowerPoint 2013 and had no problems. I compiled the VBA project to check for error. Nothing. And save the file. After this re-saving in PowerPoint 2013, the file seems to work fine again in PowerPoint 2010 und did not show any problems after the first few edits, saves and re-opening. This being said, I wonder if PowerPoint 2016 saving is peculiar and if I can replicate/if I will run into the error again if saving the file again in PowerPoint 2016 and returning to PowerPoint 2010. (I'll make a note of this thread to add new insights once I worked with this file again in PowerPoint 2016.)
Hope this observation may spare many unnecessary un-/re-installations of Office and other desperate attempts.
Cheers!
A similar thing has just happened to me a couple of times with one of my .mdb front ends running in Access 2013, after the August 2019 update to Windows 10.
My DBs too have been through several versions of Access. On opening the database it says 'File Not Found' and throws up a public module (not one on which I have been working extensively recently), without opening the Autoexec (Switchboard) form. 'Debug, Compile' is possible and doesn't suggest any problem.
For me too, typing one space (or blank line or other character) anywhere in the code, and then deleting it, and saving, closing and re-opening seemed to provide a workaround, and all has been well for the last few days (I am the only user at present).
There is no one obvious module involved, although I will probably suspect the form module I have been working on most recently if the problem persists in a troublesome way.
Now, a few days later I have de-compiled, compacted and re-compiled the database, halving its size, so maybe that will have done the trick. I hope so.
I just had this problem. In my case, I think the issue is having a blank VBA module. I was moving procedures from one module to another and ended-up with a blank module. I couldn't delete the module manually and every time I tried to create a procedure to delete blank modules, I received the "File not found" error and the procedure I had just created was blanked out. I ended-up reverting to a backup.
The issue is just your references. One of the files for your references has been moved/deleted/updated. Remove and re-add your references to figure out which one.
I had a problem similar to this. A blank "File Not Found" error.
I turned off AutoCorrect and after clicking through several prompts/warnings which had me concerned, I then reopened the database and the error went away.
When reopening the database the problem was resolved.
I suspect this will fix many "File not found" errors which are probably related to the temporary link table losing a reference for whatever reason.
I had this same issue MS Excel.
On the user pressing a button a useless File Not Found error appeared.
I ran through all suggested above and no change or help.
COMPLETELY ACCIDENTALLY I removed a module that i use for updating the Application status. This also has some array storage within. However, on removing this module (and commenting out references to it within my code) it appears that the issue is now fixed across users.
One Issue, is I have the same Module name within several different deployment's of Excel Add-ins. I suspect that on first run Excel isn't able to automatically assume the difference between them.
I had noticed a WORK AROUND for the error in which you create a break point on the first line of code for the button in question and then resume on break - I assume that this helped Excel evaluate and namespace the modules as to not cause conflicts.
I had that problem and solved it this way: I eliminated the form where the vba code was and imported the same form from a backup file made before.
I found yet another solution (at least in my case): In trying to find the error, I tested the application I created on a co-workers computer. This somehow reset whatever went haywire in the file. Afterwards I was able to open up the file on my computer again and everything worked as it should!
EDIT: I have realized that the error, im my case, seems to have been connected in some way to my using SendKeys (see my attempt to automate a report here on SO).
Had the same problem. I stumbled on the fix by accident. For whatever reason, simply adding an on-click Event Procedure made everything better.
Open the form in design mode
Select an object on the form
Press F4 to display the object's properties
Event > On Click > dropdown > click [Event Procedure]
Then click the three dots, which will create a new event, and launch the Visual Basic editor. This will also add default code into the Visual Basic editor
Make no other changes
Save and close changes to the form
Restart the database
For what its worth, as I was wrestling with this issue, the error resolved itself in other ways, but none of them were repeatable.
I had this problem as well, and compact/repair did not fix it. In my case I had an old VBA module that was no longer used, and which referenced an object class that no longer existed. Removing the non-compiling code fixed the issue for me.
I have had this problem for many years now in access 2010. Always in the Autoexec form that opens on msaccess startup. I tried creating a very simple form that calls the original more complex form. To my surprise the more problem moved the the new simple form. By trial and error, I found that just editing the new simple Autoexec form the problem would go away, but turn up randomly months later ALWAYS after I had made programming changes elsewhere. Sometimes instead of the file not found error, I get just get a crash out of access - but the solution is the same procedure - make a small edit to the autoexec file (just add new blank line will do). My project has come through many versions of access (2000 -> 2010). If there was some way to automate the editing of my autoexec form, then restarting access - this would serve as a workaround. I have not found any way as yet.
I have had this problem for years in my access database. I tried all the above solutions an they all fixed the problem, only to have the problem reappear sometime later - always after VBA code change. I discovered that decompiling and then recompiling ALWAYS FIXES this problem, and is the quickest and easiest way to do so. So I have concluded that there is a bug in way Office only partly compiles after program changes like macros and VBA code changes. After a number of changes the system gets 'unhinged' and throws up the 'file not found' error. Reading thru the fixes users have found in this blog supports my theory. Nearly all these fixes would probably cause some sort and recompile the unhinged code.
MY SOLUTION
In summary I have found the following..
Doing a Decompile (without a recompile) will get rid of the error - but if the code is run on a different machine the error appears again.
Doing a decompile, then a recompile followed by a Compact and Repair results makes my app run on other machines with out any problems.
I had a class module - Class1 - that was not used. I deleted it and did a compact and repair.
Something happened that caused the name of the class module to stay in the Navigation Pane but the module as such was removed:
When opening the VBA editor I got the "File not found".
Impossible to delete the name from the Navigation Pane!!
When decompiling the project I got "An error occurred while loading 'Class1'. Do you want to continue loading the project?"
I did - now the Class1 was still in Navigation Pane when opening project again but now I could delete from the Navigation Pane.
After that the message about file not found no longer appeared.
FYI
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).