Updated proposal from 2017/9

Proposal (by @karelz - https://github.com/dotnet/corefx/issues/1626#issuecomment-329840518) will be updated in top-post based on further discussion and proposal changes.

We discussed community-driven port for FreeBSD with @RussellHaley (from FreeBSD community) and @wfurt (from .NET Core team) who both expressed interest in the work.
Here's a plan proposal we put together (feedback / suggestions are welcome):

1. Produce binaries in CoreCLR & CoreFX repo targeting FreeBSD - using hacks is fine
   • Hard to parallelize, @wfurt will work on that
   • The build can be mix of builds from other platforms (Mac, Linux) targeting FreeBSD
   • We will need documented steps (on FreeBSD wiki) to reproduce the build with FreeBSD-specific bug fixes
2. Run & stabilize CoreCLR tests (using corerun)
   • Tests may be built on another platform
   • Goal: Provides basic quality of runtime
3. Run & stabilize CoreFX tests (using corerun)
   • Tests may be built on another platform
   • Note this requires xunit. We believe, based on our past porting experience, once [2] is done, xunit will just work.
   • This can be in theory parallelized with [2] - it may require shortcutting xunit (e.g. generate static execution recipe on another platform)
   • We can expose new OSPlatform API for FreeBSD when the pass rate is reasonable: see dotnet/corefx#23989
4. Full stack build on FreeBSD (using corerun as bootstrapper from [1]-[3])
   • We will need all tools (nuget, msbuild, roslyn) to work on boostrapping .NET Core
5. Installers (FreeBSD ports)
   • First-stage: Using product binaries from nuget feeds
   • Second-stage: Build product from source (blocked on build from source effort)
   • Requires FreeBSD community expertise and guidance on design
   • Note: We can link FreeBSD packages also from official .NET Core download pages as community-support packages
6. Regular build and test runs on FreeBSD
   • Goal: Make sure changes in .NET Core repos breaking FreeBSD are known early
   • Design needed
   • Requires FreeBSD community expertise and guidance on design

Operation principles:

• Changes in [2]-[4] should be done primarily in CoreCLR/CoreFX repos (due to CLA signing requirements, code reviews from .NET Core team experts/members. etc.)
• We will track high-level work on this issue. Specific bugs will be filed as separate issues.

If anyone is interested in helping, please let us know here. We can easily distribute work items from [2] & [3] above once we are far enough with [1].

Original proposal from @ghuntley from 2015/5

This issue is to discuss unit(s) of work to actually produce FreeBSD assemblies for corefx.

@stephentoub - There's what's likely a more pressing issue, which is actually building for FreeBSD. Today, when we need to specialize an assembly for a particular platform, we effectively have three builds, producing three different managed assemblies: Windows, Linux, OSX. Sounds like at least for now we'll need a fourth, FreeBSD. I suggest you start by modifying the build to support an IsFreeBSD property (or just IsBSD of you think there's a high chance that the implementations across BSDs will be the same even with varied kernels) along with the appropriate OSGroup targets. That can then be used in the csproj files as needed to specialize an assembly with FreeBSD-specific code.

Related issue(s)

• [public api] System.Runtime.Environment - OSName("FreeBSD") or OSName("BSD") #14536 (OSGroup identifier in the public API)
• add FreeBSD to Common/tests/XunitTraitsDiscoverers/PlatformID.cs? #14507 (OSGroup identifier in the private API)

/cc: @janhenke @josteink