stride · Discussion #1116 (original) (raw)

Thanks for starting this discussion, it's definitely asked frequently.

From an engineering standpoint, you shouldn't modify the Stride solution to debug it.

The clean approach is:

build Stride locally
reference that version in a game project
open the game project in a second instance of visual studio

Now you can step into each method with F11 while you are debugging. Visual studio should automatically find the Stride source files.

If you want to hit a specific breakpoint in the Stride solution, start the game without a debugger and attach the visual studio instance with the Stride solution to the running game.

So you need a local build of stride and then you can set the stride version of any game to that version to compile with the local build of stride. Just make sure that you have started game studio one time so the nuget restore of game studio did happen.

This is how we do it in our workflow and as far as I know, the original authors of Stride too.

Hope that helps...

You must be logged in to vote

3 replies

@tebjan : You say "adjust in AssemblyInfo.cs" of which there are about 100 files named this. Do you mean "sources/shared/SharedAssemblyInfo.cs" for the line that reads:

 public const string PublicVersion = "4.1.0.1";

This is what I'm going to try first.

When I edited that to 4.1.0.2 -- I got all sorts of issues form Stride3D Game Studio when I started it up. Nuget resolver issues.

So I put it back to 4.1.0.1 - -and it compiles/runs fine, and Source Link lets me step into the code. (However "Go to Definition" when not debugging does not work.)

For setting a breakpoint on "startup" from Stride solution, is that possible here? I think not, since it requires me to "start it outside of VS2022 stride solution" and then use "Attach to process" to debug it -- at which point, It's too late.

I can get around this though, by stepping into the code manually via F11 -- and then it does allow me to set BP's at that point -- but I have to manually F11 to the right place ONCE first, for this to work. I'm unsure of other workarounds for this (but this only really applies to startup debugging, nothing else).

Thanks for starting this discussion, it's definitely asked frequently.

From an engineering standpoint, you shouldn't modify the Stride solution to debug it.

The clean approach is:

build Stride locally

reference that version in a game project

open the game project in a second instance of visual studio

Now you can step into each method with F11 while you are debugging. Visual studio should automatically find the Stride source files.

If you want to hit a specific breakpoint in the Stride solution, start the game without a debugger and attach the visual studio instance with the Stride solution to the running game.

So you need a local build of stride and then you can set the stride version of any game to that version to compile with the local build of stride. Just make sure that you have started game studio one time so the nuget restore of game studio did happen.

This is how we do it in our workflow and as far as I know, the original authors of Stride too.

Hope that helps...

Regarding the step 2 "reference that version in a game project", I not sure about what files should I add to my own game soltuion. VisualStudio 2022 seems to only support adding another project but not soltuion (.sln) files to exisiting soluion.

Answer selected by tebjan