System.IO.Pipes from CoreFX (Georgios Athanasopoulos)
Author: Georgios Athanasopoulos
This is a report for my contribution to Mono Project as Google Summer of Code 2017 student
Mono is a open source development platform based on the
.Net Framework and allows developers to build cross-platform applications. Mono’s .NET implementation is based on the ECMA standards for
C# and the
Common Language Infrastructure. It includes both developer tools and the infrastructure needed to run .NET client and server applications on
Linux, Microsoft Windows, Mac OS X, BSD, Sun Solaris, Nintendo Wii, Sony PlayStation 3, Apple iPhone and Android.
Mono is supported by Microsoft and .Net Foundation and consisted by:
The implementation of Pipe Streams in
Mono doesn’t support some functionalities such as parallel builds on msbuild.
CoreFX is the foundational libraries for .NET Core. The implementation of Pipe Streams in CoreFx fixes the previous problems. So, the goal of the project was to import
System.IO.Pipes.PipeStream from CoreFX to Mono. Doing this, new features are offered by Mono.
Initially, I learned more about Mono Project and explored platform structure. Mono Project in order to manage running at different platforms, has implemented layer abstraction. There are source files (with .dll.sources extension) which are responsible for building of libraries. In these files are included source files of classes that will integrate every library. For example I worked on System.Core library that contains LINQ To Objects implementation and the classes HashSet, TimeZoneInfo, Pipes, ReaderWriteLockSlim, System.Security., System.Diagnostics.Eventing. and System.Diagnostics.PerformanceData. For this library, there is the
common_System.Core.dll.sources file in which independent classes from platforms or profiles, are included. One of profile specific files is the
net_4_x_System.Core.dll.sources. This file import common classes from
common_System.Core.dll.sources and additional classes that are required by net_4_x profile. Similarly the
win32_net_4_x_System.Core.dll.sources file is windows platform specific and import classes from
net_4_x_System.Core.dll.sources and additional classes that are required by windows platform. The schema of this structure is presented at Figure 1.
Some other profile specific files are
Some other platform specific files are
I should have imported from CoreFx the files that are in this csproj file. A
.csproj file contains a list of all the files to be compiled as part of a project, as well as other options like the project name, release and debug configurations and compilation options. In
System.IO.Pipes.csproj, I found the files that are compiled when the project is building. Because they are the files that constitute Pipes in corefx, should be transfered in mono. Csproj files have two ways for referring in compiled files. The explicit way in which every file being compiled and conditional way in which a file being compiled only if a condition is true. So, I found files that are compiled only when the platform is either Windows or Unix and files that are compiled at any case. On the first occasion, I added these files in
darwin_System.Core.dll.sources regarding to platform, while on the second I added files in
common_System.Core.dll.sources because should be compiled at every platform.
The import of CoreFx code was easy because the code existed as submodule in repo. Also, I added some errors messages in
SR.cs file that are existed now due to new CoreFx code.
When I resolved some duplicated references between Mono and CoreFx code, built mono with my changes. Running tests, I found out that some APIs of Mono were dropped by CoreFx. In particular, mono has this function
NamedPipeServerStream(String pipeName, PipeDirection direction, int maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, int inBufferSize, int outBufferSize,PipeSecurity pipeSecurity, HandleInheritability inheritability, PipeAccessRights additionalAccessRights) while in corefx implementation there is
NamedPipeServerStream(String pipeName, PipeDirection direction, int maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, int inBufferSize, int outBufferSize, HandleInheritability inheritability). Mono’s version has two more arguments, PipeSecurity pipeSecurity and PipeAccessRights additionalAccessRights. So, I had to change CoreFx code in order to support the broken APIs of Mono. First I added the missing arguments in corefx’s NamedPipeServerStream and I put default values where NamedPipeServerStream was called. Also, in NamedPipeServerStream there was a call of
Create which is used for creation of a pipe on a specific platform. I put the two additional arguments in Create as well. In Create of Windows platform, I added additionalAccessRights at openMode variable and pipeSecurity in GetSecAttrs, implementing the same functionality as mono’s version.
Afterwards, I imported
System.IO.Pipes.PipeStream from CoreFx to build and basic profile with similar way as before. I built and run tests on Windows and Linux platform. The results of tests were successful. For macOS platform, I couldn’t build and run tests because didn’t have a machine.
Beacause I couldn’t test all profiles, some includes from previous version of
common_System.Core.dll.sources had to stay there. It caused conflicts with the includes from corefx. The solution was to transfer these files to the layer of profile specific files ( e.g
net_4_x_System.Core.dll.sources). So, the profiles which I couln’t test have the previous includes of mono, but the other have corefx includes.
Also, I tried to import my changes to
testing_aot_hybrid profile which are relative to Ahead Of Time Compiler of Mono. But there was crash in the runtime in stable version of Mono, so it prevented me from testing.
monodroid profiles, I couldn’t test them because it was very hard to test on Android and IOS environment.
The profiles, that I couldn’t test with System.IO.Pipes.PipeStream from CoreFx, have the initial version of Mono.
Here, are the profiles that was tested:
Here, are the profiles that aren’t tested:
At the end, I enabled signing of libraries for security reasons.
Here are the commits that I did in Mono and CoreFx repos:
In addition to proposed work, I undertook to run
msbuild with parallel builds enabled on Linux using mono. Before my changes, parallel builds weren’t possible. So, the purpose was to check if this important feature will work with CoreFx implementation. Running tests on msbuild with mono and without parallel builds enabled, I took errors both stable and my version of mono. Enabling parallel builds, errors were remaining and I couldn’t determine if my version works properly.
- Test CoreFx implementation to
testing_aot_hybridprofiles, when runtime crash is resolved.
- Test CoreFx implementation to
monodroidprofiles, when there is suitable equipment.
- Test mono on msbuild with
parallel buildsenabled, when tests will run successfully.
Finally, I would like to thank my mentor Ludovic Henry for guidance, immense support and excellent collaboration that we had.