Using standard classes outside of mscorlib

Aug 11, 2015 at 9:33 AM
If i have a need of bringing in .net standard classes that exist outside mscorlib, i assume i will have to run il2c.exe on those assemblies?

But which version should i get them from?

If for example i need HashSet<>, i need System.Core.dll. If i run il2c.exe on the 4.0 version of that assembly i get an error saying "Unable to read metadata file".
Aug 11, 2015 at 1:14 PM
you have 2 options:

1) Bring the source code of class into CoreLib and compile (most realistic for now)

2) Copy all dlls which used into one folder where you run il2c.exe but they all will be depending on mscorlib.dll which is not ported yet and thus are not going to work.

I am working on to port all classes in mscorlib.dll but it is massive work and I don't know when I am going to finish it as it required finishing Reflection first which is not supported now
Aug 11, 2015 at 1:27 PM
Have you considered grabbing the non-native parts of mscorlib from Microsofts own CoreCLR project? In fact, why not also grab most of the native parts as well (except the jit part of course)? They must already have implemented things things like console/locking/threading and other things that tie into native code.

They have the mscorlib code here.

Of course at they also have the rest of the Core framework.

Btw, if i include an assembly that's build against the normal mscorlib, but only uses the subset you have ported, should i be able to run il2c directly on that assembly, or will it break/fail to identify your corelib as the correct one?
Aug 11, 2015 at 10:35 PM
yes, I did grab some stuff or learned a lot. it is already designed for using JIT and implementation of CoreCLR. Not really useful to dig all bits which is taking to much time.

I am using mscorlib from CoreCLR
Aug 12, 2015 at 7:29 AM
But surely you can grab all the pure managed classes that exist in mscorlib, such as Dictionary, List, ie ones that don´t call into the the CLR itself? I realize that for example reflection classes might interact with the CLR lots of classes in mscorlib are just there for historical reasons. Do you have a list of classes missing from your corelib?
Aug 12, 2015 at 10:33 AM
Edited Aug 12, 2015 at 10:37 AM
I don't remember for sure but as I remember mscorlib contains 15000 classes (around). CoreLib around 5000 so it is missing around 10000 classes.
Aug 12, 2015 at 10:39 AM
He he :) I didn't mean to imply that it is should be done manually, more that you could use a script to checkout the CoreFx/CLR sources, and delete/replace the native parts with what you have implemented, leaving the pure managed classes exactly as they were. That would also allow fairly easy upgrades as the CoreFx/CLR source is updated and bugfixed etc.
Aug 12, 2015 at 10:39 AM
But surely you can grab all the pure managed classes that exist in mscorlib, such as Dictionary, List, ie ones that don´t call
this is how CoreLib was created. but even simple classes such as string, array, decimal are using internals or VM and thus not applicable to il2c. This is why I need to port mscorlib myself. mscorlib mainly the bridge between VM and CLR objects
Aug 12, 2015 at 10:43 AM
I am trying to write code to be as close as possible to mscorlib. the main stopper is Reflection which I know how to implement but didn't have time to finish it yet fully.
Aug 12, 2015 at 11:21 AM
I am not surprised that string, array and decimal require custom implementation, but mscorlib also has a lot of classes like Hashtable, Stack which I figured would be "clean", but I guess some of them might make a simple calls like typeof/GetType etc, which I don't know if you support currently?

How are you planning on handling reflection? I might be able to assist a bit.

Btw, on a completely separate note, have you considered moving to GitHub, its a lot nicer than Codeplex :)
Aug 12, 2015 at 11:29 AM
typeof and GetType is fully working but it supports only Name, FullName, BaseType properties (but does not support GetMethod, GetField etc) . It can pass 80% of Mono.NET tests so il2c does support a lot.

as well as Delegate, MultiDelegate, locks, array, multiarrays, LINQ (but not LINQ expressions which compiled at runtime) as well as async/await if partially implemented

I am planning to use libjit from GCC to fullfil the gap for Runtime Types to allow to build it at runtime times and it would allow to create the code on the fly
Aug 12, 2015 at 11:31 AM
Btw, on a completely separate note, have you considered moving to GitHub, its a lot nicer than Codeplex :)
I was using Codeplex as it has forum and it had statistics but now stats are not working and when I have time I am going to have a look at github
Aug 12, 2015 at 12:55 PM
GitHub's issues works pretty well as forum (you can create a "discussion" label to separate from bugs/feature requests etc).

Must say this an impressive piece of work, with a bit more work and some polish on the toolchain (VS project template, automated refresh from CoreFx/CLR) and documentation, this could be extremely useful. The only thing that comes close is MS' own LLILC (LLVM based compiler for .Net Core), but they are currently only planning to use it for Jit, and only later as an AOT compiler, and I don't think they are planning on getting it to work with say emscripten, but rather rely on a real CLR on the target platform.