.NET Core Tools Telemetry
The .NET Core tools include a telemetry feature so that we can collect usage information about the .NET Core Tools. It’s important that we understand how the tools are being used so that we can improve them. Part of the reason the tools are in Preview is that we don’t have enough information on the way that they will be used. The telemetry is only in the tools and does not affect your app.
The telemetry feature is on by default. The data collected is anonymous in nature and will be published in an aggregated form for use by both Microsoft and community engineers under a Creative Commons license.
You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (e.g. export on OS X/Linux, set on Windows) to true (e.g. “true”, 1). Doing this will stop the collection process from running.
The feature collects the following pieces of data:
The command being used (e.g. “build”, “restore”)
The ExitCode of the command
For test projects, the test runner being used
The timestamp of invocation
The framework used
Whether runtime IDs are present in the “runtimes” node
The CLI version being used
The feature will not collect any personal data, such as usernames or emails. It will not scan your code and not extract any project-level data that can be considered sensitive, such as name, repo or author (if you set those in your project.json). We want to know how the tools are used, not what you are using the tools to build. If you find sensitive data being collected, that’s a bug. Please file an issue and it will be fixed.
> You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (e.g. export on OS X/Linux, set on Windows) to true (e.g. “true”, 1). Doing this will stop the collection process from running.
The way I see it, at the end of the day, the decision for Microsoft is really between not collecting data and an opt-out system. If Microsoft chooses not to collect data, then all developers have to live with tools that improve slowly and have issues (possibly security related that could be maliciously abused) that are not fixed as quickly as they could be.
If Microsoft chooses an opt-out system, they can collect the data they need to make sure their tools are working optimally and as intended. Some developers may not be comfortable sharing how they use Microsoft's tools even with no personally identifiable information collected. These people can opt-out while minimally compromising the quality of the data collected. Additionally, the tools are open source, so any developer that's skeptical of how and what data is being collected by the tools can verify Microsoft's claims.
Those are the two options I see. To me, the cost/benefit of the second option greatly outweighs the cost/benefit of the first for all involved. By not collecting data, security issues that could actually compromise your privacy could go unfixed for longer. By collecting data through and opt-out and open source system, Microsoft can fix issues ASAP and developers can verify that data is collected in way that preserves their own privacy.
It seems like a lot of people are knee-jerking to the idea of collecting data through an opt-out system and not actually weighing the cost/benefit of the realistic options. Can you explain how not collecting data has a lower practical cost/benefit ratio than an opt-out and open source system?
To address your point, it's not possible to be aware of the benefits you're missing out on without data collection.
Sadly the motivation was often to ignore the data or watch it get spun by some jackass with the exact wrong agenda. It's just software, there's always a way to fix things if you really want to.
This case is different from silently adding telemetry on a minor upgrade to a tool in production
It's unfortunate they are so tone-deaf about the PR implications in Windows.
Since we only have two recorded events of someone deploying a nuclear weapon in a real-world scenario, it should be safe to relocate those buttons off the main console, and just use the auxiliary functions button, behind the kick panel, next to the row of DIP switches used for selecting the button press function. Since "reorder coffee pods" was the last auxiliary function to be added, "launch nukes" will be next, so make sure you double-check those switches before pushing, coffee drinkers!
You want the "War Game" telemetry to count for the "War" design, but you can't really tell which is which without having additional data that you shouldn't be allowed to see. If you detect "casual user" and "programmer" modes in your OS, the user shouts, "I don't want my computer knowing (and sharing) that much info about who I am!"
Even though most people aren't likely to ever need to use a fire extinguisher, you really want that interface to be simple and accessible. If you decide that because no one ever used this particular fire extinguisher, it doesn't need to be there, that's a decision that could make the difference between life and death. Moving a button on a form doesn't seem quite that serious, but it could still cause people to lose time or money, which adds up across all the people using the software.
You need to determine which feature to add:
1. One that 3 developers asked for
2. One that 6 developers asked for.
With telemetry that can become:
1. One that 3 developers asked for and can improve things for 60% of your userbase.
2. One that 6 developers asked for, but only 12 of them are using the function that it will improve.
Without telemetry data, you are playing with an arm tied behind your back.
If anything we had the problem of them not being obscured enough for a while (if the story of the launch codes being 00000000 across the board is true).
Monitoring which features I use? Opt in.
Monitoring what I do? Uninstall if possible.
*Customers may not be granted access to UX data
Would that be the "Go up to the parent directory" button that was removed in 7 by any chance?
Since we all know the famous "Open Source is cancer" reign of Balmer oft-joked of here, I assume the related issue at hand is culture shift is good and less of a concern now, as opposed to a few years ago. But I am super happy when people like you drop by.
How do people like us on HN, Reddit, and Ars get you and those like you to say, see daveguy's manager[s], we will reconsider our avoidance of the MS tech stack because how daveguy did X?
Is this silly? I am not sure. But I wonder if I am the only one who wants people like yourself to thrive so MS keeps going in this direction.
A lot of products have UserVoice set up, a lot of dev product teams (dotnet, asp.net, etc.) are looking for GitHub issues.
For Windows 10 I'd recommend using the Windows 10 Feedback Hub - if you hate something about Windows 10, post feedback in the Feedback Hub before you uninstall it.
Visual Studio has this page that explains where best to submit feedback / bugs / feature requests: https://msdn.microsoft.com/en-us/library/b8akas30.aspx
There are lots of us who see your comments on HN / Reddit / Slashdot / etc. but having been part of the Microsoft ecosystem (both inside and out of Microsoft) for many years, I can tell you that there's a huge difference between "I've seen some unhappy comments about X" and "Our feedback numbers show 68% of users want us to improve feature X". Also, specifics are important - a detailed issue report with repro steps and recommendations for what you'd like to see work a whole lot better than "@drunkvs LOL VS suxxxx ikr!!!"
Also, just because I'm an ocd fact checker, Ballmer technically didn't say "open source is a cancer". He said that Linux is a cancer, referring to the strong copyleft license requirements (https://web.archive.org/web/20011211130654/http://www.suntim...). [yes, I very well know that you can run software on Linux without that software being GPL. I'm writing this from Red Hat DevNation :)]
Regardless, I can tell you that our current CEO and everyone I work with is excited about writing great software that runs everywhere.
And yeah, that cancer line was meant to snarky and cute, not factual. It does not really matter more than me indicating the obvious, that this is a big culture shift if you look at the timeline. I think MS has ways to go too, and the long game is where we will see how it fares, but I want to make sure we encourage the good. Or it will languish, as "no one cared after a while."
If you look at any of the projects that are on GitHub now, the public issues list is the issues list. You can see all the dev comments, scheduling via labels, pull requests, code reviews, etc.
For products that aren't on GitHub, public issue lists like UserVoice have still been a big improvement (in my opinion) because they usually keep the bugs / issues / feedback around until it's fixed, and the votes accumulate so the important issues keep bubbling up.
I posted this because I thought it was an interesting and relevant part of the announcement. If MS was this straightforward and transparent with Win10 (allowing easy disabling of telemetry and the option to control upgrades at all levels) then I wouldn't be looking at alternatives. Although off by default would be better, but they would get approximately zero feedback with that. Best would probably be ask on install with a checkbox easily unchecked.
Whoever decided their .net tools telemetry and messaging needs to be in charge of that aspect across all products.
And you and I check Github. That does not mean anyone being engineering managers care. I am curious what else we can do beyond starring GH repos. I do that, I just do not like my lazy armchair form of support and worry I will lose a culture shift at MS I have quickly fallen in love with after years of reviling the company as a whole, short-sighted or not.
The person that had poked in was iirc, and Azure developer in MS, not from the MS-SQL team. There are plenty of developers at MS that do follow various GH projects (as happens everywhere else) and will get the right people involved when they see things.
I would presume that by pushing these kinds of projects (.Net Core, etc) out to github, and even the documentation likely won't see things close off any time soon, and not without losing more mindshare than Oracle has caused people to move away from Java.
They are being quite open about it and how to turn it off.
However, the option to disable on install (checkbox prompt for preference) would be much better. This is an improvement over the Win10 approach.
Microsoft is by no means an example of sainthood, but many in the HN community tend to only criticize it, while closing the eyes to similar actions of companies that are closer at heart.
It's the same with VS and VS Code (and Atom too). There has been a move from opt-in (for older versions of VS) to opt-out. Although I do still see connections to MS domains with all the customer experience stuff turned off.
It was still a little rough: the "getting started" instructions ONLY worked on Ubuntu 14.x and not Ubuntu 16.x, and my PR to the documentation pointing this out was nixed. (I notice they've since added a disclaimer: https://docs.asp.net/en/1.0.0-rc1/getting-started/installing...). I really hope to someday be able to build projects with React and a .NET core WebApi and be confident that my teammates will be able to get the project running on their macbooks without kms.
There are only two hard things in Computer Science: cache invalidation and naming things.
There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-1 errors.
Hopefully Jetbrains will release their cross platform C# IDE sometime soon. I would prefer Visual Studio, but I don't think that's going to happen (at least not anytime soon).
I may also be a bit biased since I contribute to VScode extensions. But I see that as a positive. I use a free editor that I can hack, look at its source and collaborate in the open.
That's fine, but let's not think that this will produce tooling anywhere nearly as refined as C#'s stuff. Take F# interactive v the C# one. F# has like a decade lead. Yet the C# interactive editor is smooth, polished, even has VS project integration, something the F# team had thought of doing many years ago.
Non F#-team members have said that internal politics are the issue here. To the point where some books were ... edited ... to paint C# in a better light, relatively. MS's marketing reflects this. My guess is they're too proud to admit their flagship language from their high-profile hire was shown up by what was a research project. And that the CLR's arguably biggest tech advantage over the JVM (generics) was also only done through the intense efforts of MSR; that MS Corp was against it.
It's sad, because MS is in a position to really elevate the world's programming consciousness/ability by really promoting F#, yet it's still a novelty for, as MS has said "scientific and engineering" applications. Yet, apart from tooling/legacy, F# handles every case C# does in a better way. At worst, it's C# with lighter syntax.
Oh well. At least it's there, works, and has some level of support. Only reason I consider using .NET these days.
1: The F# folks are amazingly polite and I've never heard them even hint at a complaint about MS.
> too proud to admit their flagship language from their high-profile hire
That's acute while we know that high-profile hire's past victories (Turbo Pascal, Object Pascal, Delphi) were never about the language, but about incredibly polished IDE, compiler, libraries and runtime.
> yet it's still a novelty for, as MS has said "scientific and engineering" applications
MS marketing wisdom is overrated, to say the very least. Look at Tablet PC. Windows XP Tablet PC Edition released in 2001. Ink APIs are all way through Windows SDK since back then. And they never realized that stylus thing is something more than just a 'uhm, you can draw a kitten, maybe?'. At least they never articulate anything more than that in any promotion campaign. And now Apple released iPad Pro and will eat the TabletPC-Covertable-Surface market.
fix is in progress ( https://github.com/Microsoft/visualfsharp/pull/1290 ) probably tomorrow, it's not a big problem one or two days of delay. Also because that's an sdk issue (preview2) not of .NET Core (rtm)
The f# support is in beta, c# was ahead obv, but that's ok i think, it's used as the language for the corefx, etc. vb is not working at all atm.
The .NET Core sdk preview1 worked ok ootb, see for example the https://github.com/SuaveIO/Suave-CoreCLR-sample working xplat (win/ubuntu/osx/docker). And the preview1 continue to work.
What i really like it's how the sdk it's evolving, using modularized components it's possibile to fix/improve/evolve the f# compiler/library, without waiting a new version of sdk. That's really good.
In the next sdk or rtm also the `dotnet new` it's going to be updatable, so np about template too
new console/lib templates are going to be published (with the fixed fsharp compiler/library package), that's all.
Kinda like announcing your new line of cars is ready for purchase today! Except that down in the fine print you might find out that the engine is ready to go, but the steering wheel, headlights, dashboard, and pedals are all still in development and so it's justifiable that they're broken.
I use it, and i think it's ok.
The sdk it's just a build system. the real value is the .NET Core, that mean the coreclr (the virtual machine) and the foundation libraries (corefx).
I can change the build system one month from now, to build a project using the old packages.
It's not a car (engine vs wheel).
It's more like food vs marketplace. the food it's the real deal, the markeplace may be incomplete (no parking).
Known issues will also be updated, as will documentation on how to use F# on .NET Core.
.NET Core = portable subset of .NET Framework. Therefore not entirely compatible with .NET Framework.
ASP.NET Core = portable rewrite of ASP.NET. AFAIK not fully compatible with previous versions.
Not that they're alone. Adobe did worse with "Flex" since it could refer to the compiler, a framework, and an editor at one point until they decided to make it a bit more standardized.
.Net core apps should be a portable application (portable as in the runtime is compiled in)... Yeah, it is a little confusing, and hopefully removing some of the separate terminology will help. A lot of what has changed, is that you will likely be developing .Net Core (or Xamarin apps) that will target a given platform for running in... Most of the rest should be cross-platform modules that install via nuget (platform/language package manager) and bundled with the application output.
That's not saying much; "Java" means so many different things it's enough to make your head spin. At least these days it isn't a stock ticker symbol any more.
> Do I need the Java runtime environment, the SDK or the browser extensions to run this code?
It's not really confusing.
The Runtime is required to run code. The Source Development Kit (SDK) is for development, and the Browser Extension is for running browser extensions.
For me the sweet spot will be when .NET Native becomes more mature and I can get Delphi/Modula-3 back.
You also have RAD development on .NET.
Although .NET always had AOT compilation via NGEN, it always depends on the runtime being available at OS level.
With .NET Native it is like things were on PC before JVM took off, with strong typed system languages like Delphi and Modula-3 that compile directly to native code.
I know one needs a bit of imagination to make the comparison, but it is how I like to think about it.
If you using COM or third party dlls, which is quite common on Windows, then you need those as well.
I think that .Net would be much better if they had this kind of focus in dev side from the start.
*Hides from the f# mafia.
.NET supports proper multithreading (no GIL) and it is also much faster than CPython.
If IronPython gets ported to .NET Core (maybe it already has, I don't know), then you'd get those benefits for free.
I never found platforms like .Net and Java to be low level enough to write systems software, where you'd definitely want multithreading, and not high level enough to be as convenient as Python.
I write in Python and then use PyPy for more CPU intensive services. If I wanted multithreading and instances won't cut it, it would be a pretty hardcore usecase (for a lone wolf like me), I'd most likely also need no GC so I'd reach for something like Rust rather than C#.
I hate to say "no" to learning anything, but to be the devil's advocate this is how I've always seen it.
Having said that, there is probably very little reason unless you're just doing it out of pure interest.
It's really just a copy of their informational web site content with articles by different authors, but still very conveniently combined into a single PDF useful for printing etc.
I have been looking for something like this!
The major differences between .NET Core and the .NET Framework: [...] APIs — .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are different; type shape differs in key cases). These differences currently typically require changes to port source to .NET Core.
While I understand the motivation, this at first sight looks like something that will be with us for a long time, and could make life more difficult especially for library authors, who need to potentially target both 'platforms'.
[Disclaimer: haven't used .NET technologies for a very long time and might be horribly wrong here]
Edit: Debugging works now for me, after the .NET Core Debugger was automatically installed in the background!
It's code "purity" over usability. It's putting the core dev team's principles over their customers actual need, completely violating KISS, DRY and YAGNI.
DI really is our generation's factories. I'm already seeing projects written by people who don't understand it making utter nightmare spagetti code, worse than any code I've ever seen.
It's nasty scaffolding code which is a symptom of limitations of the language, definitely not code anyone should ever actually be wasting time writing.
Instead of recognising it's a flash in the pan, the core team have embraced it and are trying to force it down everyone's necks, and a lot programmers simply don't get it and are making an utter mess instead.
Then maybe those programmers should go back to JS ES5?
I'm more of an outsider now, as I've been doing far more node/js dev lately than .Net ...
I tried Wikipedia, and Microsoft's own homepages for each, and am even more confused.
I'm a hierarchical thinker, and a hierarchical tree explaining the above would be very very helpful.
Disclaimer: I haven't downloaded any of these yet. I usually don't until I've understood something.
.NET Core = cross platform software development platform. Includes a VM, compiler, tons of libraries.
ASP.NET Core = HTTP server + server side .NET libraries.
There is no ASP.NET Foundation, it's all part of the Dotnet Foundation.
Xamarin = .NET libraries for mobile development. Wraps Android/iOS native libraries.
Visual Studio = native Windows IDE for .NET and other languages.
You probably want Visual Studio Code for HTML/PHP. But you should check out .NET Core, it can replace PHP.
By the way, if it works, it works, but I find it better to research and do at the same time. Downloading only after you've understood the org chart seems a bit too radical for me :)
.NET Core is as the name says, just the "core" of the .NET Framework, the part that's cross platform. However, I'm not sure that at this point the code's common, I believe at least a part of it has been reimplemented. I think that in the future .NET Framework will be based on .NET Core. Therefore .NET Framework will be .NET Core + Windows specific bits.
WPF is the fancy name for a .NET UI toolkit for Windows, basically. Think of it as a Windows-only GTK.
The C# development I've done was... fine, but that was seven years ago and it's like Java in the sense that it's an amazingly complex thing to grasp and keep up with. Understanding how everything is layered is pretty complicated at this point.
* Also, see doc here (last updated in feb though): https://github.com/dotnet/coreclr/blob/master/Documentation/...
* Laslty, FreeBSD arrived on azure last week, so it would be quite surprising if support was dropped.
And the download page for .NET Core 1.0 doesn't mention FreeBSD at https://www.microsoft.com/net/download#core
I could see why others might see .Net Core as a parallel product as opposed to a new one.
Overall I think it's a good move just a little confusing (unless I'm the only one) for those who have done .Net work before.
against Java --
against Node.js --
against Python --
Check the cpu secs and cpu load; check the source code.
against Go --
They have a team who does it all for fun and has an impressive testing environment build out. Fascinating to listen to given today's new. I listened a few weeks ago myself.
I have friends at work who liked C# and moved on to frontend. The fact they are so less interested in .NET now is amazing to me as I finally want them to teach me to use ... on Linux!? I never thought I would say that. Haha.
More elaborate front-end was inevitable. That being said, I love their content and only really interact with their work through an Android podcatcher/audio client.
"We used industry benchmarks for web platforms on Linux as part of the release, including the TechEmpower Benchmarks. We’ve been sharing our findings as demonstrated in our own labs, starting several months ago. We’re hoping to see official numbers from TechEmpower soon after our release.
Our lab runs show that ASP.NET Core is faster than some of our industry peers. We see throughput that is 8x better than Node.js and almost 3x better than Go, on the same hardware."
I've started a support matrix project at https://anclafs.com. Feel free to file an issue or send a PR on GitHub.
> “dotnet-dev-osx-x220.127.116.11-preview2-003121.pkg” can’t be opened because it is from an unidentified developer."
I know full well how to get around this, but it makes me suspicious of what I've downloaded. Would Microsoft have truly missed this?
BTW you can ctrl-click/right-click the installer package and select open to get the option to run it without fully disabling gatekeeper.
Lee [.NET PM]
and an issue here
CatLight is one of the apps that do that - https://catlight.io
ETA: Other than not cross-platform. Other option is Xamarin.Forms and would be useful to see more Xamarin.Forms targets.
and looks like there's a forms mac branch being somewhat worked on: https://github.com/xamarin/Xamarin.Forms/tree/mac
I'm planning to run my future ASP.NET MVC projects on Linux and very much would like to know if a better SQL Server Express / Community Edition is coming or do I need to move to PostgreSQL (which I have already started looking into).
"A customer who buys a SQL Server license (per-server or per-core) will be able to use it on Windows Server or Linux. This is just part of how we are enabling greater customer choice and meeting customers where they are."
Same editions, same prices.
Sad to hear about that though. I was hoping for a break. Will just have to continue reading that PostgreSQL book I've already started.
But I can't seriously build a complex product around SQL Server knowing that 10GB is the sky for my database.
Starts at 0930 local.
But still very good news I personally love .Net it's nice to be able to use it cross platform without having to work specifically around mono.
It's also not clear which instruction sets they are going to be aiming for Exynos started with ARMv7 + all the stuff that Samsung added to it, but the newer ships are ARMv8.
The Raspberry Pi still uses ARMv6, 7 and 8 depending on the exact model with the newer RasPi compute, and Zero models still running the old BCM2835 ARMv6 CPU's.
So I'm hoping for a more or less clean stock ARMv7 and ARMv8 builds for the .NET core coming out sooner rather than later, I also hope they'll release the X86 version to more platforms than Windows since running it on something like an Intel Edison which comes with a 32bit ATOM CPU will be quite cool.
For anyone asking this question and not getting a sufficient answer, the safe route would be "build from source, then distribute that".
apt-get install dotnet-dev-1.0.0-preview2-003121
I'm afraid this is just too late to make a big dent. C# is nicer than Java, but not that much nicer to warrant switching over or rewriting your stuff in a very immature eco-system.
Maybe they're hoping to capture some of that elusive start-up market- and mind-share? That one is already pretty hostile towards MS...
Either way, this is a good thing, I just wish they had done this in 2005 or so.
Especially as the tooling for micro-services and docker (or similar) gain traction moving forward. C# is pretty well supported, and at least here in Phoenix is about as common as Java is... can't speak for other metro areas.
I've been a pretty big node.js fan, and haven't used C# as much the last few years, but I wouldn't count it out. Two years ago, C# wouldn't have been on my radar for a new project, now it's entirely possible, given the opportunity for better cross platform deployments.
for comprehension is the equivalent of LINQ syntax which is nice, very powerful when working with asynchronous calls.
Higher Kinded Types combined with implicit parameters are the two aces in the hole that make it an asbolute definitive win when heads up against C#. When I had to switch back to C# in my last job (some projects were scala, some C#) this was what I missed the omst. Combining the two gives you the 'type class pattern', which is pretty much the first time i've actually seen composition and code sharing just work without the cruft of an 'OO' like framework.
There's a lot to be said about the huge amount of value in the main maven repository vs. what's in nuget.
Java's decade long head start in that area doesn't seem so huge when you look at what the node.js community has put together in only a few years.
If you were considering .net on a new project, however, I would probably recommend comparing something like Scala. Scala has the benefits of being a "modern" language like C# with the full support of all or nearly all of the existing JVM projects.
That being said, there are a growing number of reasons to choose .net on non-windows platforms.
When I go on Maven Central I expect every library to be cross platform except for those marked as platform dependent.
For Nuget... all bets are off for now. It's the exact opposite, I assume that things are not portable or at least have not been tested on say, Linux.
It's easier to follow than to blaze a path. We have learned from Java and can, hopefully, avoid those pains.
- Does .NET Core offers something similar to Go goroutines or Erlang "lightweight" processes?
- And something similar to gofmt?
2. There's https://msdn.microsoft.com/en-us/library/ff926074.aspx + your favorite IDE which can automatically reformat the code. Visual Studio can do this. If you want to enforce things, there's: https://stylecop.codeplex.com/
Not quite the same thing, but F# has the MailboxProcessor<'T> type which is conceptually similar to Erlang processes and can be used in the same way.
Then there's `async`/`await`, which is built on top of tasks.
I believe that it was abandoned as a supported scenario a while ago, though. But you can still see artifacts of that in the docs, e.g.:
"The value of the ManagedThreadId property does not vary over time, even if unmanaged code that hosts the common language runtime implements the thread as a fiber."
The overhead in terms of memory is the internal state of each Process + the user's Process state. To see the internal overhead, check out the member variables for the Actor class .
It's pretty lightweight, although could probably shave a few bytes here and there.