I had never had this error before, and I didn't move any file, or exclude any reference.
I'm getting this error (link).
In the ajaxcontroltoolkit.dll.refresh file, I get a path to the DLL, but it is a path that was located in someone else's computer (who no longer is in charge of this).
It might as well work if I just re-do the reference, but what is weird is that I've used this reference before, and had no problems. I don't know what triggered it..
Does anyone have any clue ?
--[UPDATE]--
As expected, I've fixed it, but this question remains unanswered. Besides, the exact same problem with a coworker..
Delete the .refresh file and do a Clean and Rebuild.
Related
I have a few t4 templates in my solution and at some point I renamed the the files and made some changes to them. When I did a build I got the above errors. Interestingly enough when I click on the file names nothing happens and when I hover over them to get the full name I notice that it's referencing the file name that I changed earlier. Also I've gone to all the files it could possibly be referencing and made sure that this error is not occurring in any of them.
I've tried cleaning and rebuilding, ensuring that all the projects are configured to build in the configuration manager. I deleted the file that I renamed and recreated it and the errors were still present even while the file was delete. Also I tried creating a file with the exact same name as the one referenced in the error message and it actually let me create the file, indicating that vs clearly knows that there is not file with that name so it seems to be a problem specifically with the debugger maybe?
I suspect this could be some strange behaviour with t4 templates as I feel like something like this happened before. A full restart of my machine was what solved that last time but it didn't work this time.
Ok so after hours of unsuccessfully scouring the internet I noticed that the 'CustomTool' field in the file properties had a typo in it which was causing the strange error.
Recently, whenever I change something in my code, rebuild, and attempt to debug, I get the error "This breakpoint will not currently be hit, No symbols have been loaded for this document."
But then as soon as I restart my computer, everything is fine and I can debug properly. Why is this happening? It's really frustrating having to restart my desktop every time I try to debug my code. I've looked all over stack overflow and MSDN and can't find any solution to my particular problem. Any help is appreciated
"This breakpoint will not currently be hit, No symbols have been loaded
for this document."
(As for this error message, it's common error which has different causes. I can't give the most direct correct answer for this issue, I can only give you some tips for trouble-shooting. In order to avoid losing contact in the round-trip comments, I post those content as answer instead of comments.)
Since VS2015 have been released for long time, I would think this issue is a particular one, not found similar issues online.
First of all, please create a new simple project to check if this issue occurs in new project when debugging.
If it persists in new project, I think this issue has something to do outside environment like VS settings, VS config files or Debug options.
You can try:
1.Go Tools=>Import and Export Settings=>Reset all settings =>No,just reset settings=>Finish
2.Repair VS IDE since it seems to work well in the past, and just got the issue recently, so maybe something is broken for your IDE(In Control Panel find VS2015, right-click=>change=>repair). Also, make sure you have the latest VS2015 Update3 instead of earlier versions.
And if it works well in new project, then maybe the issue is about the whole project or solution itself. You can try:
1.Navigate to solution folder, close all vs instance, delete the .vs, bin and obj folders and restart VS to check if it helps.
2.Make sure you've loaded the required symbols, check the content in your Modules window during debugging, there's possibility you don't load necessary symbols successfully.
3.Check the output folder after your rebuild, check in folder like bin\debug folder if you have both the .exe and .pdb files. And make sure the .exe and .pdb files are up-to-date after your rebuild by checking their Date Modified.
Hope it helps and more info about the project type, dependencies would be better:)
The company that I am working at is still using visual foxpro, and I am doing a fingerprint scanner using vfp9 and Griaule Fingerprint SDK 2009.
Everything is doing fine during the first run of the program. But when I re-run it againg. The error will happen. Any ideas why I keep on having that problem? Missing GRFINGER.DLL.
It's getting hard for me to find any support today because foxpro application development is getting obsolete.
The rub of the problem seems to be that the first run causes Fox to be somehow unable to find the DLL or to load it. The latter can occur if the DLL itself is findable but one of its dependencies (like its C runtime DLL) is not.
This may be due to a changed search path (SET PATH). If the search path contains relative directories then a simple change of the current working directory changes the effective search path, even though the actual text (set("PATH")) remains unchanged. That can happen because of things like file open/save dialogues, for example.
P.S.: sorry for the belated answer - the question was at the top of the recent/active list because someone had edited the question recently, and only after posting the answer did I realise how old the question was. However, the answer might still be useful for someone with a similar problem.
I have no idea how this started so I'm guessing there's a setting somewhere that I've been unable to find. I have a test that calls a method but when I run debug, it simply will NOT step into that dll. At all. Period. Throws an exception just fine, but it's kind of worthless when I can't step into see what's actually going on.
When another team member picks it up, he's able to debug the exact method I was attempting to target. Yes, same breakpoints, yes, same code (I checked in, he got it, ran just fine)
What the hell?
update : checked the test project for stupid entires, deleted the debug/release folders for fun, I've went though and dumped the project completely and got it back out of tfs. I've nuked the appdata/local/ms/vs/10.0 folder and the /appdata/roaming/ms/vs/10.0 folder. Deleted the local test results.
You probably need to investigate your project references. Is the DLL possibly GAC'd? Take a close look at the *.csproj file.
The fact that it can be debugged no problem on someone else's machine indicates to me that you're having an environment issue. Some sort of multiple library reference issue.
Another possibility: Visual Studio (and all its embedded tools) can have many strange caching behaviors. You might want to clear out extraneous MSTest-related temporary cache files/dirs.
Ok, got it. You can't do one of those things and it works. I had to do them all prior to opening up vstudio again. It'll blow your settings away just as a heads up.
Kill the AppData/Local/Microsoft/visualstudio/10.0 folder
Kill the AppData/Roaming/Microsoft/visualstudio/10.0 folder
Kill your entire project ... all of it.
Get latest (force)
And it works again.
I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.