Update exporting_pcks.rst

[Heremeus]

Updating C# assembly loading instructions according to godotengine/godot#75352 (comment). Simply loading the assembly is no longer enough with godot 4 and @granitrocky identified how to load the dlls correctly.

Wasn't sure how to properly format the code inside the note block, so please suggest improvements, if necessary.

[raulsntos]

The LookupScriptsInAssembly method (as most everything else in the Godot.Bridge namespace) is not meant to be used by users, if this API is exposed it's only because it's used by our source generators but otherwise it'd be internal API.

So I don't feel comfortable telling users to use this API. At least not without the proper explanation of what's happening.

Also, the plan was to make the type ScriptManagerBridge internal and replace the LookupScriptsInAssembly method with source generators (ScriptRegistrarGenerator), so it'd be better if users didn't start relying on this API since we'll likely break compatibility here.

[raulsntos]

This should work for multi-line code:

Suggested change

	``var context = AssemblyLoadContext.GetLoadContext(typeof(Godot.Bridge.ScriptManagerBridge).Assembly); var assembly = context.LoadFromAssemblyPath("mod.dll"); Godot.Bridge.ScriptManagerBridge.LookupScriptsInAssembly(assembly);``
	.. code-block:: csharp
	var context = Assembly.LoadContext.GetLoadContext(typeof(Godot.Bridge.ScriptManagerBridge).Assembly);
	var assembly = context.LoadFromAssemblyPath("mod.dll");
	Godot.Bridge.ScriptManagerBridge.LookupScriptsInAssembly(assembly);

[granitrocky]

@raulsntos That was a genuine concern of mine since there is a comment in the ScriptManagerBridge saying that the LookupScriptsInAssembly method is planned to go private. An alternative could be setting up an AssemblyLoad callback that calls it internally. Although if it's planned to be replaced with generators, we will need to consider mod support.

Somehow the Scripts in the imported dll need to be associated with the dictionary that tracks them. Maybe in that callback I mentioned?

[Heremeus]

The LookupScriptsInAssembly method (as most everything else in the Godot.Bridge namespace) is not meant to be used by users, if this API is exposed it's only because it's used by our source generators but otherwise it'd be internal API.

So I don't feel comfortable telling users to use this API. At least not without the proper explanation of what's happening.

Also, the plan was to make the type ScriptManagerBridge internal and replace the LookupScriptsInAssembly method with source generators (ScriptRegistrarGenerator), so it'd be better if users didn't start relying on this API since we'll likely break compatibility here.

That's totally fair, thanks for the insight! Feel free to close this issue and notify other users on the original issue. If I understood it correctly, the assembly workflow will be reworked in a future version which should fix the issue?

[Carsillas]

The LookupScriptsInAssembly method (as most everything else in the Godot.Bridge namespace) is not meant to be used by users, if this API is exposed it's only because it's used by our source generators but otherwise it'd be internal API.

So I don't feel comfortable telling users to use this API. At least not without the proper explanation of what's happening.

Also, the plan was to make the type ScriptManagerBridge internal and replace the LookupScriptsInAssembly method with source generators (ScriptRegistrarGenerator), so it'd be better if users didn't start relying on this API since we'll likely break compatibility here.

I hope it is prioritized that the original issue is resolved prior to making this breaking change, I intend on using this in the meantime and would like to not be completely blocked from keeping my engine up to date.

[haltingstate]

What is the method now, to load scripts that are in runtime loadable assemblies, or to load scripts that are outside of the Godot project folder?