Extension Doesn't seem to be working in Godot 3.2.3RC4

[Alriightyman]

OS/device including version:
Windows 10

Issue description:

1. Installed Godot CSharp extension
2. Create new project in Godot 3.2.3 RC4
3. Add a Node into the Scene
4. Attach new C# script.
5. Visual Studio opens

Expected:
Expected to see Play In Editor, Launch, or Attach

Actual:
Only see the Project name and it will not launch instead throwing an error of A project with an Output Type of Class Library cannot be started directly

Screenshots of issue:

NOTES
This worked just fine when using RC3. My guess is that when RC4 upgraded to the csproj sdk format, it broke compatibility.

[neikeq]

I'll have a look. The ProjectTypeGuid was moved to the Sdk. I hope Visual Studio can support that.

[akien-mga]

I had the same issue yesterday with a pre-RC 5 test build, and I expect the newly released 3.2.3 RC 5 still has the same issue.

Edit: Confirmed, same issue with RC 5.

[MrZak-dev]

I confirm this issue , Windows 3.2.3 RC 5

[toddgibson]

I was really excited about this and installed 3.2.3 RC 6 and am experiencing the same issue using release 1.1.1 of the extension.

[31]

I dug into this, and I got something working again, but with a significantly degraded experience. 😕 Basically, I made a button that assumes the current startup project is a Godot project and launches the debugging session.

---

The problem seems to be the new project system, and not using ProjectTypeGuid at all anymore. The first hint I saw towards this was dotnet/project-system#232:

ProjectTypeGuids property

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

Used to indicate the project factories that should be used to open a project inside Visual Studio.

CPS completely removes the need for this, and this can be safely removed for projects that have opt'd into CPS.

There's also this chart indicating a very different new system in use for .NET-Core-style projects: https://github.com/microsoft/VSProjectSystem#compare-mpfproj-and-visual-studio-project-system

Criteria	MPFProj	Visual Studio Project System (this repo)
Maturity	Release	Preview
Breaking changes in major updates	None	Expected
[...]	[...]	[...]
Used by project systems	Desktop C#/VB/F#	.NET Core C#/VB/F# and C++
[...]	[...]	[...]

They have a doc page for project flavoring: https://github.com/microsoft/VSProjectSystem/blob/master/doc/overview/extend_an_existing_project_type.md. But... as of writing, it's TODO 😢:

Extend an existing project type

TODO

I wanted to try out using the new system, but I hit a wall trying to find docs or any kind of example that resembles what the Godot extension needs. Maybe someone will have more success than me here.

---

On to what I did... I added a basic Command template and wired in a few methods to assume the current default project is a Godot project, register it, and launch the debugging session:

^ This shows up as "Tools.DebugCommand" in the keybinding settings.

Branch/diff: button-assume-godot

This is my first time doing anything beyond F5ing a VS extension project, so I don't have the experience to polish this up into something that might be usable broadly. Maybe the general approach of simply having our own set of launch buttons might be good enough for now? It's good enough for me, and still way better than trying to use the Mono debugger manually.

[SantasLair]

I noticed that in the csproj file the Godot SDK is specified: "<Project Sdk="Godot.NET.Sdk/3.2.3">"
Could that be used to determine if the project is a Godot project?

[wihrl]

But will it ever recover?

[neikeq]

Sorry for the delayed reply. It's as @31 said, Visual Studio uses a new project system for Sdk style projects.
I've tried about everything to get the extension working with the new VS project system, but nothing seems to work. In fact not even the samples worked (throwing composition exceptions that seem to indicate some of the DebugLaunchProviderBase imports cannot be satisfied).
At this point I'm not sure if right now this new project system support the extensibility we need.

As that problem is unlikely to be solved soon, we will need to go with a workaround. I'll make the extension load always to have Godot special code completion work, and I will add commands for launching the debugger similarly to @31's workaround.

That should be enough to make the extension usable again, even if it's a degraded experience. At least until we can make this work with the new project system.

[neikeq]

By the way, there's a workaround you can use today to make the extension work. The idea is to use an old style C# project as placeholder to trigger the extension.

