Visual Studio 2019 - breakpoints not hit

[ScottFergTMXEZ]

After loading the SpurGear sample in the new VS 2019, a breakpoint set at the 'run' function are no longer effective. The debugger does not stop there. (This involves attaching the VS debugger to the Fusion360 process and setting the breakpoint in the DLL then 'run' the AddIn.) With the same project and reproducing the same steps in VS 2017, the debugger stops at the breakpoint as expected.

Any experience in the community at getting this to work?

[goyals]

Fusion has not moved to VS2019 yet so that might be the reason for the behaviour you are seeing.

[nnikbin]

Hi @ScottFergTMXEZ ,

As you can see in the following screen capture, I set a breakpoint in VS 2019 Community Edition at the 'run' function of SpurGear.cpp and there was not any problem. The debugger stopped there.

Make sure that the project name, output dll name, manifest name and folder name of your add-in are the same (except the extension part).

[ScottFergTMXEZ]

I appreciate that Fusion does not yet support VS2019. But from the viewpoint of VS, Fusion is just another EXE and a DLL built and debugged by VS should be independent of that. The success that "nnikbin" claims below substantiates that.

Thanks.

[ScottFergTMXEZ]

Thanks for the data point. Knowing it works for you, and assuming we have the same sources and API libraries, suggests there's some global setting in my VS2019 environment (independent of the project/solution) that is causing my problem. I'm still at a loss for how to proceed with isolating the problem, But if I find the answer, I'll post it here.

[nnikbin]

Are you debugging the original SpurGear project or a copy of it? Is the project name, output dll name, manifest name and folder name of your add-in the same? (except the extension part).

[ScottFergTMXEZ]

In reproducing this problem (yet again, N-th iteration) I have copied the SpurGear source (from "CPP\AddInSamples\SpurGear") to a local folder ("H:\SpurGear").

Loaded the project in VS 2017, rebuild, launch Fusion, attach process, set breakpoint, add AddIn at this new folder location, run AddIn, breakpoint reached, shutdown Fusion.

Loaded the same project in VS 2019 (ignoring suggestion to update platform and toolset -- yes, I've tried it both ways), rebuild, launch Fusion, attach process, set breakpoint, AddIn already added at same folder location -- verified by AddIn details, run AddIn (run on startup was not set), breakpoint NOT reached. I've even verified using Process Explorer that the DLL is in fact loading from the expected location. And I've changed the "command has been added" msg to verify which version is running. I can then redo the scenario in VS 2017 where it still works. This result should, I believe, alleviate any concerns about naming issues.

It concerns me that the sample build uses a Post-Build Event to copy the DLL from the Debug directory back up to the main folder. This obviously places it in the location with the manifest and resources, but it is NOT the same full file path name that the VS environment (and debugger) associates with the build product output which has the potential for great confusion. That this ever works is interesting to me and suggests the debugger somehow identifies with the DLL even though its full path name is different. I did try copying the manifest and resources down to the appropriate debug directory where Fusion adds it just fine, but the breakpoint is still not reached.

FWIW, to any Autodesk people listening: It's probably best to use the build process to copy the manifest and resources to the build directory than to copy the DLL up. This is a common practice and there are settings in the project to do just this. More complicated projects may have additional build products, other files, dependencies and DLLs and it gets pretty sloppy having to copy these up where they are never 'cleaned'. I know SpurGear is just a sample, but it should reflect best practices.

[nnikbin]

@ScottFergTMXEZ , I went through the steps you mentioned. The breakpoint works. I saved the solution in Visual Studio 2019 (Community Edition) and uploaded the zipped folder (containing all compiled and intermediate files and folders) here. I hope it helps isolate the problem.

(For this version I ignored the suggestion to update platform and toolset. But in both modes the debugger stops at breakpoint).

[ScottFergTMXEZ]

Thanks! That could prove helpful. I've downloaded the ZIP and will investigate more soon.

[ScottFergTMXEZ · Accepted solution]

I finally resolved the problem by uninstalling "Python development" from Visual Studio 2019 using Visual Studio Installer > Modify.

I can only speculate that, since Fusion 360 supports Python, VS 2019 somehow sensed that and selected the wrong debugger. If this is the problem, perhaps there's some way to force the C++ debugger to be used?! It is odd that debugging works in VS 2017 where I also have Python development installed.

[Anonymous]

Your solution worked for me.

Removed Python from VS2019 Community and everythings working great.

[LiveLover]

Csott Ferg, good day! is SpurGear C++ source code available some where? It seems Very interesting to look at.

And I'm exercising the very same problem with debugging as you describe here.
Does debugging works well for you now? (latest Community VS?)

https://forums.autodesk.com/t5/fusion-360-api-and-scripts/how-to-debug-c-code-in-visual-studio-with-... 

[ScottFergTMXEZ]

The resolution stated above worked for me.

Source for the sample SpurGear is delivered somewhere by Autodesk, either with Fusion360 or as part of the API package. I don't recall which.

[JeromeBriot]

---

@LiveLover  a écrit :

 is SpurGear C++ source code available some where?

---

Hello,

Go to the Fusion 360 install folder and search for the CPP/AddInSamples/SpurGear subfolder.

[LiveLover]

 JeromeBriot Thank you!!
Yes
Shift+S -> SpurGear C++ ->"Edit"  and it is where you describe.

[charliex2]

sometimes when i can't get the c++ breakpoints to play along nicely,  i just insert a hard coded breakpoint in the code and then VS will resolve the rest.

as  long as its launched from a  debugger, or a debugger is attached you can remove the check and if JIT is in, you can choose a debugger when it hits the BP

if (IsDebuggerPresent()) {
DebugBreak();
}