Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple .NET5 SDK-style projects per Godot project #1141

Closed
GeorgeS2019 opened this issue Jun 29, 2020 · 11 comments
Closed

Support multiple .NET5 SDK-style projects per Godot project #1141

GeorgeS2019 opened this issue Jun 29, 2020 · 11 comments

Comments

@GeorgeS2019
Copy link

GeorgeS2019 commented Jun 29, 2020

Describe the project you are working on:
As project complexity increases, it may be necessary to have a simpler and intuitive way to organize Csharp scripts into multiple projects.

Describe the problem or limitation you are having in your project:
Currently it is not trivial to create separate csharp project as either an additional Csharp library or for unit/integration testing, within a godot project.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Migrate the current legacy csproj to the new .NET5 Sdk style csproj format which make tracking which csharp files are associated with which csproj project simpler. However, the aim of the proposal is to go ONE step further on HOW to organize these SDK style projects within a single Godot Project.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Allow one single Visual Studio Solution .sln file to support multiple the SDK style csproj projects with each on a separate csharp directory under a e.g. root Script directory.

The .sln file needs to be at the root level so it is possible to use continuous testing and delivery using Azure DevOps (Online or Server)

If this enhancement will not be used often, can it be worked around with a few lines of script?:
No, we need this to allow Godot to support more complex and scalable project

Is there a reason why this should be core and not an add-on in the asset library?:
This involves the .sln solution file at the Godot Project root

REF: The current proposal requests the migration to the .NET5 SDK style csproj. However the current proposal suggests how to organize Multiple SDK style projects per Godot Project to allow Godot project Csharp/mono project to scale in complexity

@aaronfranke aaronfranke added this to the 4.1 milestone Jul 1, 2020
@Calinou Calinou changed the title Support multiple .NET5 SDK style projects per godot project Support multiple .NET5 SDK-style projects per Godot project Jul 3, 2020
@GeorgeS2019
Copy link
Author

GeorgeS2019 commented Aug 21, 2020