Add a new C# project to your solution. Make sure it's an old style project, not Sdk style. Add the ProjectTypeGuids containing the Godot GUID, and add a project reference to your actual game project. Here's an example:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{F97F64DA-67E2-448D-8516-2F7427C8B882}</ProjectGuid>
    <OutputType>Library</OutputType>
    <RootNamespace>StubProj</RootNamespace>
    <AssemblyName>StubProj</AssemblyName>
    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <Deterministic>true</Deterministic>
    <ProjectTypeGuids>{8F3E2DF0-C35C-4265-82FC-BEA011F4A7ED};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <ProjectReference Include="..\MyGame.csproj">
      <Project>{5957a55d-a731-4684-85cb-0bf023e5d393}</Project>
      <Name>MyGame</Name>
      <Private>False</Private>
    </ProjectReference>
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

Change the path, guid and name of the ProjectReference to point to your game project (or just remove that part and add the project reference from Visual Studio).

Set this project as the "Startup Project" in Visual Studio, either from the toolbar next to the launch button or right click the project and "Set as Startup Project".

That should be enough to make it work. The launch button should be "Play in Editor" again.

The reason the placeholder project needs to reference your game project is because otherwise VS shows "No compatible code running" when a breakpoint hits.

[juanpaexpedite]

I have done the @neikeq workaround and now I have that issue. What option do I have to do in Godot to make it work?
NOTE: Using Godot 3.2.3 stable x64

[neikeq]

@juanpaexpedite You should have a Godot editor instance open editing the same project. If you already have and still get that error, then it's a bug. But that would be a different issue to this one.

[spacechase0]

I noticed that editing when paused & continuing doesn't appear to actually take the changes (athough breakpoints appear to work fine). (I can also edit the files when the game isn't paused, like other things that work with edit & continue.) Is this a limitation of the addon, or part of this issue?

[AnderssonPeter]

Skimmed thru the comments but are sadly did find any thing that could work.
I installed the latest version of the addon (in the release tab)

1. created a new project in godot 3.2.3
2. added a root scene
3. attached a .cs file to it
4. Opened the cs file from godot (This opens visual studio)
   But no options show up
   

<Project Sdk="Godot.NET.Sdk/3.2.3">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>
</Project>

Am i forced to use the old ,csproj format to make this work?

[piratesephiroth]

Am i forced to use the old ,csproj format to make this work?

yeah, at the moment you have to use the workaround posted above by @neikeq
You can just use the project file he provided and adjust the stuff inProjectReference, then add it to your solution in Visual Studio.

[BaronKiko]

I can confirm the workaround still works. I feel like a better solution. and something that's needed regardless. is a generate vs project button in godot. Then it can just generate the proxy project for you.

[31]

I've pointed a few people at this issue who needed more info to successfully apply the workaround. So, I decided to try it out and document a full process to get the workaround in place.

Step by step workaround guide:

https://gist.github.com/31/302bab2630ddf8d90ab4aec0d358b538

[magian1127]

vs 2019 16.9.x
if use the above method, intelligent prompt inoperative

[piratesephiroth]

intelligent prompt

what's intelligent prompt?
Intellisense is working just fine in VS 16.9.2

[pjmavcom]

Trying the @31 workaround guide got me to this error:

Method not found: 'Void Mono.Debugging.Evaluation.ObjectValueAdaptor.set_DebuggerSession(Mono.Debugging.Client.DebuggerSession)'.

Any idea what I did wrong? Thanks!

[piratesephiroth]

Here's my tutorial:

Important: The VSMonoDebugger extension will prevent this one from from working.
Please disable or remove it before trying this workaround.

Get the snippet neikeq posted above and paste it into a new text file.
Now edit this "ProjectReference" block:

    <ProjectReference Include="..\MyGame.csproj">
      <Project>{5957a55d-a731-4684-85cb-0bf023e5d393}</Project>
      <Name>MyGame</Name>
      <Private>False</Private>
    </ProjectReference>

• Change the Include attribute, from "..\MyGame.csproj" to a relative path that points to your game's .csproj file.
  Just the file name is fine if you placed this stub project it in the same folder as he original project.
• The Project, Name amd Private elements aren't necessary, you can just delete those lines.

Now save the file as Stub.csproj or whatever.

Now open your project's solution file in Visual Studio.
Right click the solution in Solution Explorer and select "Add" -> "Existing Project", then select your new Stub project file.

