These notes gather information and assessment regarding the possibility to target .NET Core (v2.0) for embedding in rClr
- MS doc - .NET Core hosting
- MS doc - CLR Hosting
- Blog post hoswing coreclr
- Hichhikers guide to coreclr
- Mono embedding
- Python for .NET thread on CoreCLR
- Marqin/simpleCoreCLRHost
- CoreCLR embedding in pythonnet
- Core CLR hosting part of the codebase
- Fancy.CoreClrHost codebase and the related post
Bootstrapping the .NET execution engine is the start, and this is what most of the information out there details. Fine. But in the end it is a small part of rclr, and documentation is very patchy or unclear as to:
- How much of the prior, .NET Framework MSCorEE API objects and methods remains valid or conversely superseded by .NET core
- How much of the prior, .NET Framework MSCorEE API objects and methods remains windows only
- Would the Mono part of the native codebase be completely obsolete and if so, has as much to be rewritten for .NET core
More "drastic" or left field approaches:
-
Feasibility to completely reengineer with more code in C# than C++ (in the spirit of Python for .NET) - but has this already been pushed as much as possible?
-
Is there an opportunity to engineer some subsystems and share with projects such as Python for .NET
-
Desirable things "on the edge"
- Using Rcpp for glue code - definitely wanted technically, but what does that mean for licensing; are there subtleties different from R itself in terms of rClr users
C:\src\tmp\coreclr-master\src\coreclr\hosts\unixcoreruncommon\coreruncommon.h is very thin. C:\src\tmp\coreclr-master\src\coreclr\hosts\inc\coreclrhost.h