runfaster2000

The post clarifies that everything will be open source. We use a combination of MIT and Apache 2. MIT is our default license for new code.

IPC is already supported. We have no plans to support WCF (as a server) on .NET Core.

Like this: https://docs.microsoft.com/en-us/xamarin/android/get-started...

We haven't made a decision on .NET Standard yet, in terms of what its role will be going forward. Major point is that its forward-looking role will be significantly diminished with this plan.

There are not really any yet. We intend to take the Java interop that Mono already supports, improve it as needed, and make it available to other scenarios beyond just Android. If there are certain things you would like to see, I'd love to know.

.NET team member here. We haven't invested any effort into this particular benchmark. We're happy to invest in benchmarks that have well-defined (and enforced) rules on entries. Our understanding is that the "game" part of "benchmarkgame" is appropriately descriptive. We have put a lot of effort into the TechEmpower benchmarks.

In terms of .NET performance, we've made significant improvements [1] with each release. If there was a gap between C# and other languages before, it is likely that it is much smaller now due to our efforts.

We have a balanced view on performance. We are investing in application throughput, latency, memory usage and disk footprint. Most .NET users care about multiple of those things. We also hear from users who care disproportionately about just one of them. This motivates us to care about all of these things, although throughput and memory usage is where the biggest gains are.

I have this (not very good) joke that many .NET developers until recently would not have been able to accurately describe what structs were (as opposed to classes). To a large degree this was because we used them in very narrow ways in the products. That has changed a lot in the last few years. ValueTuple, ValueTask and Span are all good examples. The culture of the .NET has changed and so is the .NET community around us. This will result in higher performance code more generally within typical .NET applications (as opposed to some theoretical outcome). If this happens, and I do believe it will, .NET will be forever changed in a pretty radical (or at least "rad") way.

[1] https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performan...

Partially true ..

> Open source doesn't mean open development and liability & commitments.

Right. We are stating up-front what we intend to achieve. We will sart with making WPF on .NET Core have parity with .NET Framework and then expand from there. We'll stick to Windows as the OS for the project.

> The purpose is to literally make the source public but they don't have resources to make a long commitment.

We are not saying that. We intend to continue working on WPF. In fact, we are talking about moving some of Microsoft's 1st-party apps to WPF on .NET Core, just like how we're moving 1st-party web sites/services to ASP.NET Core and .NET Core. Same playbook.

Much of the context is in dotnet/coreclr #13388 [1].

At the risk of repeating the content of the blog post ... The issue was reported in August, 2017 and fixed later in the same month. The fix shipped in a .NET Core patch update in September. We attempted to get the fix into .NET Framework 4.7.2 but missed that scheduling. We're now looking at making the fix in a .NET Framework patch release.

[1] https://github.com/dotnet/coreclr/issues/13388

Few points:

- Deployments: https://www.microsoft.com/net/customers

- Monthly engaged developers is >500k for NET Core.

- >50% of developers are on Windows.

It depends on your app. We've seen massive improvements for webservers and long-running apps. Short-lived apps don't benefit. We'll be posting more on it soon. Give it a try!

Sorry! Poor wording on my part.

I updated the wording to: "Much easier to manage .NET Core and ASP.NET Core versions in project files and with self-contained application publishing."

The thing that you are talking about still needs to be improved. Sadly, that didn't happen in this release.

Correct. Most developers will not deal with it much directly, particularly not in the way that it is used in the "guts" of the product.

No relationship to the 18.04 LTS, but we were following that release closely. We started testing on 18.04 at the start of the year, and offering Docker images for it at around the same time. We're also watching the Alpine 3.8 release closely.

Some apps might run completely unmodified, but that's not really our plan. We intend for folks to update their apps to target .NET Core 3. We intend to support all the APIs that we find that client apps use. We're not including ASP.NET Web Forms, for example, but we'll definitely be supporting System.Drawing.

We've already shifted to putting more effort into the .NET Core project. The last few .NET Framework releases have been pretty targeted. That trend will continue. We'll continue adding existing .NET Framework APIs on Core to make it so that devs can move more and more apps to .NET Core. That's the basic plan.

From the post:

* Desktop applications will need to target .NET Core 3 and recompile.

* Project files will need to be updated to target .NET Core 3.

* Dependencies will not need to retarget and recompile. There will be additional benefits if you update dependencies.

Disclosure: .NET Core team member and blog post author.

Windows-specific features are not really "creeping into .NET Core". WPF and Windows Forms will be components that layer on top of the .NET Core runtime. If you want to use them, you will get them. If you don't want to use them, you will not. We already have precedent for that with the Windows Compat Pack [1]. We also have significant platform-specific implementations already [2].

