Linux Compile Error

[Conzar]

I get a compile error when trying to compile. Also note, the dnu command doesn't seem to exist. Instead, its called dotnet so the build script doesn't work. I changed this and eventually got to compiling with the following error:

error: Package Microsoft.CodeAnalysis.CSharp 1.1.0-rc1-20151109-01 is not compatible with dnxcore50 (DNXCore,Version=v5.0). Package Microsoft.CodeAnalysis.CSharp 1.1.0-rc1-20151109-01 supports:
error:   - net45 (.NETFramework,Version=v4.5)
error:   - portable-net45+win8 (.NETPortable,Version=v0.0,Profile=Profile7)
error: Package Microsoft.CodeAnalysis.Common 1.1.0-rc1-20151109-01 is not compatible with dnxcore50 (DNXCore,Version=v5.0). Package Microsoft.CodeAnalysis.Common 1.1.0-rc1-20151109-01 supports:
error:   - net45 (.NETFramework,Version=v4.5)
error:   - portable-net45+win8 (.NETPortable,Version=v0.0,Profile=Profile7)
error: One or more packages are incompatible with DNXCore,Version=v5.0.
log  : Writing lock file to disk. Path: /home/spethm/Work/MonkyGames/projects/osvr/osvr-ubuntu-build-script/OSVR-Config/src/ConfigUtil/project.lock.json
log  : /home/spethm/Work/MonkyGames/projects/osvr/osvr-ubuntu-build-script/OSVR-Config/src/ConfigUtil/project.json
log  : Restore failed in 13217ms.

Errors in /home/spethm/Work/MonkyGames/projects/osvr/osvr-ubuntu-build-script/OSVR-Config/src/ConfigUtil/project.json
    Package Microsoft.CodeAnalysis.CSharp 1.1.0-rc1-20151109-01 is not compatible with dnxcore50 (DNXCore,Version=v5.0). Package Microsoft.CodeAnalysis.CSharp 1.1.0-rc1-20151109-01 supports:
      - net45 (.NETFramework,Version=v4.5)
      - portable-net45+win8 (.NETPortable,Version=v0.0,Profile=Profile7)
    Package Microsoft.CodeAnalysis.Common 1.1.0-rc1-20151109-01 is not compatible with dnxcore50 (DNXCore,Version=v5.0). Package Microsoft.CodeAnalysis.Common 1.1.0-rc1-20151109-01 supports:
      - net45 (.NETFramework,Version=v4.5)
      - portable-net45+win8 (.NETPortable,Version=v0.0,Profile=Profile7)
    One or more packages are incompatible with DNXCore,Version=v5.0.

Maybe you should consider opting out of Telemetry

The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favourite shell.

And then there is the fantastic message I get when installing dotnet (should I really expect anything less from M$)

This software may collect information about you and your use of the software, and send that to Microsoft.

Why did you choose .net, WHY? There are heaps of cross platform UI's. JavaFX is awesomesaus. QT, etc. .NET is a problem on Linux and I suspect OSX.

[JeroMiya]

The build issues might be fixed when the project is updated to CoreCLR 1.0, though they are not yet tested on Linux (we have other Linux/Mac issues to solve before we can check the "Linux/Mac supported!" checkbox). There is a PR for this here:
#34

I think we're waiting on updating our CI machines to use it.

Also see, w.r.t. telemetry:
#37

[Conzar]

Even opting out of telemetry doesn't solve the reporting back to M$ issue. As installing dotnet on linux produces that error message. Personally, I won't be touching this but I thought I would report for any brave/stupid other linux users out there that will allow M$ on their systems.

[JeroMiya]

That message is specifically addressing the telemetry that is disabled when you opt out of telemetry with the environment variable. There is no other telemetry or reporting back done by the CoreCLR tooling, so disabling it there will disable everything. Please see the following for more information about the telemetry in the Microsoft builds - what information is collected (and more importantly what is not collected):
https://aka.ms/dotnet-cli-telemetry

That being said, CoreCLR is an open source project, so those overly concerned with telemetry or build integrity can always review the code and build their own binaries. Anyone not on one of the supported Linux distros for the Microsoft binary packages would need to do this anyway.

[Conzar]

@JeroMiya trusting M$ by default is wrong. We have many years of horrible M$ business practices to go by.

Anyways, my suspicions are correct. Installing .net core automatically opts into telemetry (via cli).
https://github.com/dotnet/cli/issues/3093

[JeroMiya]

The link I posted previously clearly explains the telemetry as opt-out, as does the issue you linked. It's not a secret. And, as I said before, setting the environment variable opts out of telemetry completely. We fully plan on doing so in our build script as a courtesy, though you can set it yourself before running the script, if you wish. If you don't believe that opt-out actually opts-out or that Microsoft is not being truthful in describing what data is gathered or not gathered, then please review the CoreCLR source. It is an open source project, so you are free to do so.

I'm leaving this issue open to address the Linux build issues, but please keep discussion focused on OSVR-Config.

[Conzar]

The link I posted describes the telemetry of the dotnet core library that is installed and is not related to programs that are compiled with dotnet. By default, installing dotnet core on Linux opts in to telemetry on the commands related to dotnet. IE the command lines. This is NOT related to the compile options. Perhaps you need to have a re-read of the issue posted to get a better understanding of the difference.

[Conzar]

So much for your Open Source Claims:

The only catch is that you need to pull the ASP.NET Core Module out and install that manually ... they don't have a standalone installer for the module yet (AFAIK), nor has it been spun off into OSS yet (but they are planning to do that)

What where you saying about looking into the source code? Oh right, that's not possible. Again, you put too much trust into M$

[JeroMiya]

I understand exactly how the dotnet-cli telemetry works, what dotnet-cli commands it related to, and what data was collected. It's all spelled out clearly in the CoreCLR documentation that I linked to earlier, as well as from several of the links in the issue you posted. I think the issue of telemetry is well and truly addressed in this thread. In summary:

• CoreCLR runtime and framework libraries do NOT have any telemetry.
• dotnet-cli commands (e.g. dotnet build, dotnet restore) have telemetry that is invoked at the time of executing the commands, that defaults to on.
• setting an environment variable turns it off.
• we should do that in our build scripts.

[JeroMiya]

We don't actually use the ASP.Net Core module - especially not on Linux. The app runs on the kestral server fully standalone, not on IIS. That being said, I may have some kruft left from the template project that references IIS - I'll open an issue to remove any references to it.

Issue opened. See: #38

For future reference, I will not be convinced by "Microsoft is evil" style arguments. If you have a specific concern, such as telemetry, by all means let's discuss it. However, Github is not a forum for debates such as these.

[Conzar]

Why not use mono on linux instead of M$? Mono actually has a history of working unlike .NET Core which is still broken and of course has spyware.

[JeroMiya]

Fixed in:

• CoreCLR RTM update #34
• Added ubuntu.14.04-x64 as a runtime in project.json #39

Telemetry turned off in:

• Added commands to turn telemetry off for the build script. #40

This issue is still open:

• Linux/OSX support #32

Mono support:

• If you would like to add support for running the backend on Mono, feel free to do so. However, please write a separate build_release_mono.sh build script to build with mono, per your preference.

A couple of known issues remain for full Linux/MacOS support. While the backend runs and most pages are now functional, Start Server button does not work (need runtime config for executable suffix on current platform), and there isn't a convenient "launcher" script/app as there is on Windows to make it easier to run as an end-user. Or alternatively a NativeScript wrapper or similar.