How do I get visual studio 2017 to step into one of my constructors?

Question

5.00/5 (1 vote)

See more:

VS2017

Sorry for the general and (hopefully) simple nature of this question, but I can't find an answer to this for VS2017 anywhere.

The step-into (F11 on my machine) function seems to be broken for constructors. Does anyone know how to alter this unhelpful behaviour?

Update
I must be missing an option in Visual Studio 2017 here. I have now noticed that step-over (F10) jumps not to the next line but to the next breakpoint.

I don't know if this has anything to do with it, but I have just found a load of stuff in the main WPF .csproj file that I don't recognise:

<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{19445C4F-9102-4EDE-B898-6CEAEF581DD7}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>DoddPMP.WPF</RootNamespace>
    <AssemblyName>DoddPMP.WPF</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <ProjectTypeGuids>{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
    <WarningLevel>4</WarningLevel>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <PublishUrl>publish\</PublishUrl>
    <Install>true</Install>
    <InstallFrom>Disk</InstallFrom>
    <UpdateEnabled>false</UpdateEnabled>
    <UpdateMode>Foreground</UpdateMode>
    <UpdateInterval>7</UpdateInterval>
    <UpdateIntervalUnits>Days</UpdateIntervalUnits>
    <UpdatePeriodically>false</UpdatePeriodically>
    <UpdateRequired>false</UpdateRequired>
    <MapFileExtensions>true</MapFileExtensions>
    <ApplicationRevision>0</ApplicationRevision>
    <ApplicationVersion>1.0.0.%2a</ApplicationVersion>
    <IsWebBootstrapper>false</IsWebBootstrapper>
    <UseApplicationTrust>false</UseApplicationTrust>
    <BootstrapperEnabled>true</BootstrapperEnabled>
  </PropertyGroup>

What I have tried:

If I put a breakpoint inside the constructor, this is hit okay.

I have already turned on the option to step into properties but can't find anything similar for constructors.

The code I am trying this on at the moment is in the WPF App() constructor, but I am pretty sure I have had no problems debugging from here on VS2015.

Update
Well, that is weird and more than a little worrying. Removing all the guff I have posted above from the project file gets the debugging working properly inside the constructor of a class created during application start-up but the debugging is still broken in the main App.xaml.cs file.

Posted 8-Feb-18 3:41am

Patrick Skelton

Updated 13-Feb-18 5:58am

v4

Add a Solution

Comments

F-ES Sitecore 8-Feb-18 9:45am

Is it a static constructor you are trying to debug? If not it should work as normal, if so the constructor is only called the once so you have to make sure the debugger is attached before the class is accessed for the first time.

Patrick Skelton 8-Feb-18 10:56am

Thanks for the answer.

It is not a static constructor. The debugger is attached because I can step normally except for the problem of F11 refusing to step-into the constructor.

As suggested by Original Griff, I created a new WPF project, added a button and then created a POCO class of my own in the click-handler. I can step into this constructor fine, so I'm guessing my problem has something to do with being in the main App() constructor. Though, as I said, I had no problem with this on VS2015. Odd.

Richard Deeming 9-Feb-18 8:38am

Are you debugging a release build by any chance?

Richard MacCutchan 9-Feb-18 8:58am

Or possibly the code needs a rebuild.

Patrick Skelton 9-Feb-18 9:42am

Thanks for the suggestions. Unfortunately, neither is the answer. I've rebuilt and the project is set to Debug.

I've used Visual Studio since the late 90s and never seen anything like this.

Richard MacCutchan 9-Feb-18 11:05am

Removing stuff from .csproj files if you don't know what it is, is not generally a good idea, as it could well break something else. But it certainly sounds like some project setting is not correct. It may be that when you upgraded from 2015 to 2017 something go messed up. You could try recreating the project under 2017 from scratch and adding in the source files manually.

Patrick Skelton 9-Feb-18 12:22pm

I take your point about removing stuff from the project file. I did take a backup first.

I suspect I will indeed end up recreating the whole solution manually when I get time. I will try to remember to revisit this question to report whether or not this fixes it.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Patrick Skelton · Answer 1 · 2018-02-13T05:58:00

The solution to this was to repair Visual Studio and then manually recreate the entire solution from scratch.

I'm not sure if both of these steps was necessary. I suspect that the repair may have been what fixed it. However, I feel better having recreated the solution, because there was that guff in the main application .csproj file that I didn't recognise.

Sorry my answer is not more conclusive. If you do encounter a similar problem, I'd see if a simple repair fixes it before doing the time-consuming task of recreating the solution.

Hope this helps someone.