Creating a uber-issue to represent the major effort to bring official support to Roslyn on additional platforms beyond the initial release on Windows.

Our goal is to help facilitate cross-platform development for .NET developers, as we see Roslyn's compilers as the reference implementation for new language implementations as well as the diagnostic analyzer community.

We should plan a few features/enhancements to be ready for at least a preview implementation, as well as discuss what is necessary for full production-ready support.

The ultimate goal is to provide a credible command-line tool set for managed development and execution on these additional platforms, beginning with Linux and Mac OS X.

This is also in line with our fellow .NET foundation platforms who are also making visible cross-platform investments. Our part in this effort is to provide compilation services in a form of command line compilers and APIs.

For the initial preview, it would be great to have an example of building CoreFx on one of these new platforms. We'll target a “golden path” E2E scenario where user clones the CoreFx Git repo and builds it using tools from the .NET foundation.

Current non-goals for the initial preview

• Emitting debug information (e.g. PDB's or any analog)
  Plans for PDBs on non-windows platforms are still very nacient at this time. In particular we need more clarity from our partners in CoreCLR, Mono, and others.
• Compiler server.
  The first step will be just CSC.
• AOT/NGEN
  This is good-to-have aspect of deployment, but not blocking. Also, generally, if underlying platform supports AOT, it can be applied externally.
• Signing.
  Signing may necessitate calling into platform–specific crypto APIs. We will consider this a stretch goal unless it is absolutely necessary to have this functional when building CoreFX. (I am not very clear on this)
• CI infrastructure for usage within Roslyn.
  This is the CI infrastructure for the Roslyn compiler itself (not for the Core CLR, which seems important).
  We can probably live without this at first, but it is good to have to ensure that continued development does not introduce nonwindows breaks.
• Main branch builds and runs tests on additional platforms.
  Building CSC will likely work, but the test infrastructure may need decent amount of work to make it all pass.

How:

• It seems to be easier to do initial steps on Linux. Just because it is easier to work with VMs in a mixed environments.
• Cross platform related fixes will go into Roslyn main as any regular workitems (via TFS/PRs or whatever is the mechanism of the day). We do not expect to have a special versions or builds for Linux except for very initial work.
• If we need some temporary fixes/hacks/workarounds relevant only for Linux but unacceptable for master, we can have a Git branch for that, but it is very undesirable.
• It would be acceptable to build on windows for now, although it might be convenient to bootstrap on Linux for testing purposes.

Subitems. Rough order. (some items do not depend on each other so may done in different order):

• get CSC functional on Mono/XBuild and give compiler binaries to CoreFx to unblock test infrastructure work on Linux
• ensure that compiler can build CoreFx on on Linux
• figure the deployment story for compailer on multiple platforms and provide official binaries via official deployment story
• complete scenario E2E, bugs, fixes...