Long Term: Add Support for .NET Core 2.0

[jkoritzinsky]

Something that I'd like to see in the future would be to run on .NET Core (dotnet/coreclr with dotnet/corefx) on the RoboRIO (as an option or as a replacement of Mono). Since .NET Core is developed directly by Microsoft and open source, it will probably have better support than the Mono Runtime. I also would like to see it as an option. I'll start working on this myself in the future. Below are the steps I'd need to do to make it work:

• [ ] Add FRC toolchain support to the existing CoreCLR build chain
• [x] See what in WPILib doesn't compile for .NET Core
• [x] Try to find fixes for above (will be expanded as problems are found)
• [ ] Test on roboRIO hardware
• [ ] Try to find fixes for bugs in above (will be expanded as problems are found)
• [ ] Modify VS extension to have CoreCLR as a choice as well as Mono.

And probably more things after that.

[ThadHouse]

This would definitely be cool. I had always thought about it, but never had had the time to seriously look into it. Adding the FRC toolchain in is probably actually the hardest part of this (and maybe running the built in .NET Core tests if there are any.) Everything else should be fairly portable, as long as the Marshall class and P/Invoke are still available.

[ThadHouse]

Currently GetDelegateForFunctionPointer is not implemented, so that will probably be the main issue for now. Hopefully that gets added soon.

[jkoritzinsky]

I can mod the FRC toolchain in pretty easily (I took a quick look around their build system. Basically were just need to copy the ARM makefiles and adjust the toolchain tuples). The missing method you mentioned will be a bigger problem.

[jkoritzinsky]

I just was looking at the source again and it actually looks like GetDelegateForFunctionPointer has been implemented for a while. See the following sources:

https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Runtime/InteropServices/Marshal.cs#L2492

https://github.com/dotnet/coreclr/blob/master/src/vm/marshalnative.cpp#L366

So maybe that won't be a problem after all.

[ThadHouse]

Hmm. I wonder what I was looking at then. Looks like we should be good then. Everything else shouldn't be too hard to deal with.

[ThadHouse]

I ran the .NET Portability analyzer on this and NetworkTables. NetworkTablesCore is fairly easy to change (NetworkTablesManaged is not however). Here is a list of what needs to be changed for WPILib.

HAL

• [ ] System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage (Just make our own. Easy)
• [ ] System.EntryPointNotFoundException (Again probably make our own. Just like NetworkTablesCore)
• [x] System.Environment Is64BitProcess and OSVersion (Use System.Runtime.InteropServices.ProcessArchitechture and OSDescription)
• [x] System.OperatingSystem.GetPlatform (Figure out something new. Necessary for us however)
• [x] System.PlatformID (Again Necessary for us. Figure something out)
• [x] System.Reflection.Assembly.GetExecutingAssembly (Typeof(CurrentType).GetTypeInfo().Assembly)
• [ ] SuppressUnmanagedCodeSecurityAttribute (Can remove, but maybe IfDef it out. Its good to have on windows)
• [ ] System.Reflection.AssemblyName.GetAssemblyName (Figure out what we can do)
• [x] System.Threading.Thread Abort, Priority and Yield (SpinWait suggested for Yield, other ones can be worked around)
• [x] System.Threading.ThreadInterrupedException (Again Work Around)
• [x] System.Type IsAbstract, IsInterface, GetInterface (.GetTypeInfo().IsAbstract and IsInterface for the first 2, GetInterface will need a fix)

WPILib

• [x] System.Activator.CreateInstance
• [x] System.Runtime.Remoting.ObjectHandle.Unwrap (These 2 are used in RobotBase to actually start the robot code. Definitely need a fix then.)
• [x] System.IO.Ports.SerialPort.ctor (Where do we use this??) - LOL... Fixed
• [x] System.Reflection.Assembly.GetExecutingAssembly (Typeof(CurrentType).GetTypeInfo().Assembly
• [x] System.SystemException
• [x] System.Threading.Thread Abort, Priority and Yield (SpinWait suggested for Yield, other ones can be worked around)
• [x] System.Threading.ThreadPriority
• [x] System.Type IsAbstract, IsInterface, GetInterface (.GetTypeInfo().IsAbstract and IsInterface for the first 2, GetInterface will need a fix)

WPILib.Extras

• [ ] System.AppDomain (Gone in .NET Core)
• [x] System.Threading.Thread Abort, Priority and Yield (SpinWait suggested for Yield, other ones can be worked around)

[ThadHouse]

Did a little more looking. The biggest issues to get rid of are the Activator.CreateInstance stuff, and then the platform switching. They took out the old ways of detecting platforms and replaced the APIs with different ones.

For 32 vs 64 bit arch, we can check the size of IntPtr. For Unix vs Windows, I guess we could use the DirectorySeperatorChar, as that should be different between unix and windows. We already use P/Invoke to detect the difference between Mac OS and Linux, so I think that would be OK, as long as Windows doesn't switch in the future.

Any other ways you can think of to check between OS Types and bitness?

[jkoritzinsky]

We can use the new interfaces in System.Runtime.InteropServices.RuntimeInformation.

[ThadHouse]

That would mean we have to provide separate binaries for NET Core vs NET Framework and Mono. That should be OK, but it'd be nice to be able to use the same binary no matter what framework is used. and the new RuntimeInformation stuff does not exist in the old framework.

[jkoritzinsky]

Good point. I think what you said will work well enough. I'll keep an eye out for anything else.

[ThadHouse]

WPILib should now be fully portable. WPILib.Extras is mostly. The only issue is that without AppDomain support GetAssemblies is gonna be a much harder method to make. It seems like everything else in those 2 is portable. I'll work on the HAL next, but that shouldn't be bad either.

[ThadHouse]

I think its worth waiting until .NET Core 2.0 comes out. Looking at the roadmap, they're adding back some of the missing libraries we need at that point. In addition, they plan on having arm 32 and 64 builds, which we should be able to base a soft float version off of then the current x86 builds.

[jkoritzinsky]

I agree. I'll change the issue title.

[ThadHouse]

@jkoritzinsky Will you send me your email? I got an email today asking a few questions about Attributed Commands. My email is on my profile.

[jkoritzinsky]

@ThadHouse I just sent you an email.

[ThadHouse]

I ended up getting NetworkTables moved over to multi target .net core and .net framework 4.5.1. Finishing up travis builds now on my local repo, but everything went over fairly smoothly. The only thing is I couldn't run the reflection tests for NetworkTables.Core on NetCore, but I can run them on the full framework and that's the only place they're needed, so its good.

[ThadHouse]

Well, we can cross off being able to run .net core on the rio :D

This was also done 100% with a microsoft build, since they build for softfp, so we don't even need to worry about running our own builds of the entire library.

[jkoritzinsky]

Nice!! Ok this is awesome.

[ThadHouse]

It required building a few native dependencies that are not included on the rio by default, so it won't be a no install solution, but it's pretty close. I was able to get both a network tables and cscore program working successfully. I'm sure wpilib would work if ported. I'm going to wait until VS 2017 and the release .net core tooling comes out before actually switching that repo over.