Expose properties defined in C# script component classes to Blueprints

[enlight]

This will work similarly to the C++ code, public properties marked by a yet to be implemented UPROPERTY attribute should be accessible via Blueprints.

[Algorithman]

Hi enlight

Do you have any good references about the compilation process inside the editor? (for example is UBT used to compile it? Can i call own tools as prebuild/postbuild?)

I have a idea how to solve this, but i lack the knowledge how the compilation is done by UE4.

Another question: Why did you use plain c++ for the Klawr.ClrHost.Native, wouldnt it be easier to use c++/CLI for the wrapper?

[enlight]

Do you have any good references about the compilation process inside the editor? (for example is UBT used to compile it? Can i call own tools as prebuild/postbuild?)

Do you mean the native code compilation and reloading Epic does? Then no, I don't know much about it, and I'm not sure there are any docs on the topic. I seem to recall a pull request or two to make it easier for plugins to hook into the build process, but that was a long time ago now, and things make have change significantly since then.

As for your last question, Klawr.ClrHost.Native has to be native because it boostraps the CLR, the auto-generated wrappers in the Klawr.UnrealEngine assembly could be written in C++/CLI, here's an excerpt from my notes on the subject:

C# wrappers vs C++/CLI wrappers

The Klawr.UnrealEngine wrapper assembly could just as easily be written using C++/CLI, which could in theory be more performant than the C# wrappers currently being generated. The downside of C++/CLI is that it requires more explicit marshaling code, though the fact the marshaling code is explicit is also an advantage to some extent as it's much easier to see what's really going on during the native/managed transitions. The extra code isn't too big a deal since I don't need to write it by hand, just need to change the code generator. As it stands it's not a big deal right now, it won't really add anything I can't already do with the C# wrappers.

There a couple of other considerations I can think of though, C++/CLI is ugly (IMHO), only Visual Studio supports it (AFAIK), but only as a second class citizen. I also didn't want Klawr to be forever limited to the MS runtime, yes, right now the bootstrapping is done via COM which means that Klawr only works on Windows. However, I was hoping it would be possible to implement a Mono bootstrapper and build the wrappers with any C++/C# compiler on your platform of choice. This was before Microsoft decided to open source .NET, now I'm just hoping that in the future Microsoft or some enterprising hacker come up with a cross-platform CLR hosting interface to replace the COM one, and Mono finally becomes irrelevant.

[Algorithman]

Thanks for the answers. Clarifies it a bit.
My plans now are to create a c++ class (like any other c++ BP classes) which has the properties and functions of the c# dll built in. And from there we would've no problems to access the functions and properties, even from BP's. So the c# class would be accompanied by a c++ class as BP interface.

I dont know, but i think it is quite hard (if not impossible) to create a COM interface dynamically at runtime, so i rely on one-time Reflection after c# compilation.
Have to look through your code-generater again : )

[enlight]

My plans now are to create a c++ class (like any other c++ BP classes) which has the properties and functions of the c# dll built in. And from there we would've no problems to access the functions and properties, even from BP's. So the c# class would be accompanied by a c++ class as BP interface.

I haven't actually thought of doing it that way before, but it sounds feasible if hot-reloading works reliably. The generated C++ classes would have to go into a separate plugin though, KlawrRuntimePlugin can't be reloaded after it bootstraps the CLR as the CLR itself can't be restarted within the same process.

My original idea was to generate a UClass instance (more precisely a UKlawrBlueprintGeneratedClass instance) from the C# class, probably in here. So the Klawr Blueprint compiler will add a property/method to the UKlawrBlueprintGeneratedClass for each property/method in the C# class that was marked as a UPROPERTY/UFUNCTION. To do so it would generate a new Blueprint graph that calls a native function that forwards all the arguments to the corresponding method on the C# class... or something like that.

I dont know, but i think it is quite hard (if not impossible) to create a COM interface dynamically at runtime, so i rely on one-time Reflection after c# compilation.

Yeah, COM is currently only used for bootstrapping and I'd prefer to keep it that way.

[Algorithman]

A downside to my approach is, a simple
(c++)
UPROPERTY(...)
int32 test;
wont work well.
Because i have no getter/setter, i can't pipe it to the c# side. Did some reading yesterday, but didnt find a transparent way to apply getter/setter to a variable like c#'s auto properties.

As for the UKlawrBlueprintGeneratedClass.h, i seen it. And it can be a descendent of UKlawrBlueprintGeneratedClass. Doesnt matter if i define the interface to the c# class inside a UClass, AActor or whereever, just need a place for it. UKBPGC is a good place tho :)

As for hot reload, i think it depends on the compiler class settings. Stumbled over a few constructors which mentioned EKismetCompileType::Cpp (in Blueprint.h for example) which is also passed in to the FBlueprintCompiler. KismetCompiler should take care or reloading the dll after compilation i think. Didnt find a place yet for file change detection/reporting to tell the editor it has to be rebuilt.