Move project source to a subdirectory when creating a new C# project

[naturalarch3r]

Describe the project you are working on

I have been working on an unreleased an unannounced 3D game since ~2018.

Describe the problem or limitation you are having in your project

Godot Default C# Solution Structure is Flawed

Summary

The .csproj file for the game project is created at the same level as the .sln file, meaning by default creating any other projects through IDEs such as rider or even through the command line will cause builds to fail. It requires moving the generated .csproj file to a subdirectory to fix builds.

Admittedly, this is will mostly only be an issue for those familiar with C#, but not paying very close attention to where the .csproj file is.

Why The Issue?

With Godot being so highly desirable for beginners, and having a huge proportion of its users new to programming or new to C#, having the default folder/directory structure permit adding additional projects seems to be the best idea. If users don't know they need to move the .csproj, it will be extremely frustrating and very time consuming to discover the solution without help for these newcomers.

By default, when generating a C# solution, godot will generate a .sln file and .csproj file. The problem is that the .csproj file is generated in the same scope (same directory) as the .sln file. While this works for a solution containing only one project, you cannot guarantee that this is desirable for users. When using C#, a common method of development is test-driven development. Even outside of test-driven development, unit testing may at times be desirable. While it is possible to test using Godot, this requires creating test scenes, and test nodes with an exported property to provide a "do test" button, or something similarly cumbersome. A user may desire to use a proper unit testing package such as NUnit or xUnit.

By generating the .csproj file for the game's project at the same level as the .sln file, this causes any subsequently created projects such as a unit testing project or source generator to be inside the game's project. This causes builds to fail, as it will see the files of the second project twice. The build fail errors are very misleading and cryptic, as it will both say that it fails to see dependencies (if it is only a dependency for the other project(s) and not the game project) and will also cause it to see "duplicates" of assemblies, attributes, etc. due to the compiler seeing the other projects twice despite there only being one of them! There are no actual duplicates, but without moving the .csproj file, as is the state of the filestructure here, it will cause building to fail.

Easy Fix

While there is definitely some debate to be had over what to name the default directory for the primary project, I personally suggest naming it after the game project. By creating this subdirectory, then generating the .sln where it is now but the .csproj in its own project subdirectory, creating new projects would not cause confusing errors on compilation.

Current Default Structure

. ├──Solution.sln └──GameProject.csproj

Proposed Default Structure

. ├──Solution.sln └──GameProject-Source ....└── GameProject.csproj

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

While there is definitely some debate to be had over what to name the default directory for the primary project, I personally suggest naming it after the game project. By creating this subdirectory, then generating the .sln where it is now but the .csproj in its own project subdirectory, creating new projects would not cause confusing errors on compilation. I think that this should be trivial to implement.

With Godot being so highly desirable for beginners, and having a huge proportion of its users new to programming or new to C#, having the default folder/directory structure permit adding additional projects seems to be the best idea. With an influx of experienced C# developers for ermm... reasons.... It stands to reason that it is likely that at some point tutorials or a devlog series will feature a second project in the solution like for unit testing. If users don't know they need to move the .csproj, it will be extremely frustrating and very time consuming to discover the solution without help for these newcomers.

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

Simply generate a subdirectory with the name of the project, possibly affixed with something like "project" or "csharp-project" or "source"/"src", then generate the .csproj in that subdirectory rather than the top level Godot project directory.

See Proposed Default Structure.

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

This enhancement will benefit everyone using C#, and help reduce friction with the engine for new users. A script on the users end would both be overkill and require they know they need to move the .csproj file in the first place. The process would also require adjusting the .sln file to account for the move of the .csproj, which would be beyond what most beginners know how to do. A script or plugin is not a good solution to this problem.

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

See above.

[Calinou]

The downside of this approach is that it requires relocating all the project files, which makes for a painful migration in existing projects (which isn't required but goes in the spirit of this proposal). It would also be inconsistent with projects that use GDScript, and also for projects that end up adopting C# after being initially developed with GDScript only.

The .csproj file for the game project is created at the same level as the .sln file, meaning by default creating any other projects through IDEs such as rider or even through the command line will cause builds to fail.

Shouldn't it be the responsibility of these tools to default to the .sln file if it exists at the same level, or ask the user about it?

[naturalarch3r]

Ah, yeah, you're right. I was a bit tired writing this up. You've definitely made good points. I do feel that it should be the responsibility of these tools to provide at least a warning that creating the project will place that project inside another project. Given the drawbacks, I feel that this really isn't such a great idea after all. I do appreciate you taking the time to read through this and give it some thought though. As an alternative, maybe there could be a brief snippet in documentation that is searchable on the docs site about needing to migrate the project files if wanting to use unit testing. Something brief and simple. It wouldn't even need to go into any detail about unit testing itself or even how to create a second project.

In: https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/c_sharp_basics.html#project-setup-and-workflow Maybe have another info bubble with a brief mention of this edge case scenario, or something along those lines. It could say something like "Some users may desire to create additional projects in the solution for a variety of reasons. Note that in this case, you may need to migrate the project files including the .csproj generated to a subdirectory to avoid potential problems with the compiler."

I do think that it would be a good idea to do something to help people with this issue, but I'm not really all that married to migrating the files. Next time, I'll definitely think things through more before opening a proposal. Thanks again for taking the time to write a reply!

Edit: if this is also undesirable, I'll see about writing a short blog post on the topic myself on my site in hopes to help anyone searching for answers.

[naturalarch3r]

After extensively testing multi project solutions with Godot, I have encountered many caveats to using a Godot project this way. With the current state of things I think it is best to close the proposal. I may well write on this in my own blog, as the way of going about this is not how most users would think to. I discovered that calling any Godot methods from the other assemblies (like the unit test) will almost always segfault (as one should expect from such a scenario...). As such, I do not recommend anyone do this unless you can 100% avoid calling the Godot API. I'll leave this open for now if anyone has any final comments before closure.

[nongvantinh]

I need this feature as well. My project will require a source generator, and using this approach is the best option available.