I'm working on a web page as part of an ASP .Net application. When I include my JavaScript within a script node in the page I can set breakpoints in the JavaScript in Visual Studio and when I debug the project (which launches the page locally in IE) the breakpoint is successfully caught in Visual Studio and I can use it to inspect variables, step through, and do all the usual Visual Studio debugging stuff. However, when I move my JavaScript to a separate script file breakpoints stop working, and I see the message 'The breakpoint will not currently be hit. No symbols have been loaded for this document.'
I know I could take advantage of the browser's debugging tools but how do I get Visual Studio to hit breakpoints in a JavaScript file in an ASP .Net application?
It would also be good to understand why the breakpoint works when the JavaScript is included in a script node within the HTML page, and fails when it is moved to a separate JavaScript file?
Here are the steps:
1) First open Visual studio -> select your project in solution explorer.-> Right click and choose option "browse with" then set IE as default browser.
2) Now open IE. Go to,
Tools -> Internet option -> Advance -> uncheck the checkbox having "Disable Script Debugging (Internet Explorer) and then click Apply and OK and you are done.
3) Now you can set breakpoints in your JS file and then hit the debug button in VS.
I think the point I made in the question about having the JavaScript in the HTML file versus in a separate script file may have been misleading. It tried copying it back and it still did not work!
I have made two changes and now it is fixed (though I am not sure which one fixed it).
Firstly I checked the closing curly brackets on each function in my JavaScript (after reading robert4's answer to What can be the reasons for JavaScript breakpoint is not hit) and added a missing semi-colon after the function I'd recently added.
Secondly I held down the Ctrl key and clicked refresh in the IE launched by Visual Studio which should force a page reload (instead of loading from IE's cache).
I'm assuming that the second of these changes fixed things but I've included the first to just-in-case it proves useful.
Related
I'm in the process of migrating some Web Sites to Web Applications, using Visual Studio 2017. One thing I can't seem to figure out is how do I open multiple .cs files at the same time? I can open the .aspx file for them easy enough by right clicking and choosing Open. I can view the code behind on a single page at a time by right clicking and choosing View Code. In the old Web Sites I could right click multiple files at once and select View Code, however, it appears in Web Applications that option has been replaced with "View Code Gen File" which isn't the same thing. It's painfully slow to open a single page at a time so hopefully there is a setting I am just not finding.
EDIT: As requested, uploading screenshots. Only .aspx files are selected but when more than one is selected the "View Source" option is no longer there. Also I should note that if multiple are selected in Solution Explorer, pressing F7 also has no effect, though that keystroke does work to View Source of a single file at a time.
After further experimentation, I now see what you see and I agree that it's something that Microsoft broke along the way. In fact, in your own image, if you single-select an aspx file in Solution Explorer then you can see the "<>" icon appear in the button bar at the top of Solution Explorer. But that icon disappears whenever you select two or more aspx files.
I've done a lot of work with Visual Studio over the years and I can't imagine any justifiable reason why Microsoft would have deliberately removed the View Code option from the context menu for multiply selected aspx files.
This appears to be a bona fide bug that should be reported to Microsoft.
Meanwhile, as a workaround, use the File | Open option in Visual Studio 2017 and, in the resulting Open File dialog box, simply multi-select any .cs files you need (this dialog box allows you to multi-select files and open all of them at once).
1) I put a breakpoint, VS breaks where I put the breakpoint.
2) I then start browsing around the code normally to put another breakpoint
somewhere down the execution path. (maybe in another class in some other cs file)
3) I would now like to return to where I first stopped (just navigation in the code. Do not confuse with the go back in debugger feature used in VS's intellitrace debugging tool)
Right now I place a bookmark and return to my bookmark. But I forget most of times to place a bookmark. Hence this question. There's got to be a shortcut to get back to current line of execution or stopped at or whatever phrase is used to describe this. I also have Resharper if I can craft up some hotkey or shortcut. Anyway I can get back to where the debugger has "broken". I sometimes also use Ctrl - multiple times to navigate backwards.
thank you
That would be the Visual Studio command "Debug.ShowNextStatement" (usually assigned to Alt+Num*). You can also use the Breakpoints Window (Alt+Ctrl+B) to navigate between your breakpoints.
UPDATE: I implemented #Alex 's request for a more discoverable and accessible MenuItem for this functionality, as part of a commercial Visual Studio extension I created called OzCode. It works similarly to Resharper's Context Actions: when you are in break mode but have navigated far away from the 'current statement', this QuickAction will appear:
I tend to use the call stack window, double click the top line in the stack trace causes the editor window to display the code line where execution halted
I just starting working with Visual Studio and I find that debugging web apps is rather annoying. After making a change and clicking f5 it sends you to localhost:port/ however many times you are not editing localhost:port/ but you are editing localhost:port/someOtherFile, so you can see how this can be pretty annoying.
I am hoping that there is a way to optimize this. Ideally I would want to be able to hit f5 and have it just refresh whatever tab in my browser has localhost:port/whatever/youGetThePoint If this is possible it would make for some really nice debugging because many times you would never even have to click the browser.
Also, why do we have to hit shift+f5 to stop debugging. Why not just f5...
EDIT: I am using MVC2
In Visual Studio, right click on the file (Mypage.aspx -?) you want to start debugging with and select "Set As Start Page."
This will automatically open that page instead of root.
Click on your application in the solution manager
View -> Property Pages
Select the 'Web' tab on the left
Set 'Start Action' to a specific page.
You can select any page in the web project to be the startup page - once you click F5, the browser will start at that page.
Two things you can do:
You can set your web application to use your local IIS for debugging. I'm assuming you're using the standard settings that get setup whenever you create a new web app project.
To set your project to use IIS first make sure you have IIS installed on your dev machine. Select the web application project from the Solution Explorer and then right click. Hit the properties selection. The first tab on the right (build), should allow you to configure IIS to have an application for your project. It will eliminate the port number part and should be a bit easier to navigate around in.
Second thing you can do is find the page you want to go directly to and right click on it and set it as the start page ("Set As Start Page").
Also, you can Google for a Visual Studio macro that will attach to the IIS worker proc so you don't have to refresh what the browser is currently doing. You can also go to the debug menu item and select "Attach to Process..." and then find the worker proc and attach to it.
I believe Start Options might do the trick for you.
Right-click on the project, and select "Start Options..."
On the Start Options dialog under "Start action" heading, you may specify a page or start URL.
Sometimes I get the message that the breakpoint will not be hit, and no symbols will be loaded.
The red icon in vs.net changes color, and the debug mode just doesn't work.
what is the reason for this?
You may be running your project in Release mode. If so, then switch to Debug mode
From Visual studio debugging issue with files of the same name by Philip Carney
Do each bullet in the link below ONE AT A TIME, but repeat my steps below with each one you try.
Stop debugging (press red square icon) in Visual Studio
Clean Solution
Build Solution
Tools > Attach to Process (or start with debugging)
Start the program that you're attaching to, and run it such that your code will get hit
If attaching to nunit.exe, then open NUnit and run a test so your breakpoint will be hit
If attaching to w3wp.exe (IIS site), then open your site in the browser and go to the page that will hit your breakpoint
for manage code only - theres a good answer for this problem on the following site:
http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
for native + managed code - in the startup solution properties-> Debug tab
make sure that "enable unmanaged code debugging" check box is checked
After trying several suggested fixes for this I did the following to get it working.
Right Clicked my Project in the Solution Explorer and selected "Properties".
Went to the "Web" section and made sure "Start Action" was set to "Current Page".
Spent 3 1/2 hours on that... I'm going to go get a drink now.
I resolved this problem by selecting Automatic:Native Code for the "Attach to" field in "Attach To Process" form
Next to the "Debug/Release" dropdown list, there is another one with "Any CPU/Configuration Manager...". Click "Configuration Manager...", and you will see some of your projects might be in Release mode. Change all of them to Debug.
This can happen if the symbol fiels are different from the assembly (remote debugging), or when there is no "direct path", so the assembly hasent been load, but might be loaded using reflection and loading of the required assembly at run time.
This can also happen if the debugger is not attached to the process for whatever reason. If it's the case, you can always go to Debug - Attach to Process... and choose the right process. Your breakpoints should return to normal once VS determines it can hit them.
What does it say when you hover the mouse over the disabled breakpoint? It will usually tell you the problem. My favorite is the old 'source code is out of date', especially when I'm debugging a DLL. Another favorite is when the file you're looking at isn't the one you're debugging (a copy in another folder?). If it's a case where you can breakpoint a caller routine, but not the callee, stepping into the callee will force VS to open the 'proper' source file and you'll be able to set breakpoints. Confusing, I usually swear at VS at this point, it seems to help.
I had the same problem. Which I know is normally if the build versions are different, and something isn't matching up. I cleaned my project, rebuilt it, and then deployed and that got everything back in-sync.
I do not like to play with knives but the only thing that worked for me involved editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
I have tested with both deployed application and service, what I have found out that If the deployed code is different than a code in visual studio then breakpoint will not hit. Even small changes will affect and the breakpoint will not hit. So, It is better to debug the same version which is there on vs code and also in deploy application or service.
To fix this I had to re-create the virtual directory. I'm using Asp.Net 4.7 Framework and IIS Express. Went to Web project > property page > Web tab > clicked the "Create Virtual Directory" button next to Project Url textbox.
I forgot I had clicked this button in my "Main" branch, but then had switched to my "Sprint" branch. It kept running the "Main" code until I clicked "Create Virtual Directory" on my "Sprint" branch.
For me it was giving this because I haven't started the relevant project at start of application , it worked after I added project run on start
Background: I have a Visual Studio 2008 solution containing three different web application projects. If I right click on the solution, choose "Set Startup Projects.." and then choose "Multiple Startup Projects", I am able to fire them all up at once when I hit F5 (Start Debugging).
Desired Behavior: What used to happen (until it unexpectedly stopped working) was that it would automatically open up three browser instances (IE by default) and run each of the web apps in each of the three browser windows.
Current (Undesired) Behavior: All of a sudden, instead of opening three browser windows, it now opens a single browser instance and sequentially starts them all up with the exact same window/tab, which means that I am left with only one app actually running. (Whatever the last app it was that got started.)
Any idea what could cause this? I've checked my project and browser settings (including the "Reuse windows when launching shortcuts" option) and can't seem to figure it out. Any ideas?
Update: I changed Visual Studio's default browser to Firefox, and it works as expected by opening up multiple browser windows. I guess I'll just use Firefox when debugging for now, which is probably a good thing anyway.
I don't know why it had stopped working but rather have a suggestion: Check 'Don't open a page. Wait for a request from an external application.' option under 'Start Options' page of your Web project property pages. It specifies that Visual Studio won't open the browser window automatically. It should start your project in a Web server and wait for another application to make a request.
This seems to be a bug/feature in newer instances of MSVS and/or IE.
It happens in Visual Studio 2013 and 2015 as well, and might not be a bug as such, but can certainly be an undesired behaviour.
To reproduce:
Select 2 web projects in multiple startup projects.
Set one to Startup and the other to Start without debugging.
Only one browser tab is used, but you will see the tab used briefly by each project before the next one is loaded.
The problem is that the last loaded project is not necessarily the project you want to have in the browser.
An other workaround is to simply set both projects to Start.
It turns out using Firefox did the trick for me. Since there are no other answers, I will just accept this one.