Now right-click the Stub project in Solution Explorer and select "Set as Startup project".
(you can also do that from the solution's properties)
"Play in Editor" should be visible at this point.

[pjmavcom]

@piratesephiroth Thanks for the quick reply! Im still getting the same error. Wondering if I just messed it all up trying a few different things before coming to this? I followed this first.
https://docs.godotengine.org/en/stable/getting_started/scripting/c_sharp/c_sharp_basics.html#configuring-vs-2019-for-debugging
The GUID for the project is in the .sln file, Project section, the second set of numbers on the line with my project name right?
If that shouldn't mess it up, then is there something in Godot I'm not doing? I've got VS selected as the external editor. Haven't messed with the project settings.

[piratesephiroth]

You should get the GUID from your project file directly to avoid any mistakes.

[SantasLair]

In case anyone is interested, JetBrains Rider works GREAT with Godot mono out of the box. Of course, it isn't free. For me it is worth the cost.

[magian1127]

Excuse me for my poor English
Intellisense not working
delete StubProj.csproj Intellisense is working

my VS 16.9.2 not working
VS 16.7.x working

[pjmavcom]

You know what? I forgot to mention the main project .csproj file doesn't have a GUID in it:


net472
Platformer


The other projects I've made have them. I'm going to play around with it and see if I can figure out why, and see if that is the problem maybe.
As for Rider @mudbug-z, I have it and Visual Studio/Resharper both. I like VS just a bit more, some hotkey or something Rider doesn't have, I can't remember. But it's getting to the point where I will take just works over whatever I used to like more lol

Alright, last ditch effort, then I'll start asking about how to get Rider to work. LOL
I just started a brand new project in Godot. Empty. Made an object, attached a C# script. It created an .sln and .csproj, but the project file is as the last one. No GUID and just those 6 lines. Well, 5, doesn't have a namespace yet. I tried 3.3 rc7 mono in case mine wasn't new enough. Same outcome. Also tried setting this up with another project that had a full project file. Same error.

[xchellx]

This does not work anymore (unless you want to be restricted to .NET Standard 2.0) Project '..\MyGame.csproj' targets 'net6.0'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.7.2'.

[userqt]

Hello there, its 2022 and I am not able to see the Play in Editor button. Has this been fixed or we have to use some workarounds still? If yes, which one?

I am using visual studio 2022 and Godot 3.4.4 (Mono version (C# support)). Any help would be appreciated.

[Intrivus]

it is Godot 3.5 now and no fix for this :(

[Alriightyman]

@neikeq Just a question related to this bug, since .net6 was merged into Godot 4, will Godot 4 suffer from this bug as well or was work done to solve this issue without the above workaround?

[neikeq]

The root of the issue applies to Godot 4 as well. However, there are other challenges as well, like how to implement Play in Editor with the CoreCLR debugger.

Currently, the way to debug C# in Godot 4 with Visual Studio is as I explained here:

As for Windows and Visual Studio, you must add the following to your csproj (or a Directory.Build.props):

  <PropertyGroup>
    <StartAction>Program</StartAction>
    <StartProgram>C:\Path\To\Godot.exe</StartProgram>
    <StartArguments>--path C:\Path\To\Godot\Project\</StartArguments>
  </PropertyGroup>

[Alriightyman]

Ah, I see. I didn’t get that far in the conversation. So, in that case, the extension isn’t used then. Thanks for the info.

[Xyotic]

Found something new. Maybe we this could help to solve the sdk style problem...
https://docs.microsoft.com/en-us/visualstudio/ide/customize-build-and-debug-tasks-in-visual-studio?view=vs-2022

Maybe we could use a launch.vs.json to set the different debug targets.
And then we would need to communicate it back to the extension.

Mabe there are events for that?

[Xyotic]

Addendum:
Seems like "launchSettings.json" is the right thing to use...
In your project, create a folder named "Properties" and place the file inside.

This is how it looks:

Obviously, this doesn't do anything yet... But maybe we can use this somehow.

[GeorgeS2019]

@Xyotic Please see if you could implement using your suggestion to make VS2022 to use commands to

• Launch,
• play in editor and
• attach.

[Xyotic]

It works in combination with @neikeq 's way of starting Godot.
If you remove the "StartArguments" and move them into the "commandLineArgs" of the launchSettings.json file you can start your project with different arguments.

Looks like this:

{
  "profiles": {
    "Launch": {
      "commandName": "Project"
    },
    "PlayInEditor": {
      "commandName": "Project",
      "commandLineArgs": "--path [Path/to/godot/project]"
    }
  }
}

And in you .csproj:

<PropertyGroup>
	<StartAction>Program</StartAction>
	<StartProgram>[Path/to/Godot.exe]</StartProgram>
</PropertyGroup>

if you leave your commandLineArgs empty it just launches godot without a project.

Not sure if we can realize an "attach" functionality this way tho.

Edit: I think it should be possible that the extension creates the launchSettings.json and the entry in the .csproj for you

[GeorgeS2019]

This PR implements a way to define the Godot.exe path and execute it in a reliable way than the previous StubProj. All it needs is to deliver the parameters for different scenarios of debugging. neikeq has different messaging system to capture the standard and errors outputs for display in VS2022

I think the PR or the one before capture the godot project path

[Xyotic]

The code to define the .exe path could be used to create the .csproj entry.

But other than that I think these two approches are too different to be useful for eachother.

I didn't try if my solution works with breakpoints tho. Will do that later.
But according to this, it should work?

Currently, the way to debug C# in Godot 4 with Visual Studio is as I explained here:

[Xyotic]

Update:
Using "StartAction" + "StartProgram" in .csproj in combination with launchSettings.json do hit breakpoints in 4.0.

The next steps would be to check if the extension can interrupt startup and get information from the launchSettings. Maybe via environment variables... This way we could implement an "attach" launch profile.

[Xyotic]

I did some more digging and tried to make the Csp sample work @azbay mentioned.

Like @neikeq, it didn't build out of the box, but I managed to make it build.
Basically all you have to do is to update the nuget packages inside this sample project.
If you go with the preview packages (which are pretty current and just got some new updates), you'll also have to change the target framework of the sample to 4.7.2

Now It should build. The extension seems to load (it hits the breakpoint inside the CustomDebugger.cs constructor), but it doesnt add the new "CustomDebugger" Debug option to the Godot project...
I've also followed the instructions and did add the nuget to the godot project.

I think it has something todo with the nuget itself. Inside the "CpsExtension.Nuget.targets" the CpsExtensionDesignTimeTargetsPath uses a condition which cant be fullfilled. I tried to remove the condition but it also didnt show up the CustomDebugger...

Maybe someone else got more ideas?

[GeorgeS2019]

But other than that I think these two approaches are too different to be useful for each other.

Can you clarify are you relying on StubProj?
I could not figure out how the StubProj works by launching Godot.

However, the new CommandLine to launching Godot seems clear to follow.

What needs to be done is to connect the Godot VS2022 extension Messaging to receive the standard and error outputs of running an external command (e.g. Godot.exe). These are the information that help to communicate with VS2022 where are the error and what are the error messages.

[Xyotic]

@GeorgeS2019 I dont rely on StubProj.
This workaround does only work with .net framework projects as far as I'm aware. Which isnt going to work since we moved to .net6

[GeorgeS2019]

Is this well documented? There is an option which is not StubProj and the latest commandline?

Can u share the links I could follow this Third method?

[Xyotic]

Follow my findings I mentioned above.
Basically you only need to add this:

 <PropertyGroup>
    <StartAction>Program</StartAction>
    <StartProgram>C:\Path\To\Godot.exe</StartProgram>
    <StartArguments>--path C:\Path\To\Godot\Project\</StartArguments>
  </PropertyGroup>

to your .csproj and you can start debugging.
If you want to add the differen launch profiles you can setup the launchsettings.json.

But currently I'm more interested in getting the csp sample to work

[Logopher]

Improved with MSBuild properties (I defined GODOT_EXE as an environment variable):

  <PropertyGroup>
    <StartAction>Program</StartAction>
    <StartProgram>$(GODOT_EXE)</StartProgram>
    <StartArguments>--path "$(MSBuildProjectDirectory)"</StartArguments>
  </PropertyGroup>

[GeorgeS2019]

This should be closed...Godot 3.
Ask in disvord