Debugging the generated code
The following applies only to example / demo / test projects in this solution. Let Foobar be one such project.
Build a project and debug generated code
To debug Foobar's generated code:
- Build project Foobar in the `Debug` configuration.
- The generated native solution will include a custom build step to copy the target binary
foo_bar.exeto thebindirectory, and also to write debug configuration properties pointing to that copied binary.
- The generated native solution will include a custom build step to copy the target binary
- Open the generated native solution in another instance of Visual Studio.
- For example: right-click on Foobar, select "Open in Terminal" and run the following:
devenv .\obj\Debug\net8.0\qtdotnet\native\build\foo_bar.sln
- Now you have two Visual Studio instances running side-by-side:
- VS#1 with the qtdotnet.sln solution
- VS#2 with the foo_bar.sln solution
- For example: right-click on Foobar, select "Open in Terminal" and run the following:
- Switch to VS#2 and press F5.
- The Foobar app starts in debug mode.
- It should be possible to break anywhere in the app's code.
Note: By default, the "mixed mode" debugger is selected. This allows breaking and stepping through both the native and managed code of the app. There is however, a limitation to using this debugger mode, namely that it will only be possible to step into/through native code once the managed debug session is running. In practice this means that it will not be possible to break at the main function of the application before the loadApp function of the .NET host is called. Debugging native code executed before this call can only be done in a native-only debug session.
Changes to Foobar's generated code in VS#2
It's possible to make changes to the generated native code inside VS#2 and debug those changes right away.
- In VS#2, make changes to the generated native code.
- These changes will, of course, not be reflected in the code generation rules. Rebuilding Foobar in VS#1 will overwrite any changes made to the generated code in VS#2.
- Press F5.
- The generated foo_bar.sln solution is built, taking into account the changes made.
- The `foo_bar.exe` is copied to the `bin` directory.
- The Foobar app starts in debug mode.
Changes to Foobar C# code with both VS#1 and VS#2 opened
- In VS#1, make changes to the C# code of Foobar.
- Build Foobar in VS#1 in the
Debugconfiguration.- This will overwrite any changes made to the generated code in VS#2.
- Switch to VS#2 and press F5.
- The Foobar app starts in debug mode.
- The changes to the C# code should be in effect.
Changes to generation rules with both VS#1 and VS#2 opened
This requires a rebuild of Foobar because the incremental build up-to-date check for the project will not include the generation rules (or the generator tool).
- In VS#1, make changes to the generation rules (or the generator tool).
- Clean the Foobar project.
- For example: right-click on Foobar and select "Clean".
- If VS#2 is opened, this will result in an error due to the output dir of the generated code being in use. Ignore this error.
- Build the Foobar project in the `Debug` configuration.
- Assuming project dependencies are correctly set up, changes to the generation rules (or the generator tool) will be included in the build and be in effect when generating the code for the Foobar project.
- This will overwrite any changes made to the generated code in VS#2.
- Switch to VS#2 and press F5.
- The Foobar app starts in debug mode.
- The changes to the generation rules (or the generator tool) should be in effect.
© 2025 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.