Extension stopped working on VisualStudio v17.3.0

[Xyotic]

I updated VisualStudip from 17.2.5 to 17.3.0 and the extension stopped working. I did the update on two seperate machines to verify this issue.

When pressing "Play in Editor" nothing happens. Not even a error message or console log.

Works fine if I go back to 17.2.5.

[Commander-Firestrike]

I believe your issue is the same as mine - I assume it is since the problem I experienced appeared after updating VS2022 to 17.3.0 also. I did a lot of digging and a bit of messing around and I managed to get the extension working again, and I will attempt to explain how... but firstly we need to go over a bit of background.

The issue I was experiencing was an error appearing mentioning a "method not found" after trying to run and debug the project, similar to what you said about the "Play in Editor" button not working. I cloned the repo and built the extension myself in VS2022 to debug it. I found that in the DebugLaunch method, the debugger session is created, and the constructor for GodotStartInfo was throwing the exception. It inherits the StartInfo type from the Mono.Debugging.VisualStudio namespace, which is from the package of the same name (<PackageReference Include="Mono.Debugging.VisualStudio" Version="16.1.3-pre" ExcludeAssets="runtime" /> in the .csproj)

I can't for the life of me find any reference to "Mono.Debugging.VisualStudio" anywhere else within Google's reach apart from this tangential mention on this stackoverflow thread. Yet, the .dlls exist in the Xamarin extension folders of older Visual Studio versions. Changing the version in the csproj always gives an error saying the package cannot be found on nuget/myget.

Luckily, the extension also exists within the VS2022 installation folder. Updating the reference of Mono.Debugging.VisualStudio and adding references to the Mono.Debugging, and Mono.Debugging.Soft dlls in the [Program Files(might depend on where you installed VS)]\Microsoft Visual Studio\2022\Community\Common7\IDE\Extensions\Xamarin\Mono.Debugging\ directory and the extension works again! I have not done extensive testing but it looks like breakpoints work.

Now, ideally I would make a pull request, but have instead decided to document my findings here - because of my lack of understanding of the mysterious Mono.Debugging.VisualStudio package and where it comes from. I have no idea if it will work on other peoples' machines being packaged as a .vsix when the dlls are referenced by path instead of nuget packages. It appears as if there is no way to reference the required dlls without referencing the files in the VS2022 installation folder. It looks like it is just part of the internal Visual Studio Xaramin functionality. I can't find any source, I can't find any documentation, and like I said I can't even find mentions of it online.

I'm not sure where to go from here, since lack of any info about the package prevents any kind of meaningful development.

[GeorgeS2019]

@Commander-Firestrike Have you tried the latest PR e.g. 35 to check if this works with VS2022 and for the Godot4 dotnet6 merged

[GeorgeS2019]

Do we still need the StubProj project (the workaround to make the exension work

[Commander-Firestrike]

Do we still need the StubProj project (the workaround to make the exension work

Currently I'm using my own build of the project with some slight edits I made to add a button in the toolbar to launch the debug session instead of relying on the StubProj method. I recommend checking out Jiiks' fork. which appears to fix the issue although I haven't tested it.

@Commander-Firestrike Have you tried the latest PR e.g. 35 to check if this works with VS2022 and for the Godot4 dotnet6 merged

Also I have not tried this yet, as Godot 4 will use dotnet 6 but this plugin uses the Mono debugger, so I am guessing the entire plugin will need to be rewritten.

[GeorgeS2019]

It launch Godot..in a more reliable way than the StudProj

I hope debugging is the next step

[Commander-Firestrike]

It launch Godot..in a more reliable way than the StudProj

I hope debugging is the next step

What do you mean by "it"? Are you referring to Jiiks' fork?

[GeorgeS2019]

YES!

[Commander-Firestrike]

Okay cool. I'll mess around some more to see if I can get breakpoints more reliable.

[GeorgeS2019]

I assume this is Jiiks's plan

• Step1: Allow use of Visual Studio command line arguments - to launch Godot in realiable way not possible through the StudProj

• Step2: Add a menu for launching GoDot from visual studio - to trigger the step1

• Step3: Change GoDot to Godot

• Step4 + follows; Look into Neikeq code how to trigger the debugging! As Jiiks's steps has addressed the main issues of the StudProj, unreliable way to launch Godot

[Commander-Firestrike]

Alright cool. I might make some pull requests then.