Extension Doesn't seem to be working in Godot 3.2.3RC4
Alriightyman opened this issue · 63 comments
OS/device including version:
Windows 10
Issue description:
- Installed Godot CSharp extension
- Create new project in Godot 3.2.3 RC4
- Add a Node into the Scene
- Attach new C# script.
- 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.
I'll have a look. The ProjectTypeGuid was moved to the Sdk. I hope Visual Studio can support that.
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.
I confirm this issue , Windows 3.2.3 RC 5
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.
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.
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?
But will it ever recover?
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.
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.
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
@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.
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?
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)
- created a new project in godot 3.2.3
- added a root scene
- attached a .cs file to it
- 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?
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.
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.
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:
vs 2019 16.9.x
if use the above method, intelligent prompt inoperative
intelligent prompt
what's intelligent prompt?
Intellisense is working just fine in VS 16.9.2
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!
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.
@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.
You should get the GUID from your project file directly to avoid any mistakes.
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.
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
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.
You know what? I forgot to mention the main project .csproj file doesn't have a GUID in it:
This is normal as of Godot 3.2.3+, since it uses the new project system. I didn't need any GUID in my ProjectReference for the workaround to work for me.
@31 Yeah I remember seeing that somewhere now. I'm going to get Rider setup, but I'll still try and figure out the VS thing if anyone's got any ideas about it.
OK, I just created a new project in Godot Mono v3.3.rc7 and Visual Studio 2019 v16.9.3.
It worked just fine.
The "Play in Editor" button became the default action as soon as I set the Stub project to Startup Project and everything functioned properly.
I updated the tutorial with info regarding the ProjectGUID.
I don't understand what's going wrong for your guys.
Are you sure you added a proper path to your actual project in the stub one?
What happens when you expand the project node in the Solution Explorer?
Do you see any warning icons?
If you select the "Stub" reference, can you see the path to your project's binary in its properties?
Pretty sure
I've tried in a separate directory as well, with the path as "../Platformer.csproj"
I'll try updating VS, I'm currently on 16.7.2. I did get Rider setup though. It works good so far.
Yeah, it worked here both next to the main project and in a subfolder.
Well, being Windows and Visual Studio, I was probably holding the mouse upside down when I installed it. Not a big deal for me since Rider works now. When I get around to doing fresh installs I'll try again, but it's probably some random config I didn't know I setup or something.
EDIT: Well Visual Studio updated finally and I get a different error:
I have installed the VSMonoDebugger extension. Anything else supposed to be installed?
I have installed the VSMonoDebugger extension. Anything else supposed to be installed?
Maybe it's that extension that is causing trouble then, because I don't have it installed.
The only mono-related extension I have installed is a fork of MonoHelper that I use to build some small unrelated projects.
Alright! That was it. This link: https://docs.godotengine.org/en/stable/getting_started/scripting/c_sharp/c_sharp_basics.html#configuring-vs-2019-for-debugging does not work with this fix. Uninstalled VSMonoDebugger and it started right up.
Thank you @piratesephiroth and @31!
Alright! That was it. This link: https://docs.godotengine.org/en/stable/getting_started/scripting/c_sharp/c_sharp_basics.html#configuring-vs-2019-for-debugging does not work with this fix. Uninstalled VSMonoDebugger and it started right up.
Thank you @piratesephiroth and @31!
Cool! I added that to my tutorial.
Hello, not sure if this is connected to this extension, but after doing what @piratesephiroth suggested I get this error upon pressing "play in editor":
Hello, not sure if this is connected to this extension, but after doing what @piratesephiroth suggested I get this error upon pressing "play in editor":
Yeah, that package is required by this extension. I'm not sure why it's missing though.
The Godot project itself doesn't require that.
What could be done in such a case then? I tried adding the package Clide.Windows 4.0.17 (couldn't find 4.0.16 in NuGet) both in the main project and the stub project but still cannot launch the debugging. :/
Hello,
I successfully managed to apply the workaround by following the steps described by @piratesephiroth, and using the play in editor to launch Godot works perfectly fine, but my issue is that as soon as I add the stub in the solution, the autocompletion stops functioning.
Is there anything specific to do in order to avoid breaking the completion?
I am using Godot 3.2.3 and visual studio 2019 version 16.9.4
Any help would be greatly appreciated!
I managed to get this extension to work with @31 workaround.
But I had to add a project reference to my main projects solution.
Otherwise the brakepoints didnt hit.
I dont know if its any useful but this is a way to determin if a project in your solution is a sdk style Godot project...
public int OnAfterOpenSolution(object pUnkReserved, int fNewSolution)
{
ThreadHelper.ThrowIfNotOnUIThread();
DTE2 dte2 = Package.GetGlobalService(typeof(DTE)) as DTE2;
var sol = dte2.Solution;
foreach (var proj in sol)
{
var project = proj as Project;
var kind = project.Kind;
var file = project.FileName;
if (kind != "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}")
{
//Not a C# Project
return 1;
}
XmlDocument doc = new XmlDocument();
doc.Load(file);
var element = doc.DocumentElement;
var sdkAttribute = doc.DocumentElement?.Attributes["Sdk"];
if (sdkAttribute.Value.StartsWith("Godot.NET.Sdk"))
{
//Is a Godot project - Do more stuff with it...
return 0;
}
}
return 1;
}Edit: This only works if [ProvideAutoLoad(UIContextGuids80.NoSolution, PackageAutoLoadFlags.BackgroundLoad)] Attribute is used. Else the extension wont even run
Exciting news, maybe.
To update the research that @31 did (over a year ago now, lol) there have been some potentially useful things I've found. I'm not experienced enough to figure out the details of implementing this in a way that won't drive me insane, but hopefully someone else is capable.
The most useful resource (probably, at least in the meantime) is this section of the CPS repo which seems to detail exactly what we need. Of course, the sample itself was last updated 3 years ago, so that might throw a wrench into the works.
The only other caveat is that they (I think) use a NuGet package as the qualifying parameter that makes the debug option show up, so I'm not certain if you could switch that to target the new SDK parameter in .csproj (or however else the Godot SDK project type manifests itself).
The full documentation for CPS is found here, which should help with any other issues that crop up, especially regarding the outdated-ness of the sample plugin.
More importantly, while I'm not sure of its compatibility with the existing plugin or the versions of .NET/Mono that Godot uses, Microsoft has basically abandoned CPS in favor of the .NET Project System which is built upon the former and definitely worth looking into, if nothing else.
I remember trying the CpsExtension sample without success (it either didn't compile or MEF threw exceptions due to missing stuff).
I might give it another try soon with the information here (it seems they added this page a few months ago): https://github.com/dotnet/project-system/blob/main/docs/launch-profiles.md
@neikeq could you share your progress/the things you already tried?
Maybe on a seperate branch, so the community could take a look on that issue as well and wont have to start from scratch.
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'.
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.
it is Godot 3.5 now and no fix for this :(
@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?
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 aDirectory.Build.props):<PropertyGroup> <StartAction>Program</StartAction> <StartProgram>C:\Path\To\Godot.exe</StartProgram> <StartArguments>--path C:\Path\To\Godot\Project\</StartArguments> </PropertyGroup>
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.
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?
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.
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
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
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:
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.
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?
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.
@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
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?
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
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>
This should be closed...Godot 3.
Ask in disvord