Forum Replies Created
-
Posts
-
I think I figured out what the problem was. I installed the .NET 3.5 dev tools after installing VS 2017 and VisualGDB. I repaired Visual Studio by running the VS 2017 Launcher and selecting More->Repair. This fixed the issue.
I should have been a little bit more clear: the GDB debugger no longer functions in 15.5. I was able to start debugging a .NET application without any trouble.
It looks like Microsoft completely hosed being able to debug in VS 15.5.0. After a clean install of windows, VS2017, everything, I’m still getting the “Attaching the GDB debugger to process ‘[0] <project name>’ on machine ‘<machine name>’ failed. General Exception” dialog box when trying to start the debugger.
There is something about updating VS2017 with VisualGDB installed that kills both products. I just remember I ran the VS2017 installer then went to lunch. When I came back, VisualGDB would not start the debugger and the VS2017 installer would not launch. I’m in the process of wiping and reinstalling Windows. I never had this problem with VS2015, which leads me to believe that Microsoft is playing it fast and loose with their VS2017 updates (no surprise there).
Reinstalling VisualGDB and Visual Studio did not resolve the problem. I tried going back to a known, good restore point, and I still get the same error.
Now I’m getting a new error. “Attaching the GDB debugger to process ‘[0] <project name>’ on machine ‘<machine name>’ failed. General Exception”
Correct. Manually creating the directory fixes this build error. I added a couple of (empty) folders in source control and our build box no longer fails with the missing .alldeps error.
I forgot to add the linker scripts back in after converting the projects. I converted them by deleting the old project files (makefiles and .vcxproj), and then created new projects with the MSBuild configuration. Added the header and source files, setup the options and include directories, and I was back up and going (well, after I figured out the linker script issue). I was unaware that there was an automatic conversion added to VisualGDB. I remember asking about it when the MSBuild feature came out. Anyways, everything’s good at this point.
Okay. Not quite a bug. Turns out the build agent was missing C:\SysGCC\arm-eabi\ToolchainPropertyPage.xml.
Scratch that. I’m still having this problem.
Manually creating the directory fixed the problem. The expected location of the .alldeps file is located under TFS control, and I suspect that might be causing VisualGDB to fail to create the file. VisualGDB is throwing a System.IO.DirectoryNotFoundException.
UPDATE: This is only a problem when trying to build from the command line. Executing “msbuild <project name> /p:Configuration=Release /p:Platform=VisualGDB” dies on the “PrepareFastUpToDateCheckDatabase” step. Building from within Visual Studio seems to work.
Our projects are using just the register definition files and the startup code for the nRF5x. We’re not using the full SDK.
I did the conversion manually. I deleted all of the old Make project files and created a new MsBuild project, and re-added all the files to the new project. That went fairly smooth. I didn’t know there was an automatic way to convert projects. Anyways, when I did the conversion, I forgot to add the linker scripts. There weren’t any changes make to the linker script from the nRF5 DSK.
When I made the transition, I didn’t put the linker script back in place. The Make-based projects all used linker scripts. When I added the same linker script to the MsBuild – based projects, my symbols started working again. Interesting.
