Allow specifying C# class name instead of source file path as node's script #15661
Comments
|
Same as #7402 |
|
@Zylann Urg... you are right, it seems I somehow missed that one when I searched for a duplicate issue. Sorry, and you can safely close this issue. |
|
@Noshyaar Can we reopen this again please? From how the discussion went in #7402, it seems like we need to keep another issue open to discuss the matter specifically from the C#'s side. |
ghost
reopened this
|
Thanks :) |
|
Reopened since #7402 diverged into many different issues. |
|
Regarding assigning classes instead of files: The rationale of what was discussed is that, in my opinion, assigning classes rather than files as the common case makes usability worse. Most of the time when developing a game, you just create new files together with the class name, and only rarely you assign a script to a node (where it would make the most sense to assign classes to nodes/resources). For this reason, I am against a change like this. Regarding declaring a class that has a different name than the source file. I still don't understand why this is a limitation, would like @neikeq to explain better the rationaly for this. Referencing C# type from fully quaified name Does not C# have import ? I am not sure if I understand the limitations in regards of this. |
|
@reduz Thanks for continuing the discussion here. Unfortunately, I just stumbled upon a much more fundamental problem with the current way of resolving C# classes in Godot. It seems that Godot does not use qualified names for classes at all, completely ignoring any namespace information. I was trying to explain the problem of parsing qualified type names out of arbitrary file paths, especially when it involves referencing classes from 3rd party addons. But if namespace is not supported at all, I don't think there's any point in discussing it further before we can decide how to implement namespace support (i.e. just use qualified names in the first place / parse .cs file / parse .csproj files /etc). |
|
This issue is not very clear since you seem to include the problem which #17409 is supposed to cover. I'm gonna comment here regarding attaching a script with a class (that does not necessarily match the file name) to a node. I would like you to clarify first what exactly you need to be able to do though. Is this something required for libraries/frameworks? For what? Or is this just to allow specifying a different class in the file when attaching a script to a node in the editor? I wanna mention that we already support programmatically creating a |
|
Yeah, I admit I've caused some confusion by mentioning several different issues here. The main reason why I think it is better to use a fully qualified name to reference classes is it's more idiosyncratic C#'s way of managing dependencies. The confusion has arisen partly because I thought the reason Godot's trying to do it in its own way was simply an oversight or a side effect of trying to model C# support after that of GDScript. In that case, if we 'fix' this issue then it'd either make other issues mentioned here to be irrelevant or much easier to fix. I guess that was how the discussion became such a mess. Anyway, as it turns out that it was an intended design choice and the core developers seem to have a strong opinion (probably with some good technical reasons that I'm not aware of) for keeping it that way, I won't push it too far, as long as other issues can be fixed without changing it. I'll just reiterate my points of supporting this change here:
|
I'm not sure what you mean. What is not compatible with NuGet?
Last time I checked, Unity was still using files instead of fully qualified names to attach a MonoBehaviour to a GameObject. This was some time ago, so maybe things changed?
How exactly is it not compatible?
Like I said previously, technically this is already possible. The problem is how to let the user select a script this way without affecting the usability for selecting scripts from other languages. I've been thinking about the following solution. What if we make the script editor dialog allow to optionally specifying a fully qualified name rather than a file (if the selected language allows it)? It would be a built-in script, like built-in GDScripts, and it would simply contain the FQN. Would this be enough? I would like to know @reduz's opinion on this idea. |
In Godot, we are free to distribute our libraries as NuGet packages like any other C# projects, but as soon as we need to include Node derivatives which users assign to nodes in their project, it's no longer possible to rely on such a method as we'd also need actual source files for them. To me, having two separate ways of managing dependencies seems to be problematic, especially when the one we are using is not a common practice among other C# projects. There's an already a well established method of adding assembly references in C# projects, which is covered by many documentations, tutorials, and supported by IDEs and tools like NuGet. So, an exception like "you can do it like as any other C# projects do, except when you want to include Node type classes, in which case you need to distribute the whole project source bundle instead" feels quite adhoc and confusing to me.
I believe Unity just uses hashes for script assets internally, but at least on the surface it shows a UI that lists classes with FQNs in a hierarchical manner for users to choose a class to attach.
On a second thought, it seems that Cecil/Fody might not be a problem, as modified methods will be detected by Godot if it uses reflection to query the metadata. Source generation is a different matter but I agree it's not that significant a matter since users can just run the build process once and attach the generated sources to nodes.
My main concern was to provide a unified way of distributing and managing dependencies, but even if we decide to leave it as it is, I believe it'd be better to provide such a way to reference classes by FQNs. Unlike what @reduz mentioned in another thread about users very rarely need to assign a class to an existing node, my own experience with Unity differs on that aspect. There are a lot of 3rd party assets available in Unity, which work by letting users to select and attach components provided the asset to their own game objects. Even if we don't have that many addons right now, I can easily see how we'll see more framework or template type addons appear for Godot which will provide commonly used scripts for their uses to choose and assign to their own nodes, as we become more popular. And if we consider scripts contained in a Unity asset usually reside in such a path like So I believe what @neikeq suggested could be a good way to improve usability for our users in the long run, regardless of whether or not we are going to change the way we assign classes to nodes. |
|
FYI, Unity still doesn't see your script if its filename doesn't match class name ;) But it can differentiate two classes of the same name by the file hash (still all file based then). |
|
@Zylann Yeah, it's quite messy with many exception cases there. Unity even fails to recognize a script when it contains a static import statement, for instance :) |
The way Unity does it is very similar to how we do it in Godot, unless something changed. They assing a MonoBehaviour via files. I guess they then parse the file to find the FQN, which is what we are missing.
I don't understand what you mean by this now. |
|
I'm not sure if it was my lack of experience in C# or of my writing skills that makes it difficult for me to explain the problem clearly. But either way, please let me know if I'm wrong in any specific points. As you know, assemblies are the basic building blocks for all .NET applications and components, so managing dependencies in a typical C# project is normally done at the assembly(.dll) level, not by manually downloading the whole project and referencing individual source files. If I want to write an open source framework or a library in C#, I'd simply set up my CI to build and publish a NuGet package, which contains all the managed assembly dlls. If anyone wants to use my library, one would simply need to add the assembly name as a reference to one's So, if I want to make a Godot addon, I also want to follow such a standard workflow to publish it, and expect users to do the same to use it. But currently, such a workflow is only partially supported because if I want to let users to reference any node types defined in my addon within the editor, just providing a dll assembly wouldn't be enough. In that case, I need to tell them to download the whole project tree and extract it where they can navigate easily inside the editor, and instruct them to go to such and such directory to fine 'script' files. I don't have to clone the whole repository and deal with individual source files to use JSON.NET or Microsoft.Extensions.Logging, for examlple, and I don't have to manually track down what other components such libraries might depend on and do the same things for each of them, since the standard dependency management mechanism is well defined and supported by popular development tools. If I want to use .NET's configuration API in my project, all I need to do is add a reference to Microsoft.Extensions.Configuration.FileExtensions to the I don't have to search for the website, and download the project bundle, and figure out it also depends on 2.0+ version of Microsoft.Extensions.FileProviders which I also need to download and extract. Also, I don't need to know where exactly is the source file for FileConfigurationProvider.cs located, since I normally learn how to use such a library by looking at its API reference, not how its project source is structured. I can understand if there are some good technical reasons why we have such a requirement (other than it works for GDScript) in place, or it might not cause too much trouble for average users. But still, I would want to keep the development workflow in Godot as closely as the one acknowledged to be the standard or best practice for each binding languages if possible, rather than forcing every languages to conform to the Godot/GDScript way of doing things. |
|
I think the way to solve this for precompiled projects is not adding class
support to Godot, but instead to C#.
There can be a resource type like .csc (c# compiled) which, on disk,
contains internally a link to a dll library and a class name. Mono module
can load this type of resource as a script.
Then registering custom types works as always, no need to change anything.
…On Mar 10, 2018 22:35, "Xavier Cho" ***@***.***> wrote:
I don't understand what you mean by this now.
I'm not sure if it was my lack of expience in C# or of my writing skills
that makes it difficult for me to explain the problem clearly. But either
way, please let me know if I'm wrong in any specific points.
Assemblies are the basic building blocks for all .NET applications and
components, so managing dependencies in a typical C# project is normally
done at the assembly(.dll) level, not by manually downloading the whole
project and referencing individual source files.
If I want to write an open source framework or a library in C#, I'd simply
set up my CI to build and publish a NuGet package, which contains managed
assembly dlls.
If anyone wants to use my library, one would simply need to add the
assembly name as a reference to one's .csproj file and everything will be
ready.
So, if I want to make a Godot addon, I also want to follow such a standard
workflow to publish it, and expect users to do the same to use it.
But currently, such a workflow is only partially supported because if I
want to let users to reference any node types defined in my addon within
the editor, just providing a dll assembly wouldn't be enough.
In that case, I need to tell them to download the whole project tree and
extract it where they can navigate easily inside the editor, and instruct
them to go to such and such directory to fine 'script' files.
I don't have to clone the whole repository and deal with individual source
files to use *JSON.NET <http://JSON.NET>* or
*Microsoft.Extensions.Logging*, for examlple, and I don't have to
manually track down what other components such libraries might depend on
and do the same things for each of them, since the standard dependency
management mechanism is well defined and supported by popular development
tools.
If I want to use .NET's configuration API in my project, all I need to do
is add a reference to Microsoft.Extensions.Configuration.FileExtensions
to the .csproj and rebuild it.
I don't have to search for the website, and download the project bundle,
and figure out it also depends on 2.0+ version of Microsoft.Extensions.
FileProviders which I also need to download. Also, I don't need to know
where exactly is the source file for FileConfigurationProvider.cs
located, since I normally learn how to use such a library by looking at its
API reference, not how its project source is structured.
I can understand if there are some good technical reasons why we have such
a requirement (other than it works for GDScript) in place, or it might not
cause too much trouble for average users.
But still, I would want to keep the development workflow in Godot as
closely as the one acknowledged to be the standard or best practice for
each binding languages if possible, rather than forcing every languages to
conform to the Godot/GDScript way of doing things.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15661 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF-Z22HwaQv15vpVkMx1a9DKj_LjheuXks5tdH9TgaJpZM4RdNIw>
.
|
|
Aside from solving this by way of custom types, I'm a bit confused as to the purpose of If what they do is providing an information about what classes an assembly provides or what other assemblies (dlls) it might depend on, don't we already have everything we need? If I'm not mistaken, we already use In other words, we have most the things needed to make binary C# addons to work in Godot already, except that we just don't know what class name to pass to Actually, it was one of the reason why I initially thought it wouldn't be much of an issue to change it. |
|
.csc could be something like
library = "res://addon/mylib.dll"
class = "MyCustomType"
…On Mar 10, 2018 23:06, "Xavier Cho" ***@***.***> wrote:
Aside from solving this by way of custom types, I'm a bit confused as to
the purpose of .csc resources.
If what they do is providing an information about what classes an assembly
provides or what other assemblies (dlls) it might depend on, don't we
already have everything we need?
If I'm not mistaken, we already use MonoImage / MonoAssembly to resolve
class names to their actual class instances for the main project assembly.
In other words, we have most the things needed to make binary C# addons to
work in Godot already, except that we just don't know what class name to
pass to mono_class_from without parsing either the file path or source
itself.
Actually, it was one of the reason why I initially thought it wouldn't be
much of an issue to change it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15661 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF-Z2zpwellrUExflOXVmn6WpbPO1ahuks5tdIaYgaJpZM4RdNIw>
.
|
|
I was about to post a huge brick of text examinating the ability to index resources by human-writable identifier instead of file path... but I'll write the conclusion I ended up with, for the C# case: To be able to assign by FQN without relying on .csc, you need to load ALL scripts of the project first. Walk the whole filesystem and index all enclosing resources (here DLLs). That means the engine needs a special case for resource containers supporting FQN (which GDScripts don't need since they rely on the filesystem, unlike C#, though they have a related problem with inner classes), which brings us to a problem with referencing assets themselves. You would need to append the FQN to the path of the DLL, otherwise scenes and GDScript won't be able to load C# scripts. |
|
@reduz I assume it's a way to register custom node types defined in a managed assembly, then? @Zylann But doesn't Anyway, it seems like I'm the minority in thinking it'd be better to change this behavior, so I won't push my points further. I'm not still convinced about the reason why we shouldn't change it though, but I believe it'd be better to work on more important things if not enough number of people think this to be an issue. Before I go, I just like to say that I'm glad I have at least a chance to persuade those who have actual power to change the things in such a prolonged discussion here - it was not something I used to see when I used another commercial product. Thanks! |
|
Just going to chime in here to add some perspective from a C# developer of over 15 years (outside of game engines at least). If I were to write C# "scripting" support into a game engine now, I would do it this way (I've written something similar for a non game engine):
This is just the right way to do it, in my opinion. Simple. Very little custom project generation code to maintain. 100% full native .NET support without artificial limitations imposed by file based scripting. Full access to the entire .Net ecosystem. Third party developers can distribute Godot script libraries on NuGet. No copying .cs files from a zip you downloaded on github - if the developer posts an update to the library you can update that dependency's version and get it, super easy. In summary:
|
|
Would this be solvable with custom scheme support when loading resources? Edit: As JeroMiya says below, |
|
I would maybe use "clr" or "dotnetclr" instead of "mono" for the custom scheme name but otherwise this seems like a plausible. would be the fully qualified class name with namespace. |
|
A |
|
Forget what I just said. |
|
I thought about alternate resource path formats too when thinking about GUID identification for resources, and I thought this could just be a different way of specifying a resource locator. Each GUID would be associated with a path, which might vary if the file is moved, but that mapping allows to still load resources in the end because they are files. For C# classes, that means there would be a similar translation from class name to file. |
It can if you override edit: And yeah, I also think the editor will be the most interesting part. I'll try how it behaves with such a custom scheme today. |
|
Could we make the class reference a separate field from the current file path? Given that the primary benefit of this proposal is from adding the ability to reference scripts defined in prebuilt assemblies (perhaps from NuGet, perhaps with their own dependencies), maybe we just add the ability to do that and keep the current behavior the same for loose C# scripts in the project? |
|
Hrmpf, while using mono:// works fine at runtime, the editor doesn't work nicely with it when trying to edit such a script. To have editing capability for scripts addressed as mono://... the editor would probably need bigger changes. :-| p.s.: The bare minimum to get mono:// working is here: |
|
What do you mean? What exactly doesn't work well? |
All in all the assumed equivalence of |
|
Based on the issues brought up so far, it seems a hybrid solution might be the most effective. So, given these two use cases:
I feel use case 1 is already well covered by the current file based system, i.e. with res: paths. Can we support use case 2 without breaking use case 1 or refactoring a lot of its related code in the engine? I think so. First, let's just keep use case 1 the same as it is today. That is, for loose C# scripts in the project, continue referring to them by file paths and not class names. Node/script assignment should remain unchanged. For scenario 2, add support for dotnet://<Namespace.ClassName> (if assembly dependencies are handled at the project level, else include a path to the assembly too). For dotnet:// resources, just disable the edit script button. Presume that the script is part of a library (perhaps from a third party) for which the source is not available to edit. Instead of dragging a script file on to the node, have a search UI that lists any script classes from assemblies referenced at the project level. Picking a script from this list fills in the dotnet:// reference on the node. |
|
Going down that route will essentially create two entirely separate mono integrations in Godot, however. And you'd still need Editor enhancements for the class-assignment you mentioned. |
|
It seems globally named classes added in 3.1 could be an alternative starting point. The difference is, they would work for every kind of script, not just C#. If not, it would be nice for modules to be able to register custom resource addressing systems, so resource locators (i.e "mono://xxx" or "whatever://thing") can be mapped to files without having to modify the core for each particular type of resource. |
|
I looked into the global classes, but the problem - again - is that they are file based :-) |
|
@shartte unfortunately the resource==file mapping is assumed deep into Godot, even GDNative has to have pseudo-script files to map to the actual classes defined in libraries. But until that changes, that should not prevent class-based assignment as long as a file exists to match this design (could even be generated, in |
|
I'm not familiar with the details of extensibility functionality in various .NET IDEs (VS, VSCode, VSMac, Ryder) to know if they'd support "GoToDefinition(fullClassName)" from an external application. Plus, for third party dependencies, e.g. from NuGet, there is no source to open. That's why I suggested just disabling "Edit Script" functionality for any scripts that come from a "module", for whatever a module means in a given scripting system (.DLL assembly for .NET, something else for other languages). I suggested handling it as a separate .NET integration only because I thought it would be less disruptive than replacing the current integration with something that handled scripts from C# files and scripts from .NET assemblies in the same way. If that's not the case, then, by all means replace away. |
|
@Zylann It would certainly be possible to do "Assembly scanning" and generate such files in the .import folder. However, to enable things like |
|
Thought I would add some feedback - Sorry for the seemingly newby github account (It's my personal account) - But I've worked a number of mid to large size game studios in the last 15 years of my career. I've got about 6 years of development experience with Unity at Black Bird Interactive (we put out Homeworld: Deserts of Kharak and another internal project developed with Unity). I can say that Unity in fact DOES NOT use filenames to attach classes to game objects. They use a GUID keyed to the assembly qualified name. As far as I understand it, loose scripts are either compiled into a temporary dll or dynamically compiled during runtime... but they are compiled before use and the script/game object hooks are indeed the logical class, not the source. This means that if you define a unity game object in an external assembly, then drop that dll anywhere under the Assets/Code folder, it'll automatically load the dll and it's classes as available game object scripts. We in fact had paid for development support from Unity themselves and they confirmed that this method of importing assemblies was the preferred workflow. It worked well for build systems & various source control models. I'm currently doing some consultation work and I can say that this alone makes me want to move back to unity, which is a shame because a lot of the other features are very attractive in comparison. I think the issue is that using a file path to indicate a class declaration places a dependency on the projects code organization. By using filepaths, I no longer have the freedom to define classes or nodes under a companies guidelines and managing large scale projects where all the source is contained in 1 project is not a particularly scaleable solution. If I break the projects up, I may end up with extremely long path names and a lot of noise in terms of files that are likely not important to my task. As an alternative - using either roslyn or reflection to get nodes defined in all loaded assemblies and then presenting the available classes through the same window as the 'Inherits' selection would be ideal. As a constraint, you could also only show extended classes that are derived from existing Godot base types. I believe the reflection method would provide everything you need without adding anything to the existing project - but that is under the assumption that you have a c# runtime somewhere between the population of the window and the loading of the external assemblies. I hope this adds some perspective wrt knowing what could be influencing your users' decisions. |
|
Maybe this is the wrong proposal, but I think this proposal would also allow for generic nodes and resources, which are currently kinda broken. Example: Generic base class // Generic display
public class ItemDisplay<TItem> : Control
where TITem : Resource, IItem
{ ... }
// In a separate file, you have to declare each derived type explicitly, or exports of it will break.
public class PrimaryItemDisplay : ItemDisplay<PrimaryItem> {}... Etc. for each item type resulting in a bunch of 1-liner files. This is particularly annoying when working with Resources, as generics could really simplify certain data structures or layouts. I support the core dev's view that TRES files should be human-readable. I LOVE that you can currently write one by hand with very little issue. That said, it would be nice if certain cases could use a fully-qualified name, when a path will not do. I also get that generics don't make sense from the editor side. You can't drag in a generic script, because there's no way to know what types to specify. This makes generics nodes and resources only usable from code. A big limitation, but it would still be nice to have as an option. Note: Another solution to generics could be godotengine/godot-proposals#307 (so upvote that one if you like that solution more.) |
|
Any updates on this? |
Godot version:
master/ 30d7943OS/device including version:
Manjaro Linux 17.1-rc2
Issue description:
Currently, C# is treated in the same manner as GDScript, in that it is assumed the code would be reused in its source code form. However, it is not ideal for C# which is a compiled language and often used to create binary assemblies that can be reused in other programs.
With Godot, it is not possible to attach a C# class to a node directly (by specifying its fully qualified class name), but must be done by providing a path to the source file where the class is declared.
This is problematic, since C# allows declaring a class that has a different name from its source file, or even declaring multiple classes in a single source file.
More importantly, it makes creating a library or a framework that can be used in Godot very difficult, since it is impossible to reuse such a module in its binary form, as it is generally done by a normal C# project (by using NuGet, and etc.).
This limitation also prevents one from writing editor plugins, as described in #15237.
Ideally, users should be able to reference a C# type by its fully qualified name (including the namespace) and attach it to a node, as long as the assembly that contains the class is referenced by the main C# project which is associated with the current Godot project.
The text was updated successfully, but these errors were encountered: