Unable to properly debug duality when using a netstandard project

[Barsonax]

Summary

When you debug your plugin in VS it actually starts the Launcher.exe since the library itself is not runnable. This works fine for net portable projects but when doing this in a netstandard project things go wrong. Your game will run fine but you are unable to stop execution or step through your code.

While this 'bug' is not strictly related to duality as I can reproduce this easily outside of duality it does affect duality. This issue is mostly for aggregating info together in the hope to find a suitable workaround or fix.

Made a issue about this on the netstandard repo here

How to reproduce

• Download and open the attached test project.
• RebuildBuild the solution and start ClassLibrary1. This will actually start the exe generated by NetStandardDebugTest. Note that it will run properly.
• Now set a breakpoint and run it again. Note that the break point will not work.
• Now try to pause the execution. You will get a Unknown error 0x80004005

Workaround

• Do not use netstandard. This is currently a good workaround but eventually we want to switch to/support netstandard at which point this issue will become a blocker.

Attachments

• NetStandardDebugTest.zip

[ilexp]

Made a issue about this on the netstandard repo here

Good call 👍 Let's see what comes out of this. I have the feeling that this should work, and that there might be some insider info that could help us understand what's going on here.

[Barsonax]

The issue was moved to dotnet/project-system#3690 since its a tooling issue

[Barsonax]

Seems this is finally getting fixed in VS16.0 (so 2019)

[Barsonax]

Well seems its not fixed in VS16.1. Unclear when it will get fixed but the milestone says its somewhere in 16.x...

[ilexp]

Can confirm it's not fixed in the latest VS 2019.

It does seem to work when the executed / launcher project itself is a .NET Core project though - can anyone else confirm this?

Assuming I didn't overlook something, it means if there was any way we could move to .NET Core and .NET Standard as part of issue #573, entirely removing the .NET Framework, we would work around this issue. That does increase the scope of #573 even more though, and I'm not even sure .NET Core is anywhere near production ready or "battle tested" for desktop applications. Not sure that would be wise right now, but it's an option that exists.

[Barsonax]

Yes moving to dotnetcore will workaround this issue.

[Barsonax]

I also believe that starting the app from a netframework project will probably work as well. One possible workaround is to introduce a 'duality' project which is a netframework project and is used to house stuff that does not fit in a plugin but can also be used to start duality. I know this is a more drastic change but might be something to consider since it may have other benefits as well.

[ilexp]

I also believe that starting the app from a netframework project will probably work as well. One possible workaround is to introduce a 'duality' project which is a netframework project and is used to house stuff that does not fit in a plugin but can also be used to start duality.

Tested it, and works just fine. Added a simple GameDebugger .NET Framework console application that was configured to run the launcher and made sure it was the first defined project in the .sln file - now when I open the solution, the Debug button is wired to GameDebugger by default and I get full debug ability for both .NET Standard and PCL game plugins. Since the debugger project is never copied to any of the Duality folders, it remains completely invisible. Seamless workflow, no significant downsides. I'd say we found our workaround 👍

I'll take care of providing an updated project template when we get back to this issue after #574, so we are no longer blocked here.

I know this is a more drastic change but might be something to consider since it may have other benefits as well.

Do you have specific things in mind? Right now, the project is empty and everything it contains is insignificant as long as it compiles. Of course there's a lot of crazy stuff we could do, like

• ...actually including the launcher source and have every game bring along its own launcher.
• ...do some relative path shenanigans to have a project that links all the assets in the file system as project files.
• ...same as above, but only include project config and similar stuff.
• ...none of the above, because we don't really need it.

Any thoughts?

[Barsonax]

Do you have specific things in mind? Right now, the project is empty and everything it contains is insignificant as long as it compiles. Of course there's a lot of crazy stuff we could do, like

• It might also be possible to move build related logic to that project and keep the plugins very clean? Currently if you have many plugins that logic is duplicated across all plugins and you cannot simply add a new project since you also have to edit the csproj to make it work. With the new approach all one would have to do is reference it and it should work with any kind of project as long as it compiles. We tried to solve make this easier with templates but that still prevents you from easily using a custom folder structure due to relative paths in all the csproj's.
• Projectify duality, no longer needed to download a zip and extract it to a map. Just add a new project and it works (might need to provide a template for this)? Maybe even from the commandline with dotnet new https://docs.microsoft.com/en-us/dotnet/core/tools/custom-templates

No must have's but I do think it can streamline the whole process of developing a game with duality and make it easier to quickly setup a new project or move things around.

[ilexp]

Progress

• Added extracted GamePluginTemplate to the repository for tracking change history besides opaque .zip.
• Auto-packing .zip of the GamePluginTemplate on editor compile to ensure consistency.
• Fixed an extraction bug regarding non-existent directories that never triggered until now.
• Replaced postbuild shell commands for copying plugin binaries with a shared / imported .targets file that copies the output to the plugins folder. If users add a custom project, it's still not auto-copied, but all they need to do is add the .targets import and that's it.
• Triggered a binary release.
• Moved towards GameDebugger project setup for supporting netstandard debugging and pushed the working implementation to the feature/plugin-game-debugger branch. This is not released yet.

ToDo

• Review GameDebugger branch (@Barsonax), merge and release it when ready.

[ilexp]

Progress

• Removed GamePluginTemplate.zip from source control, since it's auto-generated now anyway, and a merge conflict hazard.
• Restored console output via GameDebugger project by changing its project type.

ToDo

• Merge GameDebugger branch and release when ready.

[Barsonax]

Will check this branch this weekend 👍

[Barsonax]

Yup this is exactly what I as thinking in its most basic form.

Also good call with the .targets file and removing the GamePluginTemplate.zip from git.

There some more things we could do with this project such as moving all build logic to the csproj of the GameDebugger or making it a fully customizable launcher. These could be done in future PR's though and might also need more designing work.

[ilexp]

Merged and triggered a binary release.