Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to CoreCLR & Roslyn #39

Open
enlight opened this issue Jul 24, 2015 · 2 comments
Open

Port to CoreCLR & Roslyn #39

enlight opened this issue Jul 24, 2015 · 2 comments

Comments

@enlight
Copy link
Owner

enlight commented Jul 24, 2015

Unreal Engine runs on Mac/Linux, sorta kinda, so it'd be nice if at some point Klawr could be used on any platform supported by UE. To that end it would be prudent to consider moving from the Windows CLR & VS to CoreCLR & Roslyn.

CoreCLR now has a hosting API for Unix. It is more limited than the COM-based hosting API available on Windows but should be sufficient for getting Klawr working on Mac/Linux. There's an open issue to expose the Unix hosting API on Windows, and once that work is done there'll no longer be a need to directly interface with the COM hosting API on Windows.

Klawr currently makes use of COM for bootstrapping the CLR and for exposing some C# classes to native code, the latter usage is due to convenience rather than necessity as it reduces the amount of glue code one must write by hand. If there was a code generator for exposing managed classes to native code the COM dependency could be removed entirely, I don't know if one already exists, but by leveraging Roslyn it should be possible to build one that generates a native class from a managed class and glues the two together.

Another issue to consider is the lack of AppDomain(s) in CoreCLR, in the Windows MS CLR the only way to unload an assembly is to destroy the AppDomain it was loaded into, so that's what Klawr currently does to hot-reload the GameScripts assembly while running inside UnrealEd. In theory in CoreCLR the same thing can be accomplished using AssemblyLoadContext, though it's unclear if one can create and destroy those load contexts at will, this issue seems to indicate that load contexts cannot be disposed of as yet. Of course there's also the security/isolation that AppDomain(s) provide, in CoreCLR this would have to be accomplished by spawning separate processes.

Another interesting project is DNX, perhaps not something Klawr can use directly, but may be useful as a reference for proper usage of the CoreCLR hosting APIs and Roslyn.

@enlight
Copy link
Owner Author

enlight commented Jul 27, 2015

The CoreCLR Unix hosting API is now available on Windows (see dotnet/coreclr@480227b).

@enlight
Copy link
Owner Author

enlight commented Jul 27, 2016

I haven't worked on this project in 8 months, so I haven't been following CoreCLR development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant