runfaster2000

9 ms·

31.
by runfaster2000 7y ago
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.
32.
by runfaster2000 7y ago
IPC is already supported. We have no plans to support WCF (as a server) on .NET Core.
33.
by runfaster2000 7y ago
Like this: https://docs.microsoft.com/en-us/xamarin/android/get-started...
34.
by runfaster2000 7y ago
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.
35.
by runfaster2000 7y ago
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 lov
36.
by runfaster2000 8y ago
.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
37.
by runfaster2000 8y ago
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 t
38.
by runfaster2000 8y ago
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 Sep
39.
by runfaster2000 8y ago
Few points: - Deployments: https://www.microsoft.com/net/customers - Monthly engaged developers is >500k for NET Core. - >50% of developers are on Windows.
40.
by runfaster2000 8y ago
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!
41.
by runfaster2000 8y ago
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 need
42.
by runfaster2000 8y ago
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.
43.
by runfaster2000 8y ago
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 c
44.
by runfaster2000 8y ago
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 AS
45.
by runfaster2000 8y ago
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 th
46.
by runfaster2000 9y ago
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.
47.
by runfaster2000 9y ago
We currently have no GUI story for .NET Core. At the point that one gets added, yes, this will totally work.
48.
by runfaster2000 9y ago
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: &g
49.
by runfaster2000 9y ago
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 o
50.
by runfaster2000 9y ago
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
51.
by runfaster2000 9y ago
BTW: Your friends can also contact me -> rlander@ms
52.
by runfaster2000 9y ago
See: https://github.com/dotnet/designs/issues/2
53.
by runfaster2000 9y ago
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
54.
by runfaster2000 9y ago
Sorry to hear that. I suggest calling support. Cross-org bug routing isn't super easy.
55.
by runfaster2000 9y ago
Point taken. We have some improvements to make on this front.
56.
by runfaster2000 9y ago
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.
57.
by runfaster2000 9y ago
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 im
58.
by runfaster2000 10y ago
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
59.
by runfaster2000 10y ago
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 p
60.
by runfaster2000 10y ago
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

More ›