Support generic linux target

[tmds]

Would it be possible to support a generic linux target which is used as a fallback when the specific flavor of linux is not supported?
e.g. ubuntu.15.10-x64 falls back to linux-x64.

[TheRealPiotrP]

Can you be more specific? Where do you suggest adding this behavior?

[tmds]

I think it means: native parts (e.g. runtime) have no dependencies provided by OS libraries and there are more generic versions of for runtime specific libraries which include their own dependencies as well. (e.g. linux-x64 version of a library would include some native library where the ubuntu.14.04-x64 would use the libraries provided by Ubuntu 14.04).

This would mean the generic system would be fatter and probably a bit slower, but it would run on any linux-x64 system. Think about it as doing "static linking" vs "dynamic linking".
A user would then be able to download the linux-x64 version of dotnet and it would just work independent of his linux flavor.

[songdongsheng]

RID break such a UNIX programming philosophy, check the feature, not the distribution.

Just use the feature, exit with a clear error message when no such a feature exist, to say the least of it.

[davidfowl]

@tmds I'm not sure I understand what you're asking for? The RID graph is here https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json. It's just a hierarchy of names and imports that form a relationship (fallback order etc). There's a generic unix and linux already and you can see the more specific RIDs inherit from them.

You have to think of a RID as a package pivot. It allows package authors to put an asset in a folder named after the RID so that it gets selected when some conditions are present (like putting it in project.json), it's not much more than that.

[songdongsheng]

No.

To be more clear, if an application running on RHEL 7.2, it should running correctly both on CentOS 7.2 and Oracle Linux 7.2.

But dotnet just report no runtimes compatible with RID 'ol.7.2-x64'.
Looks like a joke !

$ dotnet build -c Release
Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'ol.7.2-x64'. Possible causes:

1. The project has not been restored or restore failed - run dotnet restore
2. The project does not list one of 'ol.7.2-x64' in the 'runtimes' section.

[dasMulli]

I can see two themes here:

1. Request to more visibly support the generic linux RID.
   Probably this is just a documentation issue because people only see the samples using the distro+version RIDs.
   I'm sure there are a lot of people putting together custom linux environments or using non-mainstream distributions wondering if and how they can get netcoreapp-s working there. Maybe something like "if linux kernel X.Y.* with kernel modules/options [..] and libraries [..] are present, you should be fine but it's not supported by Microsoft." would be helpful enough.
   However, i am bit concerned seeing that many packages do not provide runtime assemblies for linux-x64. E.g. Libuv package only provides builds for RIDs debian-x64 and rhel-x64. (not a show-stopper as you can easily bring your own).
   Also, you can easily get errors like the following when you include the RID linux-64 in your project.json:

Errors in ...../project.json
    System.Diagnostics.Process 4.1.0-rc2-24027 provides a compile-time reference assembly for System.Diagnostics.Process on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with linux-x64.
    System.IO.FileSystem.Watcher 4.0.0-rc2-24027 provides a compile-time reference assembly for System.IO.FileSystem.Watcher on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with linux-x64.
    One or more packages are incompatible with .NETCoreApp,Version=v1.0 (linux-x64).

1. Request for builds with statically linked dependencies.
   That is a big no-no. First it would make the size of the executables explode and make hotfixing single libraries a pain (re-distribute all standalone apps because of a libssl bug?).
   But more importantly, that may not be possible because of license incompatibilities and may cause license issues for developers wanting to sell standalone apps.

[tmds]

@davidfowl @dasMulli Thanks for clarifying. I wasn't aware of the RID graph. How well does the generic linux RID work today? My experience is dotnet only works on the supported linux flavors. E.g. if you try to run it in ubuntu 15.10, it doesn't use the generic linux RID bit fails because it cannot find assemblies for the more specific ubuntu 15.10 RID.

[tmds]

@dasMulli How do you include the RID in your project.json?

[dasMulli]

You would have a project.json like this:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "Microsoft.NETCore.App": "1.0.0-rc2-*"
  },
  "frameworks": {
    "netcoreapp1.0": {}
  },
  "runtimes": {
    "linux-x64": {}
  }
}

But that will give you the restore error mentioned before:

Errors in /Users/martin/Documents/dotnet/TestLinuxApp/project.json
    System.Diagnostics.Process 4.1.0-rc2-24027 provides a compile-time reference assembly for System.Diagnostics.Process on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with linux-x64.
    System.IO.FileSystem.Watcher 4.0.0-rc2-24027 provides a compile-time reference assembly for System.IO.FileSystem.Watcher on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with linux-x64.
    One or more packages are incompatible with .NETCoreApp,Version=v1.0 (linux-x64)

[tmds]

@davidfowl Is there some up-to-date documentation on project.json? I constantly find myself changing this file until stuff builds.

[dasMulli]

http://json.schemastore.org/project

It has just been updated yesterday.

[tmds]

@dasMulli Good for validating, less for understanding. Need a bigger picture to understand things like: when do you need a runtimes section (and what RIDs are there)? What is the "Microsoft.NETCore.App dependency? How does a typical project.json look for a library and for an application? What is "preserveCompilationContext"? ...

[guardrex]

@tmds Docs are WIP and on the way, but I have some links at https://github.com/dotnet/cli/issues/2135#issuecomment-212692267. Some of your questions are answered by the app types doc, and there are some other docs in the cli repo Documentation folder. There are some good basic explanations at https://docs.asp.net/en/latest/ under Conceptual Overview and Fundamentals. [Keep in mind that RC2 may release early next week with a host of doc updates. You might want to hold off reading deeply until RC2 hits and docs get a major update.]

preserveCompilationContext just means that the compilation metadata will be preserved after you compile the project locally, so additional compilation can occur later (e.g., Razor views are compiled later, thus you need to "preserveCompilationContext" for something like that).

[tmds]

@guardrex I found this interesting article: http://dotnet.github.io/docs/core-concepts/app-types.html, but it doesn't cover libraries, created a doc issue: dotnet/docs#427

[guardrex]

@tmds Yep ... but just as well they didn't do too much work on docs with all of the design. Bascially, the GH issues ARE the best docs. It's just that there is a lot there to consume. You can get a rundown in the Annoucements for RC2 of breaking changes: https://github.com/aspnet/Announcements/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0-rc2

Your question about the platform standard is answered here: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

I'll put one of my packages up on GH and ping you back so you have a basic sample of what one looks like.