C#: Allow project source files to be separated into a sub project folder.

[Avantir-Chaosfire]

Describe the project you are working on

Small C# game

Describe the problem or limitation you are having in your project

C# project are all forced under the root project directory, making the directory messy, hard to distinguish what is Visual Studio and what is Godot. Would only become worse with multiple projects (is that even possible with the current setup?).

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Allow C# projects to exist in subdirectories of the Godot project directory.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

n/a

If this enhancement will not be used often, can it be worked around with a few lines of script?

Not necessary, just improves project organization.

Is there a reason why this should be core and not an add-on in the asset library?

It can't be an add-on. It is core. (Why do I have to answer these irrelevant template questions?)

Actual details:

Credit to godotengine/godot#28290

Currently all C# projects are forced to be in the root project folder meaning the default namespace will always be that folder and most code is put into sub folders. When that happens your src, code, project, scripts, etc... subfolder where you store your scripts and other source code now is forced to be added into the namespace path eg.: ProjectName.Scripts which ideally despite scripts not needing namespaces, you would want your scripts on the root namespace which is just ProjectName.

I was messing around with jetbrains console project and realized there's a feature that allows you to set this in the sln file. For instance:

Microsoft Visual Studio Solution File, Format Version 12.00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ConsoleApplication6", "ConsoleApplication6\ConsoleApplication6.csproj", "{D7E527AF-F5E5-45A0-AAE6-B4C46ED0347D}"
EndProject
Global
    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
        Release|Any CPU = Release|Any CPU
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {D7E527AF-F5E5-45A0-AAE6-B4C46ED0347D}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {D7E527AF-F5E5-45A0-AAE6-B4C46ED0347D}.Debug|Any CPU.Build.0 = Debug|Any CPU
        {D7E527AF-F5E5-45A0-AAE6-B4C46ED0347D}.Release|Any CPU.ActiveCfg = Release|Any CPU
        {D7E527AF-F5E5-45A0-AAE6-B4C46ED0347D}.Release|Any CPU.Build.0 = Release|Any CPU
    EndGlobalSection
EndGlobal

Now you could try manually editing this to your project sln, but building in editor complains if you move the .mono, .csproj to the sub folder.

Suggestion:

Allow c# projects to have a sub folder inside the project folder with the same name be the root of our project. This would make separating the c# much cleaner and organize the code base better.

Just a simple checkbox asking if the project source be in a subfolder ProjectName\ProjectName and when enabled the editor will look in that folder for the source as the root rather than the root project folder.

[Calinou]

Related to #1141, although this proposal has a smaller scope.

[GeorgeS2019]

@Avantir-Chaosfire we are discussing this topic within the GodotXUnit . The main branch with multiple c# projects => Addon c# csproj. Folder Test has additional c# csproj. Then there is the main c# csproj at the root directory. The hack branch attempts to have only one c# csproj. The solution is not optimal, at least there are people attempting to improve that at the GodotXunit issues.

[raulsntos]

Multiple C# projects are now supported in both 4.x and 3.x. A new setting has been introduced in 4.0 (dotnet/project/solution_directory) and 3.6 (mono/project/solution_directory) to allow specifying a custom path for the .sln, this setting should allow you to follow the recommended multi-project directory structure.

Here's an example of how a multi-project solution could look like:

MainFolder
├── ProjectName.sln
├── src
│ ├── ProjectName  (Godot project)
│ │ ├── ProjectName.csproj
│ │ ├── project.godot
│ ├── ProjectName.AnotherDotnetProject
│ │ ├── ProjectName.AnotherDotnetProject.csproj

Since this is already supported, I'll close this proposal as resolved.

[p10tr3k]

Multiple C# projects are now supported in both 4.x and 3.x.

Just trying to have multi-project solution and I don't think this is working. I can add new projects to solution, but if I add new cs class in editor the solution is recreated and all my changes in it are lost.

@raulsntos Could you show how to do it?

[ChadNedzlek]

I don't think the resolution matches the issues request. I want all the C# files in one folder, away from all the godot stuff (the scenes, the time maps, etc). The "solutio_directory" essentially only lets you move the solution "up" to parent directories. The csproj is still stuck living next to all the other godot stuff.

I'd really like to be able to put all the C# stuff in one directory inside the godot project (after all, it's useless outside of it), and have it be isolated from the rest of the stuff, something like

MainFolder
├── project.godot
├── ... other godot resources ...
├── scripts
| ├── ProjectName.sln
| ├── ProjectWithAllTheNodeScripts
| | ├── ProjectWithAllTheNodeScripts.csproj
| ├── HelperProject
| | ├── HelperProject.csproj

I played around with the setting, and I couldn't get anything like this (I really want the C# code to be isolated into a single directory that doesn't contain a bunch of other stuff under it).

Essentially what seems possible now is the inverse of what this issue what asking for. Instead of letting the source files being separated into a sub folder, the godot stuff is now required to be a sub folder of the solution?

[Delsin-Yu]

Multiple C# projects are now supported in both 4.x and 3.x. A new setting has been introduced in 4.0 (dotnet/project/solution_directory) and 3.6 (mono/project/solution_directory) to allow specifying a custom path for the .sln, this setting should allow you to follow the recommended multi-project directory structure.

Here's an example of how a multi-project solution could look like:

MainFolder
├── ProjectName.sln
├── src
│ ├── ProjectName  (Godot project)
│ │ ├── ProjectName.csproj
│ │ ├── project.godot
│ ├── ProjectName.AnotherDotnetProject
│ │ ├── ProjectName.AnotherDotnetProject.csproj

Since this is already supported, I'll close this proposal as resolved.

@raulsntos

This is not what this proposal was for, the proposal was talking about "having multiple c sharp sub-projects under one Godot project", NOT "having a mixed type of different c sharp projects (including Godot sharp) under one c sharp solution file".

If possible, please consider re-opening this issue as it is NOT RESOLVED or SUPPORTED.

[dreadicon]

Just chiming in here, while this is technically something that can be worked around, it is a colossal pain (cost us about a week of dev) if the project isn't planned or this unexpected limitation is not made known ahead of time.

Further, there seems to be some possible issues with Node and Resource objects defined outside the Godot Project folder, which is again counter to C#/.NET coding philosophy and practices.

We did in fact consider recompiling the .NET godot module over complying with the hard-coded path string, it was that bad. The best thing about Godot over Unity (besides license) is how un-opinionated it generally is, and supportive of conventional code practices. Code-first, as it were. This is opposite, tightly binding Godot's structure arbitrarily to a monolithic project, defined by a hard-coded and counter-intuitive Godot-csharp project co-location. It may be intuitive for those coming from godot script oriented development, but that's not who the csharp support is for, fundamentally.

It's a minor thing that would have saved us a ton of work. I understand if the issue of Node/Resources defined outside the primary CS project is more complex, but at least the fundamental structural issue should be resolved within the next release or so; there's just no reason not to, as it's just changing how a couple of files are found based on a user setting.

If interested as to why this was such a pain, first the fact that this was a hard requirement at all took a day or two to puzzle out; every CS platform I've ever worked with had no opinions about where in your greater project the code should be other than under the .sln. Once we figured that out, we had to sync up the team so that the whole project could be refactored (moved into a sub-folder as the project was in the git root folder) without trampling anyone's work, which took time for people to wrap things up, leaving some of us with little to do in the mean time. Finally, after being moved, a number of links, references, etc broke. After all was said and done, we lost a week of dev.