@Calinou and @aaronfranke With the latest[ SDK style and .NET standard 2.1 support] (godotengine/godot#41408) in Godot 3.2.3.rc.4.

We may not need to wait for milestone 4.1 to realize this feature.

The most important question is to get user feedback and consensus on the benefits of supporting multiple .NET SDK-style projects. ==> how will this make Godot Csharp Game development MORE attractive and intuitive in supporting more complex projects in scalable way. How this will help to differentiate Godot Csharp development environment from others e.g. Unity and STRIDE (which will come very close to the implementation of the .NET 5 features e.g. .NET Standards 2.1 is supported some weeks ago).

Most of the bottlenecks (I have seen in the @neikeq codes prior to the Godot 3.2.3 RC 4) needed to implement this proposal have been addressed in Godot 3.2.3.rc.4.

Supporting multiple SDK-style projects is simply creating new SDK-style projects in a "community agree e.g. .csharp folder" and the GodotCsharpProject.sln at root folder reference all these SDK-style projects in the e.g. .csharp folder in a consistent way. In other words, the solution to this proposal is simply files creation, saving, manipulation.

However the community needs to agree WHAT BEST to name the folder for all SDK-style projects (e.g. .csharp).

@aaronfranke
Copy link
Member

@GeorgeS2019 The issue is less of us needing to wait, and more of the fact that this is a very low priority issue. If @neikeq happens to work on this earlier, that's cool, but we don't need to plan for it being done soon.

@neikeq
Copy link

neikeq commented Aug 21, 2020

This is unlikely to be done in 3.x. I do want to support this in 4.0 though.
I don't want it to follow a strict convention that enforces you were to place projects and I don't think that's necessary either.

The main problems I can think of right now that we will need to solve are:

  • At startup Godot checks that the C# projects are using the correct version of the Godot.NET.Sdk and updates them otherwise. As such Godot has to know where those projects are located. We could do this by parsing the solution file. It's an obscure format but I think Microsoft.Build has a class for this.
  • What should Godot do about C# files that are created outside a C# project sub-directory (are not part of any project)? What if that C# file is attached as a script to an Object? What if a C# file is part of a C# project that does not use the Godot.NET.Sdk (not all C# projects will be assumed to use the Godot API) and then is attached as a script to an Object?

@neikeq
Copy link

neikeq commented Aug 21, 2020

BTW the reason it's unlikely this will be done in 3.x is because in 4.0 Godot no longer takes care of adding files to the csproj. Godot 3.2.3 will still take care of that if EnableDefaultCompileItems is set to false in the csproj, to avoid breaking things. This complicates things as Godot would have to figure out what project to add it to.
The other reason is that such a change may likely break forward compatibility again and I don't want to do that again.

@GeorgeS2019
Copy link
Author

@neikeq Thanks for taking time to share your thought process. Again, each time I gain new insights into the milestones you plan.

BTW the reason it's unlikely this will be done in 3.x is because in 4.0 Godot no longer takes care of adding files to the csproj. Godot 3.2.3 will still take care of that if EnableDefaultCompileItems is set to false in the csproj, to avoid breaking things. This complicates things as Godot would have to figure out what project to add it to.

The .NET5 Sdk style makes it unnecessary for Godot to keep track and add files to the .csproj. More elaboration follows below.

I agree, it is not an easy task to transition from the legacy to the new .NET5 sdk style .csproj format. I believe once the users understand the benefits (e.g. more scalable c# project etc.), many will adopt and make the transition. Most c# developers should by now comfortable with the new .csproj format.

What should Godot do about C# files that are created outside a C# project sub-directory (are not part of any project)? What if that C# file is attached as a script to an Object?

If I understand correctly, the reason behind the simplicity of the .NET5 SDK style csproj project is that it will replace the current Godot c# files searching and tracking. As a preliminary suggestion, we may need to set a new guideline that all C# files must be placed within the e.g. .csharp folder with folder hierarchy reflective of the scene node hierarchy. This will maximize the leverage of the new sdk style project, doing all the c# file tracking WITHOUT including them into the .csproj project file - making debugging simpler.

What if a C# file is part of a C# project that does not use the Godot.NET.Sdk (not all C# projects will be assumed to use the Godot API) and then is attached as a script to an Object?

I have yet to figure out if it is possible to mix the Godot.NET.Sdk and the standard SDK attribute. I assume both can be independent. I need time to experiment with that.

If both can be independent. I believe this is where the community will further benefit from the latest SDK style project you have implemented.

@Clonkex
Copy link

Clonkex commented May 30, 2023

I'm working on a game using Bepu Physics as my physics engine (because Godot's own physics system doesn't offer enough control). I'd love to have the Bepu Physics wrapper C# project exist separately to my main game, so I can have a testing/development Godot project and then just link the Bepu C# project back to the main game project.

Currently I have to copy-paste C# source files from the testing Godot project to the main game project every time I make changes, which is super tedious and error-prone. Is that something this proposal would help with? I'm not familiar enough with C# projects and solutions to know what's allowed and what's not.

@GeorgeS2019
Copy link
Author

GeorgeS2019 commented May 30, 2023

@Clonkex Try Godot4 .NET6 with SDK style project

See nested SDK style project
https://github.com/fledware/GodotXUnit/tree/master/addons/GodotXUnit/GodotXUnitApi

@GeorgeS2019
Copy link
Author

@Calinou I think this is solved?

@Clonkex
Copy link

Clonkex commented May 30, 2023

Huh, I'm already using Godot 4 with what appears to be the same type of project as in your example (I have no idea what the other types of project would look like though). It does appear to work just referencing the csproj file directly within the main game project. VS doesn't offer to link directly to csproj files from the GUI so I assumed it wasn't something you could do. Sigh.

The only issue now is that my nodes need to have scripts from this external project set on them, but the external project isn't inside the game's folder so I can't see the scripts. Maybe I can symlink it and exclude from the game's C# project? Hmm.

Thanks for the pointer though! I'm closer than I was before.

@GeorgeS2019
Copy link
Author

my nodes need to have scripts from this external project

U can add reference to project.csproj outside the Game folder.

@Clonkex
Copy link

Clonkex commented May 31, 2023

A reference? In what? In the main csproj file? I did that, but the files aren't showing up in the Godot editor for me to set them as scripts on nodes.

@YuriSizov YuriSizov removed this from the 4.x milestone Dec 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants