23

I just upgraded my Visual Studio from 2012 to 2013 and haven't done anything else yet short of installing all the updates recommended.

For whatever reason, when I go into my solution and press F10 or F11, it runs the entire program as if I had pressed F5... F8 works the way F10 used to, but I don't know why the keys I've always used now don't.

I set up visual studio as a VB environment.

How can I fix this?

Thanks!!!

Additional Info:

Just to add on as much information as I can, if I set a breakpoint in my code, then I can use F10 / F11 to continue stepping through my code once the breakpoint is hit and execution is stopped as would be expected.

EDIT 2013-12-31:

Based upon a comment made by Neolisk, it appears this is simply a change in default behavior in Visual Studio 2013... If anyone knows how to change this back to the way it was in 2012, that would be GREATLY appreciated, but at least I now know it's not an error / installation issue.

Community
  • 1
  • 1
John Bustos
  • 19,036
  • 17
  • 89
  • 151
  • This seem like a stupid suggestion, but have you tried running Visual Studio in safe mode? – Kryten Dec 29 '13 at 15:13
  • John, can you export your keyboard settings (Tools - Import and Export Settings - Export - Uncheck all - check Keyboard in Options - Environment) and make this .vssettings file available for our analysis? – Sergey Vlasov Dec 30 '13 at 05:46
  • @SergeyVlasov, unfortunately, my work environment won't let me post files online, but I can tell you that the .vssettings file has nothing in it... ` .... Visual Basic 6 ` – John Bustos Dec 30 '13 at 14:23
  • @JohnBustos, when you say "`F8` works the way `F10` used to," what do you mean? What did `F10` used to do prior to you updating? – valverij Dec 30 '13 at 18:52
  • in 2012, when I pressed `F10`, it would compile and leave the debugger at the first line of written code, now it simply runs as if I had just pressed the run (`F5`) button - Not having stopped anywhere. – John Bustos Dec 30 '13 at 19:18
  • If you place the cursor on a line of written code and press `ctrl`+`F10`, does the code run until that line of code? – Chris Dec 30 '13 at 19:35
  • Yes ,@Chris, it runs to that line with `ctrl` + `F10` ... Any thoughts? – John Bustos Dec 30 '13 at 19:45
  • It sounds like you might have had some custom hotkeys defined in VS2012, either from some add-on or otherwise. If you look at the VS [Pre-defined Keyboard Shortcuts](http://msdn.microsoft.com/en-us/library/da5kh0wa(v=vs.120).aspx), only `CTRL`+`F10` and `CTRL`+`F8` perform the way you've described. – valverij Dec 30 '13 at 19:55
  • 1
    Weird stuff I think I get the behaviour you're after (`F10` leaving the debugger at the entry point) in VS 2010, 2012 & 2013 - no common custom stuff installed. You're welcome to any of my settings files (don't think there' much out of the ordinary though - set up for C# development). – Chris Dec 30 '13 at 20:21

12 Answers12

7

If 2013 works the same as previous versions, then do the following:

  • Navigate to Tools > Import and Export Settings
  • Choose "Import selected environment settings"
  • On the next screen, choose to save your current setings if you want to.
  • When you get to the point where you can import, just select "General Development Settings"

That should set everything back to what you're probably used to. Most people are set up using general settings and either don't realize it or just forget.

EDIT: If your issue is that the program executes when you press F10 or F11 when you are not debugging, then I think you might be out of luck. It's done that to me personally since VS 2008 (I'll frequently miss the F12 key when I'm in a hurry), and, after some searching, I think it actually happens to everyone:

My guess is that this is a side-effect of not being able to set contextual hot keys based on whether you are or are not debugging. Since F10 and F11 are tied to debug-execution-related operations, my guess is that Visual Studio realizes that it needs to be debugging to process them, and thus starts the program.

ANOTHER EDIT: Of course, it's also possible that you had the scheme set to something else entirely in VS2012. Check out all of Visual Studio's pre-defined hotkeys by environment here: http://msdn.microsoft.com/en-us/library/da5kh0wa(v=vs.120).aspx

If none of those have the mappings that you're used to for F8, F10, or F11, then it's possible that you or an add-on may have had few custom hotkeys defined.

Worst-case scenario, you can simply redefine your shortcuts manually by key in the keyboard settings: Tools > Options > Environment > Keyboard

Community
  • 1
  • 1
valverij
  • 4,871
  • 1
  • 22
  • 35
  • Thanks, valverjj, but for whatever reason, it's still not stepping in when I press `F10`.... This si just an annoyance - Would there be ANY other reason why `F10` would stop working?? – John Bustos Dec 13 '13 at 21:18
  • 1
    @JohnBustos, it's also possible your global debug settings got messed up. If you go to Tools > Options > Environment > Keyboard, you can check the hotkeys by environment. In the box that says "Show commands containing," you can type `Debug.StepOver` and `Debug.StepInto` (F10 and F11) to see what they're mapped as (or to change them). If you chose the VB environment, [look at the VB6 scheme](http://msdn.microsoft.com/en-us/library/da5kh0wa.aspx), otherwise, look at the default (or just check all of them, I guess). Global hotkeys will have "(Global)" marked after them (ex: `F10 (Global)`). – valverij Dec 16 '13 at 15:44
  • Thanks, @valverj, but `Debug.StepOver` has "Shortcuts for selected command" set as `F10 (Global)`... WHAT IS GOING ON HERE??? – John Bustos Dec 16 '13 at 15:55
  • 1
    Typically `F11` steps into the code and `F10` steps over... so why are you expecting `F10` to step-in? – Jeff B Dec 20 '13 at 19:14
  • @JeffBridgman, when I'm in the IDE and press either `F10` or `F11`, they both start the program as if I had pressed `F5`... `F8` still works, I just don't have a clue why they now don't... – John Bustos Dec 23 '13 at 16:14
4

It sounds like you are in VB settings and not C#. You should try changing your settings to one or the other and see if those debug options change. On my machine

Tools - Import Export Settings - Reset All Settings - C# (If you want F10/F11) VB if you want F8/Shift-F8. It doesn't matter what your settings are you can still code in both languages, but if you are used to pressing F10 to debug VB.NET code you've been using C# settings this whole time. Nothing new with Visual Studio in this regard. I am using VS2013 Ultimate, have been using Visual Studio since VS2003.

The first image is VB.net, second is C# settings VB.Net Settings

enter image description here

Jaymin
  • 2,879
  • 3
  • 19
  • 35
Jason Hughes
  • 748
  • 6
  • 18
  • Jason, You were right that I was in VB settings - Thanks for that!! Unfortunately, though, `F10` STILL runs over my code... `F11` now goes to the start of my program, but `F10` doesn't... I know this isn't a big deal any more, I'm just confused as to why it happened.... – John Bustos Dec 31 '13 at 13:32
  • In a default setting F10 should "step over" code. Is that what you mean when you say it "STILL runs over my code"? F11 will take you to the entry point of the program, or if you've caught a break point, it will step into the code. If you want to skip debugging a method you would use step over (F10) to execute the method without stepping into it. See: http://blogs.msdn.com/b/habibh/archive/2009/07/30/debugging-101-how-to-skip-over-code-in-the-visual-studio-debugger.aspx – Jason Hughes Dec 31 '13 at 15:40
  • Other than that if you are having issues still, do you have another computer at your shop that has settings that work you can look at. If it still doesn't "feel" right you probably have something selected in the Debugging options that you didn't used to like "Enable .NET Framework source stepping" Or maybe some third party extention is loaded that you aren't used to. Try running in safe mode (from command line Devenv.exe /SafeMode) to see if just the default environment and services act the way you expected. – Jason Hughes Dec 31 '13 at 15:46
  • 1
    Jason - What I meant is that if I press `F10`, it simply runs the code EXACTLY as if I pressed `F5` (it shows the win-form, for example). Of course, if there's a breakpoint, it will stop there (just as `F5` would). @Neolisk traced down the problem and has said it's simply a new default behavior for VS2013... Just seems Microsoft made changes... – John Bustos Dec 31 '13 at 15:49
  • I don't think its new behavior, I've been debugging this way for a while (since at least VS2010). Nontheless you can map any of these keys in the options for Environment under Keyboard. The behavior you describe reminds me of the difference between Shift-F8 and Ctrl-Shift-F8 if you are using VB settings out of the box. Look there. – Jason Hughes Dec 31 '13 at 15:58
  • Let me back up a sec. I do see some new behavior. Yes it appears if you select Step Over from the IDE without launching the debugger first in 2013 it will just start the debugger and assuming no breakpoints are set run through the program. Which makes sense. You are selecting to step over the whole app. – Jason Hughes Dec 31 '13 at 16:12
  • 1
    Yeah, Jason, it just never did that before, but it does make sense... Before, `F10` simply took you to your first line of code and would just jump over any methods as you were stepping through while `F11` would enter them... – John Bustos Dec 31 '13 at 16:17
3

Microsoft probably has a reason to not allow to step into a property by default.

Properties are supposed to be mostly get and set and not contain a whole lot of implementation in it. But that may not be the case all the time.

If somebody is trying to step into a property that means this developer is suspecting something in that property that may be causing problems. So by default this behavior needs to be reversed and allow stepping into properties.

For now this is how you can enable stepping into properties.

  • Go to Tools > Options menu in Visual Studio.
  • Goto Debugging > General menu item in left pane.
  • In right view you will see and option Step over properties and operators (Managed only). Uncheck this option and then you are all set.

enter image description here

Enable step into properties in Visual Studio Debugger

If the above didn't work then follow this

In the Options.Keyboard page, please select "Debug.StepOver" from the command listbox, and then put focus to the "Press shortcut keys" textbox and press F10, click Assign button to re-assign shortcut, does it work?

You can also try to run Visual Studio under safe mode, which will prevents all third-party VSPackages from loading when Visual Studio starts; if the issue disappear under safe mode, you may consider checking your installed add-ons or VSPackages.

Second, to log all activity of Visual Studio to a log file for further troubleshooting, please use the /Log switch, and post the log file content here, so we can do more investigation on it.

If this feature works well before, and suddenly behave abnormally, it usually indicate that some files or configurations of Visual Studio installation is corrupted or missed, you can:

  1. Restores Visual Studio default settings by using "Devenv.exe /ResetSettings" command. Please backup your settings before restore to default settings.

  2. Repair/reinstall Visual Studio;

To repair Visual Studio In the Add or Remove Programs dialog box, select Visual Studio then click Change/Remove.

Supun Wijerathne
  • 11,964
  • 10
  • 61
  • 87
Amarnath Balasubramanian
  • 9,300
  • 8
  • 34
  • 62
3

You can try some of these reset settings:

enter image description here

And different combinations thereof, i.e. ResetToBasic first. If does not help, try ResetToC#, then back to Basic. Then try General, back to Basic. See if you can hack your way through like this.

EDIT: I tried my VS 2012, and compared to VS 2013. What you described is completely normal. VS 2012 used to step in Form_Load and similar on F10 and F11, VS 2013 no longer does it. So it seems like your VS 2013 is working as expected.

Victor Zakharov
  • 25,801
  • 18
  • 85
  • 151
  • Thanks, Neolisk. I tried this, but still no luck with `F10`... `F11` now stops at the first line of code, but `F10` runs the code as if I had pushed `F5`. At this point, I'm just giving up and getting used to starting debugging with `F11` and then using `F10`... Absolutely not a biggie, but not what it used to be.... – John Bustos Dec 31 '13 at 13:40
  • @JohnBustos: Hold on a sec, are you sure it should be different that what you described just now? I mean F10 works as F5 in a Windows app **for me as well**, i.e. does not stop at Form_Load for example, or button click handler. It only stops at first line in a Console app for me (and maybe some other project types - did not try them all). – Victor Zakharov Dec 31 '13 at 15:22
  • 1
    @JohnBustos: You are right, see my edit. Looks like there is nothing you can fix - this behavior is normal, they changed a pattern in VS 2013, and it longer works like it used to by default. Now it may be possible to change this default, but I haven't looked into it. Bottom line - nothing to worry about. :) – Victor Zakharov Dec 31 '13 at 15:27
  • 1
    Thanks, @Neolisk! - At least now I know it's not me being crazy!! - I'm going to leave the question open hoping someone knows how to change this default VS2013 behavior, but, otherwise, I'll accept yours as the solution... – John Bustos Dec 31 '13 at 15:38
  • 1
    @JohnBustos: These issues may be related to yours: [Microsoft connect issue](https://connect.microsoft.com/VisualStudio/feedback/details/781113/visual-studio-2012-debugger-f10-behaving-like-f5-continue) and [this StackOverflow question](http://stackoverflow.com/questions/9807887/stepping-through-visual-studio-debugger-with-f10-f11-behaves-like-f5-run). – Victor Zakharov Dec 31 '13 at 16:47
  • 1
    Thanks for your continued help in examining this, Neolisk! The first issue seems to never have reached resolution, though :( and I tried the solution from the second issue and still had the same issue pop up... At this point, I'm just getting used to using different keys, but till hope someone, somewhere manages to find a solution... THANKS!!! – John Bustos Jan 02 '14 at 15:15
2

An idea to test it in a short way:

Create a Hello World console app.

1 Module Module1
2
3   Sub Main()
4        Console.WriteLine("Hello")
5    End Sub
6
7 End Module

Build first. Put the cursor in line 4 (before each step), commands should start Debug Mode if you are in Design Mode.

  1. F10 (StepOver): Should break on line 3
  2. F11 (StepInto): Should break on line 3
  3. CTRL+F10 (RunToCursor): Should break on line 4

If it is working properly: Maybe the assembly which containing the entry point of your program had modified and wasn't been rebuilded, or there is somthing other problem with the point where the control expected to break.

If it doesn't work as expected on the sample, I think you should ask on MSDN FORUM or make a bug report.

I don't know why they might have intent to change this behavior. It is working for me in my 2013 Express Edition with C# recently.

Ursegor
  • 878
  • 8
  • 16
  • If it is working on a Console Application then you should try it on a simple project which type you are using and it isn't working. After it please clarify circumstances, and try to determine which upgrade causing the experienced failure. It would be great help. – Ursegor Dec 27 '13 at 15:51
  • Unfortunately, this didn't work :( `F10` and `F11` both work the same as `F5`, but I can get it to work by using `F8`. Thanks for the suggestion re: the MSDN Forum, I'll try that now. – John Bustos Dec 30 '13 at 14:09
2

I found I had to run VS as Administrator to debug properly. I also do a clean solution prior to debugging, especially on x64 machines. If you put a manual debug breakpoint in the code and the IDE indicates it can't stop at that point, then it's possible that the debugger is out of sync with the source code.

Jamie Clayton
  • 1,007
  • 11
  • 24
1

I found what I think is an acceptable workaround for the non-functioning F10/F11 Keys. They are probably the most used keys in stepping through code, and it is a real pain to click on debug and select the key from the dropdown.

I got around this shortcoming by adding icons to the toolbar for these operations.

If you are not sure how to do this, On the Debug toolbar click on the down pointing arrow near the right side of the bar. Click on Add or remove buttons. Select Customize... Select Add Command Select Debug Scroll down to the desired key (Step over / Step into) You once clicked, you will see the two icons added at the left side of the toolbar, Unfortunately they are the same Icon, but with a little use, you should be able to select the right key to click on.

I actually prefer this method to trying to remember which function key to press.

1

On many branded laptops, there is an extra button "Fn", Press "Fn" and "Esc" together. Functional keys will be enabled in visual studio.

1

Kindly press Fn key and Esc (with Lock with Fn label).

Sometimes it gets locked and Media Player buttons get activated.

Mariah
  • 129
  • 1
  • 10
0

Sounds stupid to ask but what type of keyboard do you have? I know some keyboards have different modes that allow you to set different profiles for keys based upon the application. I use the feature with my Microsoft Natural keyboard. However I have had problems with the profile still being active when I switch into Visual Studio and then F10, etc doesn't work correctly.

Eriawan Kusumawardhono
  • 4,796
  • 4
  • 46
  • 49
Aaron Havens
  • 313
  • 4
  • 7
  • Thanks for the idea, Aaron and there's no such thing as a stupid question when nothing else seems to fit. Unfortunately, though, it's a standard keyboard on my laptop that worked just fine on VS 2012 and `F10` works here, just differently than it did for 2012 as I described in my question... Thanks for the idea, though!! – John Bustos Jan 02 '14 at 15:17
0

I faced the problem that F10/F11 doesn't work but the breakpoint works.
Once I uninstall the Security Software and unload the relevant drives it works again.

So my advice is that. And I guess it's due to the drives, so if these don't work just try to unload those questionable drives may connected with this question.

doye
  • 1
  • 3
-1

Using Logitech MX 3000 Keyboard, I've upgraded to the last setpoint version and these keys work now perfectly. (Driver version 5.90.41)