We think developers will like the idea that they can take advantage of OS-specific functionality. We will look for more opportunities to do that on macOS and Linux, too. If we were ever to support the macOS Cocoa API, it would layer on top of the .NET Core runtime, too.

Does that help?

[1] https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcin... [2] https://user-images.githubusercontent.com/2608468/39717763-1...

Excellent point. There are two major caveats today:

- no removal of native code. - no removal of code from the base managed assembly.

We would like to fix both and both are a large win.

We currently have no GUI story for .NET Core. At the point that one gets added, yes, this will totally work.

See my comment to the grandparent comment on our approach to only including common command strings (which wouldn't include anyone's AWS key). Also, and more importantly, we will only collect known arguments. From the blog post:

> Only known arguments and options will be collected (not arbitrary strings).

We don't want your AWS secret key in this data as much as you do. We have put systematic mitigations in place to ensure that this doesn't happen.

Hi. Team member here. We used a simple algorithm to prevent that. We essentially got the data itself to vote on what a real command was for exactly this reason. This means that a lot of people typed "bulid" since the vote passed on that one. I don't have a count, but many rows were not included in the data since they didn't pass the minimum threshold for being a real command. Imagine you spelled "build" backwards for some reason. That would have been quite uncommon.

We haven't spent much time with those benchmarks. We looked at a couple of them and believe that there are better ways to write them in C# and get better results. That's not FUD but our findings.

This is a great community activity. Clearly, the community is more than capable of performance enhancements, based on the improvements they have made in the product.

If people start improving the C# benchmarks, please file an issue on dotnet/core to get feedback and some cred. We may do another blog post on that if there is some gravity around the activity.

BTW: Your friends can also contact me -> rlander@ms

See: https://github.com/dotnet/designs/issues/2

I was personally involved in the publishing of this post. The timing of this post and the Apple event didn't even register with us as interesting. We're an engineering team and have zero interest in cross-company tactics like that. Now, if there is an LLVM release you want to tell me about ... ;)

Sorry to hear that. I suggest calling support. Cross-org bug routing isn't super easy.

Point taken. We have some improvements to make on this front.

Correct. Performance improvements are out of the scope of the standard. Much like how the HTML spec doesn't tell Google and Microsoft how fast their browsers need to work.

From the post:

“We expect that many of these improvements will be brought to the .NET Framework over the next few releases, too”

We still need to ensure that all the changes are behavioral compatible. Other than that, we are intending on improving the .NET Framework as well with these same performance investments.

Adopting and porting to .NET Core will become a ton easier, later this year. .NET Core 2.0 will add a ton of .NET Framework APIs.

These APIs are almost entirely coming from .NET Standard 2.0. See the jump in APIs in this table[1].

We often get asked if this is going against the promise of a light-weight development platform. Answer: not really. The new APIs are not being added to a single library, but several, including new ones. We will be updating our publishing tools to make it easier publish apps w/only the libraries you need. We are also looking at going one step further, which is publishing only the IL you need (intra-assembly optimization).

I am spending the week presenting at two Microsoft conferences in Europe (Milan, Amsterdam). I heard very similar feedback on EF yesterday in Milan. I will be passing this off to the EF team.

FYI: I'm a .NET Core team member.

[1] https://github.com/dotnet/standard/blob/master/docs/faq.md#i....

Was looking through our alumni magazine this weekend. This section [0] really caught my attention. Massive props to the Prof. That said, seriously nice donation.

"In 1984, Digital Equipment Corporation (DEC)’s donation of $24 million provides the University of Waterloo with eight new VAX machines — on the condition that work created using the machines would be the property of DEC.

Wes Graham, a professor of computer science, stopped the shipment until the company agreed to Waterloo’s policy of leaving intellectual property in the hands of its inventors."

[0] https://uwaterloo.ca/magazine/fall-2016/feature/60-years-inn...

The tools story that you raise is a real challenge, for users and for the team. I agree with you. As we were reaching RTM, we realized we had gotten ourselves wedged, pretty significantly. We had fortune 500 customers in production on our pre 1.0 RTM betas who were pushing hard for a 1.0 RTM runtime stack. At the same time, we came to the conclusion that the tools were not ready and needed significant changes (many of them breaking, as you call out). We decided to ship the runtime as RTM (now twice) and leave the tools in preview. The customers who were pushing hard are now happy (modulo the tools changes) and we're continuing to push forward.

If we were to do it all again with the knowledge we have now, we would skip all the changes and move directly to the final plan. We're sad about the resets, both to our users and because we were not nearly as efficient as we could otherwise have been. We're now on a much more solid plan and are working to land it.