I've been running VS 2019 for awhile now with no problems. I've been working on the same 2 solutions for the last year with no problems. Friday I upgraded to the latest version (16.6.2) because VS suggested I should. As soon as I did that, breakpoints in any MVC views no longer function in my project.
I have gone through the standard checklist of the old "No symbols have been loaded for this document" message. I have confirmed that the PDB files are in the right place, that the DLL and PDBs are of the same version, etc. Everything is exactly the same setting-wise as its always been. Friday morning it worked.
I installed the latest update (v16.6.2) and now the same breakpoint I had working a few hours before no longer works. Within this same project I CAN set a breakpoint in a controller or other classes - it seems to only be the .cshtml pages that are the problem.
My assumption is that one of 2 things occurred here: either v16.6.2 introduced a new setting I need to change in order for this to work, or v16.6.2 broke it. I have scoured the webs looking for any settings changes in this release and have come up empty. I have done the standard machine restart and all that stuff. No dice there either.
Are there any other troubleshooting steps I have missed?
Related
I've been working on an MVC 5 code first project for a few months and (seemingly) out of nowhere, Visual Studio is refusing to debug and giving me some strange errors.
When I try to run the application Ctrl+F5 it builds ok but the browser never gets beyond the loading stage, I still have the pinwheel in the browser tab, but the app never loads.
When I try to debug the applicaiton F5 it builds ok, but then comes up with 2 errors, firstly Debugging information for iisexpress.exe cannot be found or does not match. Cannot find or open the PDB file. and then Process with an Id of xxxx is not running.
I've tried loading symbols from MS (https://stackoverflow.com/a/8138518/1778169), using a different database name, uninstalling VS extensions, performing all Windows Updates, repairing the VS installation and even reinstalling VS entirely. Nothing seems to help.
I'm not very familiar with PDB files, but I have done nothing knowingly to change this, and they seem to be in the right place:
I am running out of ideas, but really want to avoid a Windows reinstall if possible.
It's only happening in this one project, so the problem would seem to be with the project itself, not the installation. But I have no idea where to start debugging this problem, or looking for a solution.
Possibly Relevant
I tried running the app on a custom domain (set up in the hosts file and IIS Express's ApplicationHosts.config file). In an attempt to solve this problem I reverted these settings back to the default localhost:[port]. This doesn't seem to have made any difference, but thought I should mention it just in case.
My problem was that the Native Code box was ticked in the Debuggers section of the Web section in Project Properties.
I don't know how this came to be ticked, I certainly never ticked it.
Either way, unticking this box solved my problem.
I've got a group project built in Delphi XE2 that has 3 projects that always build to the wrong folder for one option set. (I've got 4 configurations under Release and Debug, one for our software configurations and one for FastMM and it's only the debug one that I want to use for debugging that always goes in to the wrong folder. Compiling the project even says it's building to the correct folder, but the DLL always winds up in a different one which I only used once when I was unit testing the code outside of the main project.
I've deleted every associated file, .identcache, .res, .tvsproj (whatever that was) and nothing changed. One very strange thing I noticed is that I copied one of the projects to configure the second one and mimics the behavior of the one it was copied from and I never even unit tested that one, so it never had that output path configured for it.
Obviously this makes it pretty annoying to debug, I have to copy files in to the correct folder just to do that (I was kind of astonished when it actually worked, because I thought Delphi might expect to find the files in it's output path, but oh well, those things are magic)
Let me know if I can post anything to help, I don't really know what's necessary, I checked the registry for the output path that it is getting built do and found nothing that I thought was of any consequence (nothing related to these projects).
One thing I did notice was, because I copied the original project into another project (they're plugins to the same part of the main program) it has the same and when I try using it in the "Build Group" it automatically selects both projects. That's one mystery solved, but is probably a red herring?
OK so as usually happens, after 3 years of suffering with this when I finally ask the questions I'm lead straight to the answer it appears as if RAD Studio is lying to us. The configuration shows this:
but the dproj had this:
in it.
there were two conditions for cfg_3 and only the last one showed up in RAD Studio, well for some odd reason the build path was taken from the first one (even though it's specified in both). So, removing the wrong one (the first one) fixed the problem and things are now building to the correct folder.
I had imported the Utils option set when I was testing the library, but when I incorporated the program in to the main program, I removed it. Somehow it didn't find it's way completely out of the dproj and I guess (not sure why) but it seems like the other library got messed up because it shared a GUID.
I have done all the searching and can't find a solution to this weird problem that's been bugging me for about 5 hours. I started this app in Lazarus, but then took it across to D5pro to see if I could solve the problem. Thought it might have been a Lazarus "thing."
In D5, I have an app fully-working (so far so good) and I decided to try some different approaches to the look and feel so I "Save Project As" into a new folder. I then went through all of the included Units and saved them to the new Folder. I copied the two OpenSSL .DLL to the new folder. Did a compile and run and it all works fine. Well, almost.
When I tried the new app, the POP3 Unit crashes at "Login"
I have stepped through and all of the basic login stuff, Server, Name, SSL parameters etc is identical to the former version.
I went back to the original app and did a full Build and it still worked fine. I did a full Build on the new app and it still crashes at Login.
It gets through the pop3.Sock.SSLDoConnect() OK, but comes back from pop3.Login() with an error 10061 which according to the BlckSock Synapse-Unit, means "Connection refused."
When it returns from this call Result:=ssConnect(s, #name, SizeOfVarSin(name)); which I assume is in the .DLL it has a Result of -1 which then triggers the GetLastError and that is "10061 - Connection refused"
As far as I can find, everything is identical between the two projects. All Library Paths are in the Environment and not within the project.
Any thoughts and suggestions?
There is not much to work with. Can you see all parameters in the debugger on the various external call moments?
A change of compiler of course can make hidden bugs come to the surface, just like e.g. optimization. A well known difference is that the life time of temps might vary (see here).
Probably you need to nail the defining difference first. As with Delphi, the debugger is your friend here.
OK, problem solved.
Sir Rufo, it was a good idea but it did not help, but thanks for trying.
I had copied the ssleay32.dll into the new app folder BEFORE I started compiling. It did not work. I did a full Build and it still did not work.
I decided to delete the ssleay32.dll and libeay32.dll and do a full Build. I ran it and of course it crashed, but this time I expected that.
I then copied the two .ddl back into the new app folder and did another full Build.
Bingo problem solved. Seems weird but it is working with both Lazarus and D5. Something to do with the way the .dll gets linked into compiled .dcu.
Doing the Build with no .dll available cleared that. Dropping the .dll back into the Folder and another Build got the .dll linking correctly included into the .dcu.
Aaarrggghhhhh :)
I recently changed from developing iOS apps on a MacMini to a new MacBook Pro (2.2 GHz Intel Core i7). While working in XCode, I occasionally get pop-ups when the system is apparently trying to do an autosave and runs into a problem.
The pop-ups state "The document [filename] could not be autosaved. The file has been changed by another application. Click Save Anyway to keep your changes and save the changes made by the other application as a version, or click Revert to keep the changes from the other application and save your changes as a version."
Examples of the filename are: AppDelegate.m, MyLoginViewController.m. There shouldn't be anything else that is changing those files.
I can't do anything within XCode until I choose one of the options. Sometimes it seems like the system is trying to overwrite my newest code with an old version of my code, sometimes it seems like it is trying to save my newest code. So, sometimes Revert is what I need to do to keep my current version, and other times Save Anyway is what I need to do. However, sometimes, I can't tell what the system is trying to do and I choose the wrong option and lose hours of work.
This has happened numerous times over a span of three weeks.
I am using OS X 10.7.2 and XCode 4.2.1. The code is on my MacBook's hard drive.
Does anybody have any idea why this is happening?
Thank you.
This is a huge problem, and it looks like it's Lion's force-fed "file-versioning" that is destroying work.
I typed quite a bit of code into my source and saved it regularly (pretty much after every complete paragraph). Suddenly I couldn't find an entire section that I'd just written. I even did a project-wide search, in case I'd accidentally entered it in the wrong file. Suddenly Xcode raised a dialog saying it couldn't autosave the file because it had been modified externally. Did I want to "revert", or save what was in the editor?
In the several times I've seen this come up on two systems over the past few weeks, I've chosen to save what's in the editor, thinking that obviously it must be the most recent version. WRONG. I hit "Revert", and the block of code reappeared.
There is so much wrong here, it's hard to decide what's the most offensive.
Confirming that this happens on XCode 4.3.2 on an iMac running 10.7.4.
I have found that this bug may be related to having the same file open in more than one tab or window in XCode. If you carefully avoid ever having more than one window open on a given file at a time I think you can avoid this problem. However, it undermines the very useful ability to apple-click method names to navigate to the file that contains them.
This has cost me hours of original work and been the source of immense frustration. The derisive comments from others are simply inadequate.
I heard they had a complicated fix for it already at Apple, but unfortunately, it was "accidentally lost" and now they can't remember which files need what changes to make it work again. :-/
I'm developing an application on two different machines (home and work) and while the home one seems to run just fine, the work one is, for lack of a better word, possessed. It has been exhibiting the following issues:
When loading the application, it will start at the simulator's main screen instead of starting the application at random intervals. You can start the application and have it work fine, then close the simulator, reload, and have the same codebase not load.
Going to applications doesn't show the application itself, in fact it never does.
Trying to load the applications cod file (File->load java program) never works. Tried the steps in this thread, with unreliable results.
Extremely small changes, such as modifying the value of a width variable by one, commenting out a function such as makeMenu or adding a button will cause code to no longer work, with no errors shown by the IDE.
Using clear.bat with sometimes work, sometimes not. Same with manually removing all files with the name of the project.
reinstalling the eclipse environment and the blackberry plugin did nothing more then burn off an hour.
having "load on startup" in the blackberry_app_descriptor.xml file is set.
Both systems are using Eclipse 3.5.1, BB plugin for eclipse 1.1 beta, Java 4.5 with the 8300 simulator. THe only difference that I am seeing is the operating system between the two systems. The work one being XP Sp3, home being vista. THe vista one isn't perfect, but I can test variable changes without flipping a coin to see if the app will even load or not.
I've tried the solutions that were similar on this forum, such as this one, but it looked to be that those solutions are dated as none of the options for the steps existed in my eclipse install.
So has anyone ran into such baffling behavior, and can it be fixed? Anything that I might have missed that could be tried?
I've been seeing this behavior with the new 1.1 plugin, the application doesn't load on startup and the FIle->load java program doesn't help. For me, the solution was I have to run a clean build every time, that is the eclipse clean and build instead of just build, not the clean.bat... Hope this helps!
Try clearing resources that have improper naming structure in your projects stuff with spaces or special character in the name of the file.
It took me two days to figure out.
One solution i got regarding your problem.
As I See Please run the application first time as Run as blackberry simulator
that is got start and here pick up run and then Run as Blackberry simulator