Age | Commit message (Collapse) | Author |
|
Use script instance binding for objects constructed from C#
|
|
Windows: Default to system MSBuild and add VSCode hint path
|
|
|
|
Don't pass FrameworkPathOverride to MSBuild. It's causing issues with some nuget packages.
|
|
Do not initialize Mono if 'res://.mono/' and mscorlib are missing
|
|
This is the whole reason 'fill_search_dirs' was added for, yet somehow I forgot to pass the config parameter.
|
|
Only possible if the object class is a "native type". If the object class is a user class (that derives a "native type") then a script is needed.
Since CSharpLanguage does cleanup of script instance bindings when finished, cases like #25621 will no longer cause problems.
Fixed ~Object() trying to free script instance bindings after the language has already been removed, which would result in a NULL dereference.
|
|
Previously this was only done when building the script for running the game. This was a problem because the user could want to build the project manually with the "Build project" button, to then run the game from the command line or similar.
|
|
|
|
|
|
Add environment variable to specify a custom --debugger-agent for mono.
|
|
|
|
BaseIntermediateOutputPath seems to be empty by default. The workaround is to explicitly set it.
Also fixed passing char instead of char[] to String.Split. Why was this even working with Mono?
|
|
C# Bindings Generator: Fix vararg methods with custom return type
|
|
|
|
This would cause errors that shouldn't happen unless there was something to build.
|
|
This fixes the previously wrong PR
Because we don't actually ship 'debug' templates to users make sure
the mono exporter picks the correct 'data' directory for export
templates.
This fixes #24752
|
|
Because we don't actually ship 'debug' templates to users make sure
the mono exporter picks the correct 'data' directory for export
templates.
This fixes #24752
|
|
Add code-oss, vscode-oss, and visual-studio-code-oss to vscode path
|
|
|
|
Happy new year to the wonderful Godot community!
|
|
|
|
VSCode's executable name is not uniform and godot only search for "code".
|
|
C#: Improve tool script support and fix reloading issues
|
|
|
|
|
|
Add option for automatic project updating.
|
|
|
|
- Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project
- GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly
- This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
|
|
|
|
Previously it would fail if the type name included its namespace.
|
|
- Added a very simple parser that can extract the namespace and class name of a C# script.
|
|
- `modules\mono\csharp_script.cpp(576): warning C4099: 'CSharpScriptDepSort': type name first seen using 'class' now seen using 'struct'`
- `modules\mono\signal_awaiter_utils.cpp(144): warning C4003: not enough actual parameters for macro 'ERR_FAIL_V'`
- `modules\mono\editor\net_solution.cpp(101): warning C4129: '%': unrecognized character escape sequence`
- (several) `modules\mono\glue\cs_compressed.gen.h(222): warning C4129: 'E': unrecognized character escape sequence`
|
|
|
|
|
|
- Also make sure we load API assemblies from 'res://.mono/assemblies/'.
|
|
Make sure API assemblies are up to date at startup
|
|
- If there is a solution and C# project at startup, make sure API assemblies are up to date.
- Fix prebuilt assemblies only being used when building the game project, and not in other instances.
|
|
|
|
- We no longer box struct to return them from internal calls.
- Use reinterpret_cast if the managed struct layout is the same as the native struct.
|
|
|
|
|
|
- Fix unused bool local for MonoBoolean argument.
- Append U to API hashes. Fixes warning: 'integer constant is so large that it is unsigned'
|
|
Some of this code has been re-organized.
f
|
|
Mono: Editor and export template dependencies and fixes
|
|
- Bundle editor dependencies:
- 'GodotSharp': Root data directory for the editor
- 'Tools': Editor dependencies. Only GodotSharp.dll for now.
- 'Api': Prebuilt GodotSharp and GodotSharpEditor API assemblies.
- 'Mono': Mono files to bundle with the editor.
- 'bin': (Optional, not used for now) Mono bin directory.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- 'lib/mono/4.5': Framework assemblies.
- Added build option to copy the required files from the mono installation to 'GodotSharp/Mono'. Enable with 'copy_mono_root=yes'. Disabled by default.
- Export template dependencies:
- 'data_AppName'/'data_Godot':
- 'Mono': Mono files to bundle with the game.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- The data directory is generated when compiling and must be bundled with the export templates. In the case of OSX, the data directory must be placed inside the 'osx.zip' export template.
- In OSX, alternative location for directories (needed for app bundles) are:
- 'data_AppName/Mono/etc' --> '../Resources/GodotSharp/Mono/etc'
- 'data_AppName/Mono/lib' --> '../Frameworks/GodotSharp/Mono/lib'
- The editor can bundle prebuilt API assemblies.
- Generate them with a tools build by running: `--generate-cs-core-api <GodotSharp_OutputDir> --generate-cs-editor-api <GodotSharpEditor_OutputDir> <GodotSharp_OutputDir>/bin/Release/GodotSharp.dll` (This command will be simplified in the future and both projects will be in the same solution)
- Build the solutions and copy the output files to '#bin/GodotSharp/Api'.
- Fixed API assembly being added twice during the export process.
|
|
- thread_local.h: 'delegating constructors only available with -std=c++11 or -std=gnu++11'
- mono_reg_utils.cpp: 'extra tokens at end of #endif directive'
- mono_bottom_panel.cpp: '<fieldB> will be initialized after <fieldA> when initialized here'
- bindings_generator.cpp: 'name lookup of 'i' changed (...) matches this 'i' under ISO standard rules (...) matches this 'i' under old rules (...)'
|
|
- Also fixed uninitalized variable in buildscript
|
|
|
|
This allows more consistency in the manner we include core headers,
where previously there would be a mix of absolute, relative and
include path-dependent includes.
|