Hi! I just started using Godot yesterday, and so far my migration from Unity is going surprisingly smoothly.

However, I had a question related to C# in the Godot engine. My code is designed in a modular manner, and I like to make extensive use of assembly definitions and the internal keyword to do things like hiding helper classes and methods. It helps to keep things tidy and organized.

I've noticed that Godot seems to put all my C# scripts in one big assembly upon building. This isn't the worst thing in the world, since I organize my scripts into namespaces, but I'd prefer to split things off into their own assemblies, if possible. Is this something that can be done in Godot, and if so, does anyone know how I would accomplish this?

    I don't think Godot has a built-in method for generating assemblies as Unity does. You would probably need to generate the .dll files yourself using MSVC. After that they can be drag&dropped into the Godot project folder. However, these libraries would not automatically have access to the Godot engine interface. For that, you would need to include godot-cpp in your C# dll project.

    Hopefully someone can correct me and say there's an easier way, but that is the only way I know of.

    Thanks for the answer!

    In that case, I'll just file this one away as "something to look into later maybe", and move on for now.

    2 months later

    @David_J

    I am in the exact same situation - turns out you can use Git Submodules to achieve this functionality. I know some people recommend against Submodules due to their complexity but maybe they will be helpful for you!

    David_J I'd prefer to split things off into their own assemblies, if possible.

    Possible? Yes. Really needed? Not so much.
    In Unity this was mostly done because of performance iirc (recompile, domain reload). In Godot this isn't a big issue.

    I think you should be able to create libraries directly inside the Godot solution, which you could reference. Each library would get compiled into its own .DLL then.
    Alternatively you could create an external .NET library project and add GodotSharp.dll as dependency - that way you have access to the Godot API from within that external library. You'd have to add the produced .dll file(s) as dependency to your Godot C# project. This takes a a bit effort to set up but can be fully automated then. How useful this solution is for your workflow also depends on your IDE.

    I don't think this is documented anywhere yet, but anyone a bit familiar with MSBuild/C# project setups should be able to make it work.

        5 days later

        Armynator
        The primary reason I'd like to do this is because I like to hide certain fields and classes with the internal keyword (from scripts that aren't in the same module). I'm not super concerned about the performance side of things, since Godot seems to compile considerably quicker than Unity from what I've seen so far.

        Again, missing this feature is not the biggest deal in the world, it's more a coding preference of mine.

        Regardless, I'll take a look at creating libraries in the solution and see what I can dig up.

          Maybe a good compromise without too much overhead would be utilizing namespaces. They won't prevent you from accessing their members, but they'll help keep you from accessing their members on accident. When you want to communicate between namespaces, you can use using directives to make it explicit what you are bringing into your scope. https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/namespaces#1452-using-alias-directives

            a year later

            award
            By splitting the project into assemblies, we can prevent incorrect dependencies between classes.
            This is very useful when there are many classes.
            Namespaces cannot stop us from making mistakes.
            If I understand correctly, Godot does not have built-in support for modularity?

              a month later

              I recently looked into this again after not bothering with it for a while. For anyone who wants to do something similar: I ended up compiling my C# modules into separate DLLs using VisualStudio, and then adding those DLLs as dependencies in my C# solution. This works - mostly.

              When the scripts are built, Godot copies referenced DLLs into the same folder as the GodotSharp DLL, so modules with a dependency on GodotSharp will work as expected. The main issue is that Godot throws the "Failed to export C# project" error message upon exporting the game - however, the build still succeeds. The pack file and .exe are created as normal, and DLLs are copied over correctly. I haven't found any issues yet in exported builds using this workflow, so I'm hopeful that it's just some engine jank.

              It's not ideal, but it gives me the control and modularity that I was looking for.