Dotnet: Allow passing custom build arguments

[monxa]

Describe the project you are working on

Multiple projects. In many I use fixed C# addons such as AssetPlacer.

Describe the problem or limitation you are having in your project

Build times are too slow if no change occurred. Simply using C# makes me wait for >= 1s every time I want to run the game.

Can be mitigated in the dotnet build template (Project.csproj) somewhat, but fastest build times can only be achieved when passing custom build arguments to dotnet such as --no-restore.

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

Allow users to pass custom arguments to the build process.

Add to ProjectSettings (advanced settings) for Mono-Builds: dotnet/build/custom_compiler_arguments dotnet/build/custom_publish_arguments

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

https://github.com/godotengine/godot/pull/93539

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

No.

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

For users like me, this would enhance the whole experience of iterative development with godot using C#. It generally allows for an enhanced user experience with no downsides (that I know of).

[AThousandShips]

Can be mitigated in the dotnet build template (Project.csproj) somewhat, but fastest build times can only be achieved when passing custom build arguments to dotnet such as --no-restore.

Are there any drawbacks to this option? Otherwise I'd say it's something to just add to the existing build instead of needing custom options

What other options would be useful to have that requires adding this feature?

[monxa]

Can be mitigated in the dotnet build template (Project.csproj) somewhat, but fastest build times can only be achieved when passing custom build arguments to dotnet such as --no-restore.

Are there any drawbacks to this option? Otherwise I'd say it's something to just add to the existing build instead of needing custom options

What other options would be useful to have that requires adding this feature?

If I understood @raulsntos correctly in a previous request of mine, changing the default build behavior to use --no-restore on successive builds could imply regression and confuse users. They mentioned this here: https://github.com/godotengine/godot/pull/93310#issuecomment-2179121133. Their argument is very convincing in my opinion.

Regarding other options: Users could alter the build process of dotnet from outside Godot. For example, they could override the path to dotnet, or use bash/powershell/cmd scripts to change dotnet's behavior without modifying Godot itself. However, this approach would be cumbersome and require a deep understanding of their system's architecture.

Other useful options that users can pass to dotnet build include:

• Setting the verbosity level of the build process output.
• Enabling or disabling debugging features.
• Configuring very custom setups specific to their development needs (not exhaustive).

The original idea is from @paulloz (see their comment here). Perhaps they can expand on this further?

[AThousandShips]

Then that makes sense, thank you for elaborating on the context!

[warent]

I also want this. And, something which may overlap, I would also like to pass custom preprocessor directives here as well.

My use case is that I would like a GODOT_SERVER preprocessor define to know at build time if this build is a dedicated_server. https://github.com/godotengine/godot/issues/94414

For example, one way to do this could be adding a new define here

<DefineConstants Condition=" '$(ExtraDefineConstants)' != '' ">$(DefineConstants);$(ExtraDefineConstants)</DefineConstants>

And then in my case I could do dotnet build -p:ExtraDefineConstants=GODOT_SERVER (idea came from here)

(Even more ideally there would be a fancy listbox UI for adding/removing these custom directives)

One important thing to note is that this feature proposal needs to support multiple run instances, for those of us who test with two or more instances (in my case: the game client; and the dedicated_server)

Notably, this issue seems to have come up at least once before as well! https://forum.godotengine.org/t/how-to-set-custom-preprocessor-flags-in-c-when-compiling-for-release/7844/

[floriansimon1]

@warent For the defines, the problems you'll get with that approach is that your text editor probably won't know about those defines. A solution to this is to put the scripting defines in the .csproj file itself.

I have a patch that implements what you suggested, except it's just a semicolon separated list of strings instead of a packed string array. I suppose this is a bit more convenient in a way because you can copy and paste from that field: https://github.com/godotengine/godot/pull/94939#issuecomment-2258029504

I plan on adding more features later on related to defines if my proposal is accepted, such as the additional and removal of flags in an existing .csproj without a full generation to prevent the loss of info in the project file when changing defines. Right now, I lose my referenced Nuget packages every time I change defines.

[floriansimon1]

@monxa I don't expect I can use your PR to add custom scripting defines my text editor will know about. Am I wrong here?

[monxa]

@monxa I don't expect I can use your PR to add custom scripting defines my text editor will know about. Am I wrong here?

Correct. If you want an external editor to know about the build arguments, this issue might be unrelated.

The PR mentioned in this issue enables you to specify/overwrite build arguments, not definitions as the ones you define in the .csproj. You should be able to read custom definitions in the build process tho (https://github.com/godotengine/godot-proposals/issues/10028#issuecomment-2231550625).

@warent did you test this?

I have taken a sneak peak at the other PR and it indeed seems to go into a completely different direction. Does the pr also allow custom build arguments other than constants?

[floriansimon1]

Does the pr also allow custom build arguments other than constants? No!