and their response is even worst:
https://github.com/dotnet/cli/issues/10497#issuecomment-4494...
Sadly, I thought they would have fixed it and not ignore it.
In Windows file access performance compared to Linuxdotnet
cli
Command Line2015–2021
dotnet / cli · Archived
cli
The .NET Core command-line (CLI) tools, used for building .NET Core apps and libraries through your development flow (compiling, NuGet package management, running, testing, ...).
36Distinct people
53Mentions
1Explicit recommenders
3.5KGitHub stars
What to know before exploring
What it is
The .NET Core command-line (CLI) tools, used for building .NET Core apps and libraries through your development flow (compiling, NuGet package management, running, testing, ...).
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
My favorite actually is https://github.com/dotnet/cli/pull/3494 . Of course sending things like IP addresses is unavoidable. I should also mention…
yuhong used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year53 dated mentions
Observed mentions: 2015-11-18 21:39:43 UTC to 2021-11-17 11:23:19 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 12 | 1 | 11 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 19 | 2 | 17 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 14 | 3 | 11 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
This Repo has moved!
This repo has been merged into https://github.com/dotnet/sdk. All previous releases that were serviced out of this repo are now out of support. We have created tags for all servicing branches if you still wish to build those branches. This repo will be made read-only on 2/17/2023
For more information, see dotnet/announcements#119 "Consolidating .NET GitHub repos"
Looking for the .NET Core SDK tooling?
If you are looking for the latest nightly of the .NET Core SDK, see https://github.com/dotnet/core-sdk.
Build status
Read the full README on GitHubWhat Hacker News says
14 sourcesAlso stuff like this:
https://github.com/dotnet/cli/issues/3093#issuecomment-44343...
Trust, is an issue.
In Windows file access performance compared to LinuxDotnet core still calls home even with telemetry disabled
3 points · Open discussionIt's just a shame they felt they had to put in the sneaky telemetry.
https://github.com/dotnet/cli/issues/3093
In Ask HN: What technologies did you learn in 2018?When they’re not screwing it up:
https://github.com/dotnet/cli/issues/3093#issuecomment-44343...
I suggest anyone interested reads the entire thread.
In Is ASP.NET Core Now a Mature Platform?Names..
Satya Nadella is directly responsible here. There has been no response from him on petitions about it. Google the various sources:
Ben Evans is responsible for enforcing the state of affairs on .Net core at least. https://github.com/dotnet/cli/issues/3093
Joey Ailleo, Powershell PM said this https://news.ycombinator.com/item?id=18629942
"I'm a huge privacy advocate, but telemetry doesn't have to be a dirty word. With PowerShell Core, we went through an RFC process to define our telemetry goals and implementation[1], we publish our data to a public dashboard[2], and all of the telemetry source code is out there in the open[3]. Our telemetry enables to help drive prioritization and decisions around platform/OS usage, and disabling it as simple as setting an environment variable[4]."
That's basically MSFT policy:
1. Telemetry is good
Read the rest
for you
2. We do X, Y, Z (but forget to mention the times they got it wrong like the environment variable didn't work on Debian packages they built for .net core).
3. Default is opt out, if you can (windows 10 pro has no opt out option).
4. Stick fingers in ears.
MSFT, you can go to hell at this point. This is just disrespecting and abusing your customers. I will ALWAYS put a privacy respecting vendor at the top of the list.
Adding machine ids [MAC address] to telemetry [.NET Core] (2016)
2 points · Open discussionDoes this justify hashing user identification for later correlation with other products?
https://github.com/dotnet/cli/blob/b45f1fb439b36872c249b07f1...
In Microsoft .Net Core telemetry is not opt-inAccording to this PR they do collect command line arguments.
https://github.com/dotnet/cli/pull/2145
"My understanding is that this was recently discussed with our privacy team and we concluded that collecting the arguments themselves (hashed or not) is not acceptable per our privacy policies. Not sure whether the code already reflects that, but it's being worked on."
Somebody in the thread for the issue said it's "not acceptable per our privacy policies" and "being worked on" two years ago, but did they ever actually stop collecting command line arguments?
In Microsoft .Net Core telemetry is not opt-inI went down the rabbit hole on this one a little. They're sending a SHA256 hash of the user's mac address with every telemetry event (which can be trivially reversed. I leave it to the reader to decide whether MAC addresses are personal identifiers).
And also for what it's worth, it appears that they are using this ID to correlate what users are doing across their products - as indicated by this comment: "// The hashed mac address needs to be the same hashed value as produced by the other distinct sources given the same input. (e.g. VsCode)"
(https://github.com/dotnet/cli/blob/b45f1fb439b36872c249b07f1...)
In Microsoft .Net Core telemetry is not opt-inThis stuff is Free and Open Source, right? And the phone-home stuff is done with ordinary network connections, right? So the telemetry could be stopped either using firewall rules, or by modifying the code.
Edit looks like it can be disabled with the "DOTNET_CLI_TELEMETRY_OPTOUT" environmental variable, following https://github.com/dotnet/cli/issues/3093#issuecomment-22997...
In Microsoft .Net Core telemetry is not opt-inMicrosoft .Net Core telemetry is not opt-in
140 points · Open discussionIf anyone other than me was concerned that the "system property to disable JRE last usage tracking" was something like the enabled-by-default telemetry of .NET Core[1] (which made me give up on it in disgust), it's apparently[2] not – it's just some (commercial add-on) logging feature.
[1] https://github.com/dotnet/cli/issues/3093
[2] https://docs.oracle.com/javacomponents/usage-tracker/overvie...
In JDK 10 Early Access Release Notes> Build-time performance is much improved in .NET Core 2.1, particularly for incremental build. These improvements apply to both dotnet build on the commandline and to builds in Visual Studio.
It is good to see some improvements. Currently, `dotnet build` takes at least 3 seconds to compile a simple hello world project on my system, even when the source code isn't changed at all. At first I thought I did something wrong, but no, others were suffering from this too.[1][2]
This occurs because every `dotnet build` run tries to resolve the dependencies and inspect the file structure to see if any changes are made. And for some reason those operations are dog slow. Visual Studio doesn't have this problem, as it knows the file structure and the dependencies beforehand, so it can determine whether there should be a recompilation easily. I wanted
Read the rest
to use VS too but it was too slow for my tiny laptop, so I'm stuck with VS Code.
I hope the improvements are big enough that I can reevaluate using .NET Core again. The build time was a huge obstacle to my iteration cycle, so I had to use TypeScript in my previous project. I sincerely want to code my backends in C#.
[1] https://github.com/dotnet/cli/issues/5918
[2] https://github.com/dotnet/cli/issues/7610