I'll be honest, as much as I love the improvements with .NET Core/.NET Standard, Microsoft's branding strategy leaves a lot to be desired.
vNext has already been historically used in the context of ASP.NET to refer to ASP.NET (not to be confused with ASP.NET MVC) v6. We restarted the versioning back with ASP.NET Core, now on version 2. Entity Framework used to be a .NET framework component but is now standalone, and has a Core version? Does Blazor (or is it Razor Components now) share the .NET branding?
Separate to the web stuff, we have the .NET platform - .NET framework is the non-cross platform version for which we're on version 4, but it implements .NET Standard v2 along with .NET Core, which has a Linux runtime. Mono also implements .NET Standard v2 and has a Linux runtime.
I remember many years ago when we also had Microsoft .NET Passport.. which was completely unrelated to everything else that I've mentioned related to the .NET brand.
And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?
> And now we have .NET 5 which is neither Framework nor Core
Just to note, the blog post explicitly says that .NET 5 is the next version of .NET Core. It's where .NET Core is going, and given that so much more of the .NET "picture" is being realized with it, the name is changing to be more reflective of the fact that it's not really a "core" (small) thing anymore.
Yes, indeed. But will that change also apply to the other projects that target .NET Core (now ".NET")? Will Entity Framework Core become Entity Framework and clash with the 'full-fat' Entity Framework? The blog post suggests this won't happen by referencing ASP.NET Core 3.
And where does this leave the legacy .NET Framework? It reads as a sub-project of '.NET' (previously .NET Core) but it very much isn't because it provides a set of older APIs. We seemingly have two meanings for .NET now, referring to .NET Core (which I guess only applies when suffixed with v5+) and the wider array of .NET projects, whatever they are.
I missed that, and that would be a pretty big deal. I thought the message was of a side by side evolution, with full framework getting features possibly with a delay.
Well, it is not really the case, there will be still two frameworks, just one isn't going to be developped anymore (full .net 4.8). The way I read that sentence initially was them merging the two into one.
>Well, it is not really the case, there will be still two frameworks, just one isn't going to be developped anymore (full .net 4.8).
If "one isn't going to be developed anymore" there there will be just one framework.
"Being" here means what's the official worked-on implementation. Not merely existing, obviously the code for 4.8 wont go anywhere, nor will existing deployments suddenly vanish.
What they are saying at MS Build is 4.8 will be supported "forever" because there is too much code depending on .NET Framework, but new feature development is going into .NET Core 3+. By the time they reach .NET 5, they will have unified .NET Core, .NET Standard and Xamarin. They are skipping version "4" to avoid confusion with the second .NET Framework 4.8.
I took "forever" to mean that they would still be issuing security patches to 4.8, for example. Given all that I don't know why you're insisting on phrasing it like that. There is only one future, sure. But you seem to be making it sound like 4.8 has a planned obsolescence date or something and Microsoft is saying the exact opposite.
When 4.8 is installed, 4.7 is going away. Here .net 5 will not replace .net 4.8, it will exist side by side (if I understand correctly). That's two frameworks to me.
The VB6 runtime is still installed on Windows 10, but no one (should) considers that a viable Framework to target in 2019.
Maybe a better analogy is that .NET Framework 1.x and .NET Framework 2-4.x are side-by-side installed still in Windows 10. If you wanted you could still target .NET 1.0 and it will run in an entirely different runtime (.NET 1.x and 2.x are hugely different). .NET was designed for that sort of side-by-side deployment, they just haven't done it in a while.
Yet I've not met a developer that still sees .NET 1.x as a viable Framework recently. Do you want .NET 4.8 applications to just break? What do you expect here? The "current framework" is always a combination of marketing and support and this article seems pretty clear that all marketing and support effort will be on .NET 5, and .NET 4.8 is "done".
Yes, major versions install side-by-side (except v2-v3) because they aren't perfectly backward compatible and this is necessary for legacy app support. So, you can need all of .NET Framework 1.1, 3.5, and 4.8 now, and in the future .NET 5.x is added to the list.
You can have .NET 2 or whatever older on the same machine too.
Doesn't change the fact that .NET 5 will be the single official .NET release onwards, where development efforts will be concentrated, etc. It's not like MS will support 2 different frameworks (except one as a legacy release).
All the desktop stuff is only on Windows though, right? If I'm not mistaken this is the first major .NET Core component that is not cross-platform, which is confusing in itself.
They explicitly won't support cross-platform efforts for the GUI stuff, as stated on GitHub (though maybe, one day ...).
I suppose their rationale is damage control ("Okay, they get the server, but the desktop is still firmly ours"), but it would certainly keep me from starting a personal project with a Microsoft Framework.
At this point I'm guessing that it's because there isn't a strong future for desktop apps written in native code. Even VSCode is written on top of Electron. Good, bad, or indifferent I think that there isn't a lot of point in developing a native GUI framework at this point.
(To be clear - I'm 100% sure that there are a lot of use cases that I'm blithely waving away, but I'm also sure that those use cases are currently being addressed with WinForms, Qt, GNOME, etc, etc, so why should MS invest in Yet Another GUI Framework?)
I wouldn't mind seeing WPF, or a descendent, ported to other platforms. Xamarin Forms, Eto Forms, and a lot of other wrappers already do a lot of that though, if you want cross platform gui from .Net. (god that looks sloppy)
I also tend to agree that for good, or bad, that Electron will probably grow significantly as an application base. Like I see node becoming the defacto runtime for WebAssembly, I see Electron taking that place for WebAssembly + UI. And I don't think it's all that bad.
Even with MS, Electron seems to be their unified UI target for a lot of apps. VS Code, Teams, Azure SQL Studio (or whatever the name is now), and don't see that space shrinking. I'm only surprised that Teams doesn't have an official Linux version.
WinForms is outdated, "replaced" by WPF and I think apps on the Microsoft App Store have to use WPF instead of WinForms.
So it would make sense if they're pushing .Net Core to be cross-platform, that they want to eventually push the Microsoft App Store "buy" button to be cross-platform as well, with a GUI framework to support those apps. Speculation, but .. of course they will want to.
You can't publish WinForms or WPF applications to the Microsoft Store, they've both been replaced. It's only UWP or using MS's tooling to convert Electron apps to UWP.
Yep, I've semplified. What I understood from this post is that net framework is in "maintenance mode": probably MS plan a 4.8.1 with but fixes and maybe a 4.9 with some minor updates, but .net core (now simply .net) is the place where new things will be developed.
Nothing in the article suggests maintenance releases, but MS' history is probably enough for that. The article does definitely state that .Net 5 is the evolution of Core and will be the entire platform going forward. I'm, personally, glad to see Core/Framework/Mono etc rolled into a single version at 5. The previous split versions have been fairly confusing.
Fair enough - but the wealth of documentation for it will continue to exist, as will older applications targetting it. This seems problematic if you want to search for ".NET" (meaning .NET Core).
The post is a vision-setting announcement about where .NET is headed. The finer details like you've described will be worked out in the following 1.5 years.
If you're developing an application with a Windows desktop GUI, you're still doing it on full framework (WPF, WinForms, UWP). They're folding that into .NET 5, and I haven't seen anything indicating that they see that as "doing it wrong". This is only one case of developing for full framework, but it's a big one. I imagine any other cases where the developer community really needs full framework capabilities that still aren't ported to CoreCLR, they'll fold that in just the same as with the UI frameworks, as a Windows-specific capability. Maybe they end up sunsetting more than I think, but for now this seems more like consolidating Core and Framework than ending Framework.
Last time I tried to seriously switch from Framework to Core, I was dismayed to find that Assemblies could not be unloaded from memory in Core after they were loaded. That was something that depended on the AppDomain functionality, which existed in Framework only.
There are a ridiculous amount of first-party Microsoft SDKs for products they are pushing heavily that don't support Core yet.
Unless there is a newer version than last month, one of those is the Bot Framework extensions for Microsoft Teams, which they are just slamming ahead with.
Yes, the branding is terrible and has been for some time. It's good that most of it is merging but this is still years away and will create a lot of historical churn in its wake.
Even with the tremendous strides in tooling and docs, the naming and runtime complexity is the biggest hurdle in getting new developers to the ecosystem. Just about every other major stack has a far simpler setup. Even ".NET" is hard to search for.
> And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?
My understanding is .NET 5 is both. Previously .net framework and .net core were both implementations but also api surfaces. And it's my understanding that .Net 5 will basically "implement" both. So .net standard won't be necessary because if all implementations(.net core + mono) implement all the difference api surfaces then you don't need a "common" api surface.
So there will only be two implementations. Mono and .NET core which will provide all the same api surface as .net framework + .net core(and therefore .net standard).
.NET Standard will probably still be necessary due to the fact that Mono will still continue to exist separately thanks to products which embed it (such as Unity).
This vision structure paints Mono as "merging" into .NET 5 where the MonoVM will be a optional switch with CoreRT and the goal of MonoFX entirely dropped for CoreFX. It also sounds like they want to converge the hosting APIs so that products such as Unity may easily switch between MonoVM and CoreRT. At that point, if Mono is .NET 5 and Core is .NET 5 (embedders like Unity would move to embed to .NET 5), there maybe isn't really a need for .NET Standard.
The first two sentences of the article sum up the announcement and eliminates most of the confusion:
Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.
There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.
I think Microsoft has been guilty of what you say in the past but this announcement and their product offering going forward could not be more clear.
It is quite confusing and misleading to say "There will be just one .NET going forward" since this will not affect the .net framework at all - there will still be two incompatible platforms (4.8 and 5/core) for the foreseeable future. They just changed the name of one of them.
I think the problem with MS is they want a simple name change to look like some new unifying strategy. Developers would be much happier if they just cut out the bullshit and made it clear this is just a name change of .net core. The name change in itself is fine.
MS is just FUD'ing themselves with these confusing messages.
>It is quite confusing and misleading to say "There will be just one .NET going forward" since this will not affect the .net framework at all - there will still be two incompatible platforms (4.8 and 5/core) for the foreseeable future. They just changed the name of one of them.
Well, everything will move to 5. And the framework at 4.8 will stop being developed. And 5 ( Core, whatever you want to call it, ) is incompatible with the .Net 4.8.
Not likely. Many libraries (like web forms) will probably never be migrated. We will have two incompatible .net's for the foreseeable future. Changing a name does not change that.
That's right; we'll have two incompatible .NETs for the foreseeable future but only one will be getting new features. .NET 5 will unify Core, Standard and Xamarin/Mono.
In what way will this unify .net Standard with Core etc.? Or are you talking about a different standard?
I'm genuinely confused because the illustration shows .net standard as a layer between .net 5 and various platforms. But if that is the case, the platforms will not be able to take advantage of newer features, since .net standard is the API shared with .net 4.8. This does not seem likely.
Yes that's a good question. The situation today with .NET Core vs .NET Standard is: Standard is the common functionality that works in both .NET Framework and .NET Core. Standard continues to overlap more with Framework as those features are added into Core.
After .NET Core 3.0, MS said new features will only be added in Core. And when they reach .NET 5, Standard and Core will be identical, with "Standard" being the library you link to regardless which specific .NET implementation you're running on: desktop, IoT, mobile, etc. I believe the diagram only means that "Standard" covers all of .NET 5, not some subset of Core. And .NET Framework is a separate, maintained legacy library off to the side.
Note, I don't work for Microsoft, this is just my understanding from reading their docs and talking with them about it online and at MS Build.
I don't see how you reached that conclusion. Once .NET 5 arrives, there won't be any more concern with ensuring portability between .NET Core apps and .NET Framework apps by way of targeting .NET Standard.
.NET Standard will be only one thing, if they end up retaining the name at all. It will be the the interface to everything in .NET 5. .NET Framework will just be its own thing maintained only for legacy compatibility. After .NET Core 3.0, new development will not be added to .NET Framework.
I do agree with you that it would be clearer if they only spoke of .NET 5 and .NET 4.8 Framework versions.
> Once .NET 5 arrives, there won't be any more concern with ensuring portability between .NET Core apps and .NET Framework apps by way of targeting .NET Standard.
In the real world there are massive amounts of code in the .net framework. Because of the significant breaking changes between 4.x and core/5 it will take a long time before all this code is ported, and many application will probably never be ported, while still having to be maintained. So for the foreseeable future it is going to be very important whether libraries are 4.x compatible or not.
Consider Python had (IMHO) fewer breaking changes between 2 and 3, but still the migration took about a decade.
> In the real world there are massive amounts of code in the .net framework.
Right, I agree with everything you said here. That's exactly the reason why MS said at the Build conference that they will be supporting .NET Framework "forever". There is a lot of it out there and it will likely remain for a very long time.
When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away. There will be .NET 4.8 in maintenance mode and .NET 5 as the future, growth mode. Maintaining .NET Framework apps hopefully won't be a problem but if you're thinking of building a new app using .NET 4.8, you're likely making a big mistake unless it's to satisfy some immediate need that doesn't work on .NET Core. MS said they're committed to supporting people stuck in that position. Just don't expect new features that will appear in future .NET versions.
> When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away.
I'm really struggling to understand this. Can you explain how you would prepare to port a .net 4.x site to core/5, if the notion of a compatible intersection goes away? How would you even make a library which is compatible with both 4.x and 5?
If you are thinking of porting an old 4.x app but you wait until some time beyond Nov 2020 (https://i.redd.it/f8todfd66uw21.png) then it is in your interest to track the latest .NET Standard along the way. If you haven't been keeping the app up to date, say you're on 4.6.1, and then you decide you like .NET 5 and want to move to it, I think you'll just have to try it and fix whatever breaks.
This is pretty much like every other porting project where you have an old neglected project that you want to bring up to date. Maybe there is an easier way but I don't know what it is. Staying on the legacy .NET Framework isn't the end of the world, you're just committing to maintaining it as is. If you want new features as they become available, well... that's on you, don't wait.
Maybe you move some functionality out of your legacy GUI app to microservices written in .NET 5, parts that are unlikely to have any porting issues. In any case it's not like anyone is going to be surprised by what's going on. Maybe the community will back port some new things to .NET 4.8. MS will be devoting their efforts to enhancing the new platform while keeping the old one on life support. I think that's reasonable. (edit: typos)
Yeah all that is completely obvious. So why not just communicate honestly: This is a massive breaking change. It is going to be painful, but is necessary to moving forward. But don't deny the reality of it.
Saying .net 5 is unifying .net is like saying Python 3 unified Python or that Angular 2 unified Angular.
> If you haven't been keeping the app up to date, say you're on 4.6.1,
Again, why the dishonest arguing? 4.6.1 is years old, but you will have exactly the same problem if you are on 4.8 which was just released. It has nothing to do with code not being updated.
> where you have an old neglected project that you want to bring up to date
Again, this has nothing to do with projects being old and neglected. It is a breaking change, it will affect all projects on .net framework if they want to upgrade. And you know that.
I honestly fail to see what has been dishonest in the communications around this.
The plan for .NET 5 does, in fact, unify .NET Standard, Core and Xamarin. These will no longer be separate things but will go forward under one name.
I'm not sure what you're claiming as the _breaking change_. Can you be specific? It's not, in fact, going to break anything from what I can see. .NET Standard will simply continue to grow larger in .NET Core 3+ until it covers everything. This seems to me to be very different from the Python situation where you are (probably) forced to make code changes to compile with Python 3. If I have some code that compiles with .NET Standard 2.0, are you under the impression that it won't compile with .NET Core 3+ or .NET 5? If so, what leads you to think that?
OK, sorry I called it dishonest, that was out of line since it was assuming bad faith. I just don't think we can pretend .net framework doesn't exist anymore just because the successor is announced.
As I have gathered from talking to former Microsoft developers and evangelists, vNext is generally embraced to mean "the next great version", maybe primarily for developer centric stuff.
Personally, I've been hearing about MS Build vNext and TFS vNext for the last 8 years, and there's been several releases since then. Maybe that's why I kind of associate it with vaporware, even though that's probably unfair.
What would be a great naming schemes for retro fitting an open standard with a new, open implementation for a subset of the existing framework?
To draw an analogy to Debian, vNext is somewhat similar to Sid. The name is a moving pointer. In a Microsoft context, there is not an unstable connotation like Debian's Sid is.
vNext is a term used across much of the Microsoft ecosystem to denote the current WIP version of a specific technology. SQL Server vNext has pointed variously at what became the 2017 release and currently points at the 2019 release (and will soon point to the next release after that).
Excellent recall--I had almost entirely forgotten about ".NET Passport," one of Microsoft's many premature plays at being an identity provider. This certainly added to confusion at the time about .NET's actual form... something to do with XML, or web services? And an awkward new ORM that will definitely not become well-loathed in near-record time?
Given the embracing of other platgforms, and the convergance aspect of one .NET to rule them all. WHy they didn't rebrand it is a mistake they will probably end up doing if they want to pull in dev's on other platforms. Many who's exposure to .NET will be of a legacy flavour and maybe left a sour taste. A taste that will stick with them upon anything .NET.
I'd vote for .ONE, one API to rule them all.
Though convoluted does sell books, I'm sure we will see a title "When is .NET not .NET" soon.
"There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more."
This is remarkable, and impossible to predict from the Microsoft of 10 or 20 years ago. Satya seems to be the rare visionary CEO of a megacorp, instead of just defaulting to a defensive and reactionary stance like most other leaders.
My guess is that it's also at least partially reflective of how .NET's status at Microsoft has changed over the past two decades.
Remember 20 years ago, when .NET wasn't just a managed software development platform? It was a company-wide strategy[1] that was meant to encompass more-or-less their entire product line. The whole Microsoft future was .NET, and they were going to have a .NET edition of Windows, SQL Server, Exchange, etc.
Since then, those plans have been dropped, Microsoft's (.NET-based) preferred GUI toolkits, WinForms and WPF, were replaced by one that is .NET-compatible but not .NET-native, etc. etc. .NET just isn't as central to Microsoft's identity as it was 20 years ago.
Which, I'm guessing, means that the .NET team is now a lot freer to go cross-platform without inviting the wrath of the Windows team.
I think the initial ".net strategy" was just a (failed) marketing exercise. It was supposedly some kind of grand vision where the .net framework were just one component and SOAP was another. They certainly did not plan to base Windows or SQL Server on the .net framework.
They did try a number of times to write kernels in C#-like languages. Singularity, Midori, etc.
This spawned a lot of interesting academic work that influenced languages such as Rust... trying to get high level features and safety without need for a runtime.
You're correct. I'm certain that you're fully aware of Midori, but as you alluded to, a Microsoft Research initiative, but never was on the official roadmap. .Net itself has been a great success. I was completely sold on .Net Core and .Net 5 is exactly where they needed to take it.
He understand that Microsoft is a software company, and makes money selling software and software services. Steve Ballmer, for all his good attributes, was stuck seeing Microsoft as a Windows company, thinking everything had to relate back to Windows. Nadella understand that companies change or die. Ballmer just thought that meant finding new places to shove Windows.
I'm pretty skeptical of all the Microsoft praise lately, but if this is indeed true, it's a big deal. And probably a management feat somewhere (CEO or otherwise).
I worked on dev tools at Google and recall many efforts over the years to try to unify the customer experience -- between internal and external tools, Go and Dart, Android and Chrome devtools, etc. Things always lurched in one direction or another, but never consistently. It was always above someone's pay grade to choose one or the other, so you ended up with both.
Convincing engineers on devtools to abandon their babies is indeed hard!
On the other hand, I think if you dig deep, Microsoft still has all the legacy, but they cover it up with a lot of branding. Hence the top comment in this thread about confusing branding.
Older execs probably had to be defensive and reactionary because they had to protect their main source of income, Windows.
But it's clear now that 1) Windows has zero chance of taking a significant market share away from Linux in the cloud and 2) cloud technology is an important area of growth for MS.
Satya probably sees that stubbornly sticking to Windows just isn't going to work anymore, so it's better to play nice with the others.
> Office for Linux would be easy, but that’s not going to happen.
I have a hard time believing it would be easy. I use both Office for Windows and Mac, and the differences are great enough that I'm guessing that there's a huge amount of divergent code in the UIs. And both would be written against GUI toolkits that are not present on Linux, so a Linux port would be yet another major effort.
That said, I think that you're right that it's not going to happen. My understanding is that a major consideration for anyone looking to port a commercial desktop product to Linux is that Linux desktop users are, in the broad, very hesitant to spend $100s on a commercial product when open source alternatives exist. My guess would be that a Linux port of Office just isn't a proposition that is likely to generate positive profits.
Office Online is the desktop Linux user's access to Office. Enough people use Macs that it makes sense to invest into the effort, else some other vendor will gobble up Office's marketshare. I use Office Online and LibreOffice all the time on Windows 10, some documents it's just better to have guaranteed formatting compatibility with the majority of documents which are put out through MS Office. I would personally just continue the same pattern if I were a desktop Linux user.
> Office for Linux would be easy, but that’s not going to happen.
They're rewriting Office in React Native so Windows, OSX, and mobile ports will have a lot more in common.
But "Desktop Linux" will always be a million support headaches for no market share; which begs the question "Dear Lord, why?"
And the only way to build market share is through cannibalization of windows licenses. Not in microsoft's interest. If you hae a proper office for windows, I bet many companies would consider seriously switching to Linux.
Office has been available for Mac for well over two decades. There are so many more reasons for companies preferring Windows on the desktop than just Office.
I think there were so may more reasons. But what I see is all internal apps moving to be web based. 5 more years and Office is really going to be the last thing tying up corporates to Windows.
Office already runs on Chromebooks via Google Play within the Android container [0]. Is it then worth MS' time and energy to port the browser interface as a Chrome OS 'native' app?
o365's web interface is pretty much what you're asking for. It's a rent based model, but so are the desktop apps at this point (mostly). It wouldn't really surprise me to see an electron wrapper around o365 UI for a future release to unify the applications more.
The only part of "Office" I really even use though is Outlook (at work), and it's pretty good at the job it does.
Enterprises don't just use free OSS software like that. They'll use Redhat or some other corporate-backed variant, and in the end the license cost will be the same but most software and drivers don't work, users will need to be retrained, and support costs will rise dramatically. They can't even use .NET to build any internal desktop apps either.
I'd switch to Linux on day one if they'd port Office.However, windows licensing costs are negligible in most companies,compared to the overall spending on software.
I thought they published an article that explicitly mentions RN but I can't find it at the moment. MS has also been heavily working on RN for Windows including a C++ bridge that significantly increases the performance of the JS to native bridge.
But that’s how everybody uses it. That’s the default mode when you start a new document. Who even knows that the other mode exists?
Surely they could make it performant in the default mode that everybody uses now that it’s 2019 and we have megahertz to spare? There is no excuse for Word’s atrocious performance.
Draft/normal was the default in Word 2003. Most people have used it.
The problem with page layout mode is that any non-trivial format change, insertion, or deletion requires repagination and the UI freezes until that is completed. Draft mode repaginates asynchronously so that it remains responsive. Comparing a WYSIWYG editor to a plain text editor is no contest as the former performs much more work to layout the text.
I use Word a lot on documents of varying complexity and size range from one to about 500 pages and, other than doing something like a TOC update on a giant and complex document, I've never seen Word be painfully slow, even in Print layout.
Painfully (and randomly shifting) inaccurate in print layout on documents that involve more than just text, sure, I see that every day.
The efforts have been spent on cloud services. Office 365 online is rather good, OneDrive finally works, and other things like Teams and DevOps are being well integrated.
For 95% of business users, these online editions have all the capabilities they need without the install headache and are much easier to maintain and update. Office Desktop just had a refresh too but there's basically 0% Linux business users to spend the millions in development costs for a variant.
Yeah clearly they are throwing a lot of spaghetti at things, I don't know that that's necessarily bad. At least they are trying to do so openly and in a API-centric way instead of just building the garden walls higher like every other company.
I haven't used Office in years and don't know anyone who has, so I'm not sure how big of a priority it is to add platforms to a product like that.
Office on Linux already exist, it's called Office 365. Porting Office desktop for an operating system that's COMPLETELY IRRELEVANT for office users makes no sense.
> an operating system that's COMPLETELY IRRELEVANT for office users
Arguably a large part of the reason that Linux isn't used in offices is because MS Office isn't available. Of course it's in Microsoft's interest to keep it that way.
C'mon, that's complete bullshit. Linux is very hostile to the everyday user, you can't expect a large majority of users to have to fiddle as much as it's necessary to get a barely passable desktop experience on Linux. You buy a Windows or Mac computer and you're going in 10 minutes. There's no combination of distro or hardware where that's true for Linux.
I pretty much disagree here. Before she passed last year, I had my grandmother on linux for about 11 years. I had wine setup for the handful of old games (95 era) she liked, and made sure to update everything once or twice a year. Of course one time I waited too long. Archived her home dir, and installed the latest Ubuntu, restored her home dir, and she was up and running again.
She didn't have to know anything about linux to use it. The same is true for a lot of people. More so in a corporate environment with dedicated staff to handle the harder problems. Hell, most people in offices could get away with a Chromebook and Office 365 today.
Of course, general use laptops and proper linux support are not things that are very common. That part truly sucks. And, yeah, it's not pre-installed for the most part except for some boutique vendors and a couple Dell offerings.
Aside:
Have had a few looks at System 76 lately. May change out my mid-2014 rmbp next year. Unfortunately it's one of the last systems with NVidia, and the metal 2 support for the 750M doesn't work well at all. I'm also probably going to change my desktop to Linux in a few months. Hackintosh support is all but going away, and although I could change out my GTX 1080 with a next gen Navi for hackintosh, but I just don't want to support the mac platform anymore, and my 1080 has a lot of life left in it.
Again... with an office environment, with dedicated staff... the USERS don't really need to know all this stuff, just where to click to open their browser, etc.
I love Linux Mint and Antergos as much as the next guy but Microsoft built an entire platform/ecosystem around tight integration between a full range of enterprise products. I can't say I blame them, decades of significant effort is required to do that and it's not easy or there would be someone else who has done it. Not only is the incentive not there as you mentioned, but it's definitely not malevolence to avoid trying to support random desktop Linux distros which will likely not cooperate with their integration efforts (and likely take joy in being able to reject or impede MS's efforts), to the degree they can with Windows 10.
They have the right idea today, embrace server-side Linux with .Net Core, and soon, .Net 5. That's what Linux is primarily intended for, it's a server kernel and where the action is in regards to that ecosystem. There's a reason some of the code in X11 hasn't been touched in 20 years.
What? Satya didn't invent .Net. The idea of .Net, like the JRE, was to write once and run everywhere. What's visionary about it?
It's sad how so many articles and comments come off just pure PR now. Not saying your comment is, but I have to wonder how much of the "news", comments and internet content is now just PR.
Some cross-platform considerations have been built into it from the start, though. And there has been an official open-source implementation on a non-Windows platform. Perhaps more to show that it's possible than as an actual usable artifact, but it was there.
Mono existed from very early on with .Net and the core was pretty compatible. I think when MS bought Xamarin, it finally got the attention it deserved, and really did go to help .Net Core take form.
I don't know about that. I thought I kind of understood the mess of the .net framework until now but now I am really lost.
Like asp.net core was meant to be incompatible with .net full framework because of inconsistent featureset, is that going away? For applications, .Net core binaries are different from .net full binaries, they compile to a .dll, not an executable .exe, you have to run them with a command line (and if you choose the option to create an exe it comes with lots of additional binaries that aren't required in full .net framework, plus I understand some additional problems of version compatibility with the installed .net framework). So is .net 5 going to be one or the other? Or is .net 5 just another way of saying that they are discontinuing the full .net framework and that now everything will have to be .net core? But then is a simple full .net framework 4.7.1 .exe run on .net 5?
Well I believe you can now, but I thought I saw a recent announcement that said it wouldn't be possible with the next version.
When re-reading the article, I think what they are implying is that they are ceasing support for .net full framework and just renaming .net core ".net". If it is the case it is kind of a big deal, there is ton of .net full code outthere, that no one has any appetite to convert. If it is not the case, are they going to rename .net full to something else?
This article does the opposite of solving any confusion.
They aren’t ceasing support. .Net framework is an integral part of Windows. It’s in maintenance mode. There will never be another major version of .Net framework - just security and maintenance releases.
.Net 5 isn't just a rename of .Net Core. Though for most people I think that understanding would be sufficient and not outright wrong, just incomplete. It is where Core takes over. It's also Mono to target other platforms, in a unified programming API.
Moving projects from .Net Framework to .Net 5 should be as easy or hard as it was to go from Framework to Core. In my case, this isn't a problem for the current project that I'm working on, but thankfully Microsoft will support .Net Framework 4.8 in maintenance mode for a very long time.
I think, for the most part, Mono is being rolled into Core. From what I've seen, it looks like large chunks of Mono were moved, migrated or otherwise refactored into Core anyway. My reading of this is that what is now the Core runtime, will be what is .Net everywhere, and that while not mentioned, Mono as a separate runtime, much like .Net framework will not see new releases in favor of a single .Net 5.
I think making Mono and the existing .NET Core runtime 'runtime options' simplifies the confusion a lot. Unifying the standard library was already a good idea, and had been partially done anyway. The existing Mono version of the stdlib was a good effort that historically hasn't stacked up when you try to port stuff (and incrementally had been replaced with chunks of the 'you can look at it i guess and it's sort of like desktop netframework' reference sources).
I'm personally happy to see more of the .NET Core stuff end up in Mono since it usually is battle tested and has better compatibility, and I'm also happy to see more stuff approximating the existing .NET Framework and Mono workflows since .NET Core has historically been unable to do important things that netframework and mono can do.
The article mentions that while MonoVM's (LLVM-based) AOT efforts are ahead, CoreRT has outpaced MonoVM in JIT performance, so CoreRT will still be the default in everything but iOS and Blazor which are the only two 100% AOT platforms.
WPF will still be Windows exclusive, though. Like many other things. What they really mean is BCL+Runtime+Compiler, and not .NET (read as: the whole ecosystem).
The drag and drop designer part of VS is not even what I think is cool about WPF. To me it's the architecture and the whole API. It's easy to make clean enterprise size applications with good separation of concerns (I've been a developer in the C#/WPF field for around 5 years). For other platforms - and Windows as well - the closest I know is Qt, including the drag and drop part btw. ;)
This always surprises me whenever I look into cross-platform GUI toolkits. The closest is Qt as you mentioned. What really gets me is GTK's continued popularity on Linux when Qt is so much easier to develop with.
Probably a side effect from the popularity of Ubuntu which - since they dropped Unity - go still strong with GTK as they use Gnome now out of the box. And Ubuntu is like the de facto standard desktop distribution.
> how I can build a minimal app that works on all those platforms
That's perfectly normal.
There is no such thing as "Cross Platform .NET"
The C# language and the.NET Framework does indeed run on almost all platforms, but that pretty much ends here in terms of "portability".
Anything beyond that is "platform specific"
For instance, building "desktop" applications is either UWP with advanced styling and reactive data binding but only for Windows or GTK# with Mono which is very limited.
For Mobile either Xamarins.Forms for Android + iOS but it's very limited in terms of features, or it's Xamarin.iOS + Xamarin.Android which require platform specific code for UI / Routing and many others OS specific functions.
For Web , the WASM Binary is something like 5MB+ which makes it not reasonable compared to an app written in Plain JavaScript or TypeScript.
There is still a long way to go for C# to be really "cross platform"
> The C# language and the.NET Framework does indeed run on almost all platforms, but that pretty much ends here in terms of "portability".
IMO, that's not entirely accurate, and does .NET a bit of a dis-service.
.NET Framework isn't cross-platform, and doesn't pretend to be - it's Windows only.
.NET Core is cross-platform, with runtimes for Windows, Linux and MacOS.
Regarding Xamarin, I guess you haven't used it for a while? Until very recently, I had the same opinion, but only because it was years since I had used it - turns out it's rather good now!
Where cross-platform ends is really with desktop GUIs - web apps, web APIs, console apps, backend processing services/daemons etc, all of these work very well across the supported platforms, and the only time you'll likely write platform-specific code is the rare cases when you need to pinvoke into native DLLs.
Aside from the likes of Electron, I'm not sure there really is a good cross-platform solution for desktop GUIs. Microsoft would be hailed as heros if they ever crack that one :)
Qt's license is a non-starter for a LOT of commercial entities.
And Java is fine, for varying definitions of "fine". I have yet to see any Java application that looks good, aside from a couple IDEs, and none that look good across platforms.
> .NET Core is cross-platform, with runtimes for Windows, Linux and MacOS
Microsoft used to follow the eat-your-own-dogfood rule, which would seem to indicate that the development tools should use the same run-time and run on all the targets, but the announcement only mentions linux as a target. As a hobby-only-on-linux-only developer who does not buy or sell any software or related services, I find this announcement a poke in the nose with a clue stick.
xamarin.forms has support for uwp/wpf (windows), linux (GTK#) and mac (https://docs.microsoft.com/de-de/xamarin/xamarin-forms/platf...) it's not highlighted that much and for some stuff you need to create native views. but it works smoothly and you can do a lot of stuff. for some stuff you still need to configure native views, or call into native apis, but still it's pretty nice working and looks better and is faster than most electron stuff.
Yeah, I'm seriously still dumbfounded by this. I mean, it's such a positive, future-aware decision, it's confounding. Impossible to say how relevant .NET it will be in, say, 4 years time, but development will certainly be much better than today when you have several disparate runtimes to target depending on the platform.
I have extensive XP with .NET Core 2 in production on huge services with 1M+ users - we started making some stuff before 1.0 and had it in production after having few sessions with local MS.
WebAPI, APS.NET Core, Pwsh, C# 7... I dont work for MS, but that is some seriously good tech stack. Performance is amazing too. I highly recommend it. Worked in 50+ environments so far but this is top stuff. MS really nailed it this time. No, don't tell me that JAVA is comparable to C# in elegance, that linux dudes had python/ruby/perl/whatever before Powershell etc.
The only problem we had so far was with the Oracle db drivers which were non existent until several months back, but that is on Oracle... which sux more and more each day - commercializing java for example will just give a boost to .NET now, a lot of it - who at Oracle made up such decision escapes me, but maybe he works for MS.
I have a project in the early design phase that I was thinking of going with .Net Core on Linux. I've thought about going with Java, but with all the recent Java licensing changes don't think I want to go that route anymore.
I currently run on Windows servers, some of which are Core. Tried nano but its terrible as there is no package manager and no support for msi files. If you install anything in docker it takes GB's so we used VM's for bakcend/frontend running Windows Server 2016 behind IIS/kestrel/nginx and every other supporting tech on Linux (not core). One of the reasons to use Windows was Sql Server but mostly PowerShell which we do all automation in. Backend service is used to register invoices for entire country and it has 1M+ users, we have 60-100 logins per minute and 500+ concurent actions. Backend is served by single server (!) and never gets more then 10% CPU load and 20% memory with that load. I am amazed honestly. Zero dev fucktitude (once we ditched Angular, but that is another story). Almost zero downtime (30-50s to build and deploy with db migrations).
Now, we use Linux alpine docker containers, use postgre instead Sql Server and pwsh with Invoke-Build to run CI/CD stuff. Sworm for orchestrations and compose for local.
Have 2 incoming country-level services this year for production. Currently on dev/stage it works really fast but load is trivial.
We did a lot of performance test on Windows and achieved 1.5-2K req/s with hello world and our setup on IIS/kestrel. Did no test for linux variant so far.
> I've thought about going with Java,
Java compared to latest C# is like ... Clojure to VBA. No brainner really, plus Oracle (sure, there are alternatives).
Also, entire Java enterprise stack is overengineered beyond repair. I need 77 classes for basic stuff. Take .NET core you wont regret it.
I assume your docker taking GBs above is for Windows Containers? Also, most of that overhead is first use, updates and parallel similar containers are much smaller. Also, as you mention, alpine containers are what I'd consider "just enough" when wanting to diagnose an app in a container.
I've found that .Net Core on Linux and in Windows are close enough that scaling should be the bigger concern. Unless you're tethered to windows, the broader tooling is much more mature with Linux containers/pods.
.Net has some caveats with GC: Server GC preallocates heap per CPU core so if you have 8+ server it could be a waste of RAM if app uses less than 1GiB. We are tinkering with microservices on .Net Core 2 in k8s and came up with using WS mode with clearing unused allocated memory on health check calls which is dirty but working trick.
On the Java side though there is a hack in JRE which checks if JVM runs inside a Docker container in order to not get out of memory limit by cgroup.
> Worked in 50+ environments so far but this is top stuff.
With so much experience you must know how this sounds to someone not in the .net space.
You and your company are clearly well versed in .net and it's worked out for you -- take a person and a company equally experienced in Java and they'd achieve similar results (I have, companies I've worked at have). The systems you're describing are not extraordinarily large scale systems. You've failed to outline the gains here vs. another tech stack.
Not yet (blog is planned, but you know... time), but I have bunch of presentations on it (basically DevOps on Windows on premise) that I consult to companies on request, with one of those services as a real life example (I prefer diving into real working stuff over hello worlds).
For example, this is the one about Chocolatey that I gave at Microsoft event few years back (other are similar, but all on Serbian ATM since I mostly do consulting locally and involve everything from Gitlab over InfluxDb over PowerShell to obscure languages such as Autohotkey):
Today there is an Oracle driver for .NET Core, BUT this fucking driver doesn't support async/await calls!!! To archive the max performance .NET Core has to offer, you do have to use async/await all the way from the coming request to the database calls. With Oracle databases, it is not possible yet.
I am very pleased with the direction Microsoft has been moving the last few years. Every release of .Net has incrementally made our lives easier.
We are already on top of .Net Standard/Core 2.0 and are building successfully against 3.0 prerelease targets without modification. I would anticipate the move from Core 3.0 to .NET 5.0 would be trivial for us, and as long as self-contained deployments are still around in 2020 our build & publish pipeline won't know the difference (aside from msbuild & SDK updates on Jenkins).
So, does this also replace/update the .NET Framework that is bundled with Windows 10, meaning that you can release a .NET EXE and ask people to use the latest version of the .NET like you can release a .JAR and you can ask people to have the latest version of Java, or you have to bundle the entire runtime (be it via a fat compiled AOT or regular bundling) with your application?
I ask because one of the positive things about .NET Framework 4 is that i can create a tiny .EXE and give it away and expect that people will have the runtime to run it since it is already part of Windows.
>You can now publish a single-file executable with `dotnet publish`. This form of single EXE is effectively a self-extracting executable. It contains all dependencies, including native dependencies, as resources. At startup, it copies all dependencies to a temp directory, and loads them for there. It only needs to unpack dependencies once. After that, startup is fast, without any penalty.
This is for .NET Core 3, not for .NET 5. While .NET 5 might provide the same tool, it doesn't answer if it will also provide a .NET Framework 4-like functionality where the .EXE relies on a runtime already installed on the user's system and if that framework will be something the developer will need to provide and/or be part of Windows 10 like .NET Framework 4.
Ah, got it. You want to be able to ship something that relies on an existing installed runtime and don't want to bundle the runtime with your executable.
Me too. Requiring to run all executable with a command line is a major inconvenience. And by choosing ".dll" as an extension it is not even possible to assign the extension to dotnet as a default application like you could with a jar file. And if you want self-executing binaries you not only have the version problem you mention, but you also have to bundle all sort of assemblies. And there doesn't seem to be anything like ILMerge for .net core assemblies to merge them into a single file.
What you are looking for is called a "framework-dependent executable" (exe file with no framework) rather than a "self-contained deployment" (exe wrapper for dll file with framework included) or a "framework-dependent deployment" (dll file with no framework)
> Starting with .NET Core 2.2, you can deploy your app as an FDE, along with any required third-party dependencies. Your app will use the version of .NET Core that's installed on the target system.
> Your app can be run by calling the published executable without invoking the dotnet utility directly.
It's almost certain they'll offer the ability to publish a self-contained binary or split from dependencies since that's a feature of .Net Core 3 today. The Mono-based projects may not, but I'd expect them to someday replace what Mono targets with .Net Core. That's just a ways out and otherwise inconsequential to the end-user using the .Net 5 API.
> The term is based on the perceived process of harvesting fruit, such as cherries. The picker would be expected to only select the ripest and healthiest fruits. An observer who only sees the selected fruit may thus wrongly conclude that most, or even all, of the tree's fruit is in a likewise good condition. This can also give a false impression of the quality of the fruit (since it is only a sample and is not a representative sample).
I don’t get it. How can one executable even know how to bootstrap itself enough to know how to run a self extracting archive across Windows,MacOS,Linux?
I understand how MS did it in the past with DOS/Windows and how Apple has done it between the 68K/PPC/Intel transitions.
I understand that. But you still have to tell it which runtime to use even though you can build a Windows standalone distribution on Linux and vice versa.
They seem to implying that you can create one executable that you can distribute and it will be able to extract the needed parts on any supported platform.
That's not exactly what they're saying. In the quote above, they are talking about framework independence, not platform independence. The wrapper executables are still platform specific, but framework independent. However the actual .NET modules in the package are platform independent, but framework specific. They can be executed without the wrapper executable by installing the correct framework yourself.
And as much as people complain about Microsoft's messaging with respect to .Net, there isn't really a simple way to explain any of this -- even to people who are deep into the .Net ecosystem. I feel their pain.'
Yes but will this 'required runtime provided by the system' be part of Windows like it is with .NET Framework 4 (that is also updated automatically via Windows updates) or something that the user will have to go out of their way to install like Java?
In many cases, this is the crucial difference between deciding to bundle the runtime yourself or not.
> Starting with .NET Core 2.2, you can deploy your app as an FDE, along with any required third-party dependencies. Your app will use the version of .NET Core that's installed on the target system.
> Your app can be run by calling the published executable without invoking the dotnet utility directly.
Well, even at present there's no guarantee the end user has the version of .net framework and libraries you need. You might need 4.8.x stuff and they only have 4.7.x. Maybe they're on win8 and not 10, or they're behind on updates, etc.
Typically the solution for this is to either sense what's installed (and use an installer) or just ship it and let the error messages help them figure out what to do.
You can't even guarantee the user has a computer. But it's a very bad idea to throw error messages at the user mid-install, and it hurts to bundle an entire framework installer inside yours. If you can target 4.7 and know it will exist on computers with windows 10, that's much better.
The F# repl (FSI as fsharp interactive) works in .net core 3.0 preview already, you can do `dotnet fsi` to run it
Type providers works in general, but depends if the type provider library was updated to use latest type provider sdk.
Also generative type provider may not works, erasing works
Enrico answered to question w.r.t where F# is now, but F# is going to also be a big part of .NET 5. The only reason it's not mentioned in the post is that we haven't firmly decided on if the F# release that corresponds with .NET 5 will version in lockstep like C# is planned to do.
I was really excited to see this; finally a consolidated .NET. Then I read this...
Taken together, the .NET Core and Mono runtimes have a lot of similarities (they are both .NET runtimes after all) but also valuable unique capabilities. It makes sense to make it possible to pick the runtime experience you want. We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.
Mono is a large part of mobile and Unity for gaming. It's not going to disappear anytime soon and they can't go back to it being completely separate. This is the best compromise to keep the runtimes the same but share as much as possible between them.
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.
I'll read up on how Mono handles it. I've never done too much .NET and I'm a recovering JVM dev, I was just asking out of curiosity since that is a pretty thorny feature to tackle. I can think of a number of dangers/shortcomings with any approach I can think of.
I would like to know more too. Not being able to call java libraries is one of the biggest problems with .NET. There are a ton of java libraries that don’t have good .NET equivalents.
If only they could just add a very easy way to invoke functions (at least those with simple interfaces, i.e. taking just simple value types as inputs and returning a simple value type) from other languages (incl. Java and Python) this would already be a huge value boost even if performance would be not perfect.
Well, if you can get a C-compatible pointer to those functions you're already ready to go, and the inverse is true if those languages can consume C-compatible function pointers.
So from python you could probably flex to use ctypes, and from java, JNI. Naturally this is a bit awkward but I expect the mono binding tools would help smooth it over for Java (I have no idea about Python there.)
I know it's possible this way but I've mentioned "very easy" intentionally. I'd manage with what we have if I really needed it but if it was easier it could attract much more people who generally are scared away by words like JNI and C-compatible pointers.
If I were developing a program language and sought to attract more people I would consider seamless invocation of code written in other languages a strategic height.
And does this explain why they don't seem to care about making .NET Standard versions at all logical to developers (e.g. making a major breaking change, not supporting .NET Framework, to .NET Standard in a minor version)?
Edit: And before someone says ".NET Framework is choosing not to support .NET Standard, you shouldn't version based off implementations but off changes in the API": That only works if you have many implementations, .NET Standard has 3 major implementations! Losing 33% is pretty significant :)
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.
You guys should seriously consider the mental load all of this rebranding is having on your community. You have too many brands, too many names, and too many seemingly overlapping ideas.
I want to see .Net Standard die, not because of the technological merits of it or problems, but because you guys have created such a confusing mess and .Net Standard is perhaps one of the worst examples.
.Net Standard seemingly exists to consolidate compatibility between Core/Framework/whatever, but with you consolidating them under the "Framework" branding anyway there's no reason it should exist except to confuse further.
Either something is or isn't .Net 5 compatible. The end.
>Either something is or isn't .Net 5 compatible. The end.
You're in luck because that's the way it is. The .Net Standard is on the list of being .Net 5 compatible, because it's intended for shared libraries.
I want libraries written for .Net Framework, Core and .Net 5 to be cross-compatible. Targeting the .Net Standard is the only way to do that. That's easily worth putting others, who aren't even using it, through mental turmoil.
It won't be going away because the .Net Standard is an absolute must-have for the health of the ecosystem, and the most important underpinning to the entire Framework->Core->.Net 5 effort. As the grandparent comment said, it won't be as important going forward (.Net 5, 6, 7 etc) but won't be going away until the .Net Framework does. It's likely the .Net Standard will outlive you.
The post you replied to said exactly why it exists and explained why it no longer needs to exist after this (.Net 5) change. Even Microsoft's own graphic on the linked page makes .Net Standard's irrelevance obvious.
The graphic in the link is merely truncated from the rest of the .Net ecosystem. It's not redundant as it might appear in the image, libraries targeting the .Net Standard will run on Framework/Core/.Net 5+.
My understanding is that .NET Standard was needed to provide an API for the various different implementations to support. This was normally draw in images like this:
People will continue to support both framework and core for decades, so library authors that want to support e.g both framework and Core will need to ship libraries targeting .Net standard just like they do today. The question is perhaps whether there will be a new Standard (5 would be a good choice of number) indicating the support needed for .Net 5. Unless there is a competing implementation perhaps there is no need
(I don't know the answer to this question) wouldn't that just mean that .netframework's last supported version of netstandard is 2, and then you have a netstandard 5 that's supported by .NET 5? I don't feel like that's especially confusing.
.Net Framework isn’t going away. They said in another post it will be supported as long as Windows is supported but it will only be getting “highly compatible” maintenance updates.
I haven't used .NET since 2011, if you're in the same boat take a look at C# today. They're grabbing all the best features of other languages and making it their own, WHILE also allowing you to deploy static binaries to _any_ major platform.
Write C# code purely in VSCode or Rider, compile to all three platforms while on a Mac, and run your code in Linux. All from supported, non-hacky features.
Why use Go if you can use C#? C# is now incredibly compelling. The C# of today is not the C# of 6 years ago.
Goroutines and Async-Await are two very different takes on the same problem. In that regard, preferring Go over C# is an incredibly good reason to keep using it instead of switching over to C#. Choice is good, I prefer more languages than fewer.
I'm far from being an expert at Go, but I will try: goroutines are green threads (very light threads, if you prefer). The main difference between async calls and threads is that threads remove the distinction between synchronous and asynchronous code.
In C# or Python 3, each function is colored as either sync or async. You can quite easily call an async function from a sync context, but doing a blocking sync call from an async context is forbidden (although possible).
In Go there is no such distinction: you just write your functions in a straightforward fashion, as if everything was synchronous, and then wrap whatever you want to run in the background in a goroutine. If you don't need the return value from that function, it is has simple as issuing:
go my_func(param_a, param_b, ...)
Note that goroutines are green threads, not OS threads, so you can easily spawn many tens of thousands of them without bringing your system to a halt.
It is worth noting that the key to this is that the language is designed so that even the synchronous appearing APIs for things like file IO actually use the non-blocking system calls under the hood, so that the OS thread does not get blocked, and other goroutines can be scheduled.
When calling into C code, there is additional overhead of potentially creating a new OS thread to continue running goroutines on, since go has absolutely no idea if the C code will block, but since the average C library does use blocking IO, it needs to either assume the worse, or alternative have an OS thread dedicated to monitoring for kernel level blocking, and spawning new goroutinine runing threads. (I believe the assume C calls may block approach is used.) It has heuristics to avoid creating a new OS thread every time, but in any case, if you have many goroutines calling a blocking C function call, it means you have many blocked OS threads too.
Async is to deal with io not for all concurrency in general. It uses interupts, not threads. Although the implementation can use threads for optimisation, it is not the point. If you're waiting on a network socket or reading lots of files, you don't need to spawn a new thread for each item. You can instead schedule a task to run one an interupt is received.
You are entirely correct. My sentence "The main difference between async calls and threads is that threads remove the distinction between synchronous and asynchronous code." is pretty weird: I wasn't talking about threads in general, but green threads as used by Go (i.e. Goroutines) in particular.
The idea that I wanted to express is that, very broadly, there are two ways of dealing with concurrent io. One is to deal with it explicitly at call site, using some variation of async/await semantic, futures, promises, or just callbacks. That's the C#/Python 3.4+/javascript way of doing it. Although implementations vary wildly between these languages, the core idea remains the same.
The other way of dealing with concurrent io is using green threads (or related concepts like actors) as in Go, Elixir, Python with gevent, etc. IO calls don't look special (no await, no yield, no special keyword, no callback), that is to say they behave like any other function call (although the implementation of these io calls is non-blocking to allow other green threads to run). Concurrent io from the programmer perspective is achieved simply by spawning many green threads/actors.
I personally find green threads easier to reason about than async calls, especially in the long run when maintaining large software.
Definitely agree on the statement "Why use Go". It seems Microsoft has made C# into a one-stop-shop for most developer needs. Web? Do what React enables you to do in C# with Blazor. Console? C# deploys to all major platforms. App? Xamarin has tons of tools for that, and now Xamarin will be given the same attention as all other C# frameworks, besides most people defer to Web nowadays.
The IDE support of VSCode and integration with tons of other languages and tools make most other languages in this day and age seem superfluous, and I assume they are taking WebAssembly as far as it can go as I've seen talks where they mention support for low-level hardware. If they can just minimize the size of the binaries and files, we will soon see C# taking the place of C++ in terms of writing portable low-level code. I don't think it will ever take over C as it will never reach that performance level and that's a requirement, but C++ has been feeling very bloated as of late, and is becoming more of a pain to work with. If I have the option of ditching C++ in favor of C or C#, I'll do so and my decision will only boil down to performance.
I'm interested in what route they'll take as it doesn't seem they are trying to compete against any language in particular, but amalgamating what makes those languages nice to use into one, and they're doing a commendable job at it.
I think there are some developers who would consider .NET 5 a huge breaking change. .NET (Framework) 4.8 looks like the predecessor but has features (rightfully) not available in .NET 5.
I like the vision but hate the name. .NET Core 4.0 would have done it. When you market software engineers stick with patterns. This looks like a lot of managers have feedback to stuff they did not understand in the first place.
I love the name. The numerous .Net monikers are confusing. Framework, Core, Mono... each with overlapping support for various frameworks and platforms. I expect new .Net developers to be overwhelmed trying to figure out the differences, as I was.
The monikers were misleading. This feels clean, looking forward to it.
Does "Core" mean core functionality? Then what is ".Net Standard"? Is .Net Core cross platform or Mono? Why can't I use .Net Core library with Xamarin? Is Xamarin .Net Mono? Should I use .Net Core Winforms or .Net Mono?
Funny how this announcement comes the same week Oracle decided to kill Java EE. MS has always been good to it's developers and broadening the .NET platform this way makes one really consider to give it another look. Oracle in the other hand basically spreads FUD about their own platform, even though they seemingly don't even care about it anymore.
J2EE is widely popular and continues to have a vibrant community. Oracle just doesn’t have the vision of how to encourage and mature that community and turn it into the proverbial golden goose. All they want to do is kill it to get all the eggs today. They can just copy/learn Microsoft’s strategy and come out on top.
For the newbie here, can someone tell me if this is open-sourced? Many are fearful of building on a MS platform in case they change their minds in the future etc?
There are some open source components here, but I don't think the .NET platform as a whole is being moved to open source. The core compiler and runtime are open, but some of the most popular libraries and frameworks are still closed, it looks like.
There isn't much that hasn't been open sourced in the past few years: The runtime, standard library, C#/F#/VB compilers, ASP.NET, Entity Framework, Xamarin, PowerShell, Winforms, WPF are all open source or (in the case of WPF) being open sourced.
Roslyn is the compiler. There's not much of a debugger in it, is there? I mean, I guess the debugger will use Roslyn to parse watch expressions and evaluate things in the Immediate Window, but beyond that I think debugging is handled by something else.
This seems like it would be a prime opportunity to introduce UWP applications to macOS and Linux. That would be a welcome alternative for developers looking to develop high quality native + cross platform applications.
.NET desperately needs a first-party supported solution for cross-platform desktop apps. I was searching this news for any hint of that, and don't think we're going to see it yet.
I am unsure if they would try to push UWP to those platforms, or focus more on expanding Xamarin which is already cross-platform. I know WinForms and WPF are considered far too dependent on Windows proprietary APIs to ever be officially supported elsewhere, I assume UWP is the same.
That looks pretty cool. I've also seen Avalonia, which is a more .NET-focused approach, meant to be very similar to WPF: https://github.com/AvaloniaUI/Avalonia
But the main issue for me is that Microsoft just needs to pick something, and say "this is how to write cross-platform desktop apps in .NET", and support it. I don't really care what it is, they just need to have one.
I agree, but one of my concerns about Microsoft's direction is... that there doesn't seem to be a clear direction regarding UI frameworks. We now have Win32, Windows Forms, WPF, UWP XAML, and React Native, with no clear message about what platform makes sense to invest in for the long-term. In fact, I am starting to think that Microsoft may be abandoning the UWP XAML direction in favor of React Native since presumably React Native has a better cross-platform story than XAML does.
My guess is we aren't so lucky just yet. UWP has so much Windows 10 device specific functionality, and I think that Xamarin.Forms already satisfies this need.
Instead, what I see them doing is making it easy to share code between UWP and other platforms. There are so many competing options for code re-use, hopefully .NET 5 can consolidate things a bit without sunsetting Mono projects
We just started a new project on .NET Framework 4.7.x, because not everything that we care about is available on .NET Core, not even with the upcoming .NET Core v3.0.
Lets see how .NET 5 will sort out the current state of affairs.
In any case, it is a welcome change to sort out the mess that the whole WinRT and .NET Core 1.x have brought out.
Although, we exclusively target Windows platforms right now (RID == win-x64). We are considering replacing these Windows-only deps with cross-platform alternatives in the future (e.g. Novell LDAP and Mono drawing) so that we can start looking at Linux as another hosting option.
I have even had reasonable success with retargeting 3rd party libraries to .NET Standard 2.0 without much coding effort. It's mostly just *.csproj XML soup management.
To expand on this. As I understand Microsoft has started to create a new version of WCF for .NET core (or 5 as it is called now). I should a multi-year development project to do this, because it can no longer be "Windows" Communication Foundation since it also must work on Linux.
They same goes for EWT tracing which is the logging mechanism you can use. That also has to be cross platform.
So for some years to come, I (on some projects) are "stuck" with .NET 4.X until WCF and EWT has been re-architectured.
Since much of the banking world is heavy users of WCF, Microsoft has no other option that to implement WCF in. Net 5 unless they want to loose the banking industry. I did come across a post from one of the WCF products managers who said that they are working on a cross platform solution but it will take some (much) time before that has been completed. Cannot find this post, but I consider it safe to say that WCF for .net 5 is coming and that I am stuck util it does as there really is no alternative to using WCF
Off the topic, but I come from Python / Django / Flask. (Have experience programming desktop apps with .NET 4 and C#). I just don't get web app development with asp.net core.
Is there a ground up tutorial, concept-wise, about how asp.net works?
I’ve gone straight to the official Microsoft docs multiple times to try and get the same experience as when you read the Django documentation, but it’s just not there. Django’s docs explain the what, the why, and more. The Microsoft docs just have the what.
I want to love .NET Core development because I love Microsoft’s open source effort, but the support (or lack thereof) from the documentation is quite the hindrance.
My issue is that I guess I have high expectations for the official docs of a platform/framework/library/whatever. You shouldn't have to buy a book or read a random blog to find critical information on core functionality. The official docs should provide that, and Django is a great example. It includes how to do things, why things are the way they are, how to customize workflows, best practices, pitfalls, and on top of all that the source code is super easy to read and understand.
The pages at docs.microsoft.com are mostly just basic walkthroughs that leave me with a lot of questions. And the .NET Core source code is not nearly as readable.
It's getting better though. And I don't mean to take jabs at Microsoft because I truly do appreciate how much they've done in open source over the last few years, especially with VSCode.
Do you have a concrete example or two from the Django docs that you consider to be representative? Not doubting you at all; honestly just curious to see what you're looking for in documentation.
Microsoft docs are constantly under revision, including general improvements (not just reaction to changes), and the writers are very receptive and responsive to feedback.
(I work at Microsoft on docs, but not on the ASP.NET Core docs)
First off, thank you for what you do. Microsoft is kicking ass these days and I don't want to sound like I'm unappreciative or unimpressed with what you guys are doing.
The first thing I see when scrolling down those pages is that the Django page is ~90% descriptive text and ~10% code. The ASP.NET page is the opposite: ~10% descriptive text and ~90% code.
Obviously that's not the best metric but I need to get off HN soon so that's the best I have for now :)
In any case, this could support my earlier claim: Django docs give not just the "what" – they also provide the "why", along with super useful background/supporting information, and even alternative approaches (e.g. in the "Limiting access to logged-in users" section there are at least five avenues you can choose from to meet your needs).
That was the quickest example I could find. Sorry it's not more substantive. I'll post again later if I find something that could be more helpful.
And again, I really appreciate what you guys are doing and don't mean to sound like I'm sending any negativity in your direction <3
I definitely see what you're saying - that section of the ASP.NET Core docs drop straight into a top-to-bottom code-driven tutorial, whereas the Django docs go concept-by-concept. This is great feedback, so thanks!
If you get a chance, check out Microsoft Learn (microsoft.com/learn) - we're working on guided learning as opposed to documentation. Most of our content is interactive and task-based, but we try to ground the interactivity with conceptual information, context and scenarios. Much of the technical content published to date is Azure-focused, but we're growing other topics, including ASP.NET Core.
Although improving recently, Microsoft still struggles with "our docs contain lots of knowledge but not a lot of wisdom." I go to documentation to find wisdom about the whys and why nots, not just the hows (i.e., method signatures and syntax).
The Little ASP.NET Core Book [0] is a pretty good introduction that covers all the pieces you need to know for a basic ASP.NET Core application. It's available for free in all the usual ebook formats.
I've looked it up for you and found this one - a bit dated but it shouldn't matter much on an introductory level and it seems to have the concepts presented in the right order (or maybe that's just how I'd do it).
> Moving to a single .NET implementation raises important questions. What will the target framework be? Will NuGet package compatibility rules be the same? [...] How does writing code for a specific architecture work? [...] We are working through these issues now and will soon be sharing design docs for you to read and give feedback on.
This, however, is my biggest worry. Between runtimes, content files, analyzers, native references, asset visibility rules, etc., packaging has become kind of a mess. I'd love to see a move away from monolithic packages, but IDK if that's on the table. Fingers crossed.
I don't know much about WPF, but it seems to be in an odd place with UWP. The fact there are no plans to port WPF MacOS/Linux, combined with the increasing emphasis on cross-platform... I'm curious where it goes from here.
Legacy or not, Win forms would be better then nothing. For that to happen GDI+ need to be ported to core and for WPF to happen DirectX needs to be ported to core. Its all into UWP now.
So I guess it will not happen soon. MS should reboot IMO.
What does it mean to standard ASP .Net (not core)? Will I be able to run all the enterpisey apps that use ASP MVC and WebForms on Linux in 2020? And if not on Linux, then will WebForms / old MVC work on NET 5 on Windows?
But presumably only the Core 3.0 WCF/Winforms "most things work, but in all likelihood your million+ line of code app will have all sorts of little things that won't work".
Presumably if you are using any of the following heavily in your applications, you will never be able to run on .NET 5 without major porting effort (I.E. reworking everything to avoid these):
* Remoting
* C++/CLI or Managed-C++
* App domains
* code access security
* ASP.Net Web Forms
* Exposing registered COM interfaces from .NET code for access from Win32 code.
* WCF Servers (Technically, nothing prevents somebody from porting this, since WCF is basically pure managed code, and its tricky Proxy related code is already ported as part of the client code. It is just that Microsoft has no plans to bother with this.)
Will SQL Server upgrade its .NET support for .net 5? (Potentially breaking compatibility with certain currently supported use cases)?
I'm guessing IIS Managed modules will never upgrade beyond .NET 4.X.
It's not like they have to re-implement all the code for these things; the majority of this code can just be moved over as-is from .Net framework to .Net core on Windows with minimal modification.
I'd be surprised if the goal isn't 100% compatibility. If Microsoft can get Linux applications to run on Windows, they can probably get .Net applications to run on .Net.
Remoting/app domains/Code access security were ripped out of the .NET Core codebase, and there is really not much of a chance of them returning. The CoreFX codebase has systematically removed all the code needed for things to safely work with those features, and re-implementing them would be unfeasible.
As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains. Further, w3wp.exe has special code for loading and integrating with the Framework, enabling managed modules. This is the whole System.Web.dll concept. Microsoft really does not seem to want to put in much effort to fix that.
Since Microsoft always recomended hosting WCF services in IIS, which therefore relied on the whole System.Web.dll mess which I think is a large part of the reason thy don't want to port that.
That said, other than replacing XML configuration, self-hosted WCF services should be pretty easy for them to port.
> As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains.
But I wonder if you could just stub that out with a mock AppDomain object in C# to keep the API the same. Is there actually anything that's truly dependent on it being an actual "AppDomain"?
AssemblyLoadContext with assembly unloading is not at all compatible with .NET Framework 4.X, which can be a pain if you want to gradually migrate stuff.
Also it does not have anywhere near the same level of isolation, which is part of what System.Web.dll was using them for. Would it be possible to it in a system.Web.dll port? Certainly, but you would be changing the semantics enough that some applications would notice the difference, and probably not in a good way.
yeah I mean unloading is not even that good without a .net core 3.0 preview.
I think that in 5-10 years new stuff will emerge based on AssemblyLoadContext, maybe even some kind of OSGi just a little bit easier. Some examples are really promising and AssemblyLoadContext does not have the same problems as Java solutions. (duplicate Class Files, etc...)
the only thing that is missing is some kind of security related stuff.
COM and C interop have always been separate and COM has been around since 1993.
In fact, the native Win32 APIs use C style null terminated byte or double byte character arrays for strings. COM uses BSTR types - double byte arrays where the first two bytes are the length.
Interesting but as there is a 3.1 LTS version due before this comes out and this 5.0 release is not LTS, with any of those features not going LTS until 6.0 in Nov 2021.
So that kinda diminishes my initial excitement, much could change in a short period and we are talking over 2 years until any additional features becomes set in stone with LTS support. So for me, it's probably not looking at until 6 months before LTS release. As is the case with many others.
But some good changes - a rebrand would of cut of any confusion and historical hangovers. As between now and Nov 2021, much could change.
I'm sure I'm not alone in thinking that the .NET ecosystem is super confusing, coming as a developer outside of that ecosystem (mostly web).
I'm a JS, Python and PHP developer who sees a majority of jobs in my area as .NET centric. To this end, I'm interested in familiarizing myself with .NET [1] but I'm totally at a loss wrt/ where my entry point to the ecosystem should be.
[1] Insofar as starting a new small project or re-implementing an old side project in .NET as a learning process.
The most interesting piece of work happening in the .Net world is actually CoreRT (which is already beta quality), which lets you write fully native apps with access to the large .Net ecosystem. For many, it could be an alternative to Go/Rust. c# is a more capable language that Go, and easier than Rust - a particular sweet spot.
Instead the announcement was primarily about unrolling the version mess created over the last few years.
As you can see from 300+ comments at the time of writing, the post is entirely unclear about what's happening seeing as everyone still argues about it.
My read of it is that .NET Core becomes the new .NET, not that .NET Core has parity with the existing .NET.
Specifically I can't just retarget my existing projects against .NET Core (or the new .NET) and have them just work.
It will still be confusing. At some point you'll need a library that doesn't support it. ".NET" promised backwards compatibility. Now, old ".NET" stuff won't work where you'd previously expect it to. Everything was quite clear when these 2 incompatible platforms had separate names. It's like merging Java and JavaScript "for clarity".
Except for 2.x-3.x, .NET Framework didn't provide backward compatibility across major versions, so a break at the 4.x-5.0 transition would be in line with .NET Framework history even if .NET 5 was viewed as .NET Framework 5. Which seems to be why the version of what is basically .NET Core after .NET Core 3.x is .NET 5, so it fits expectations whether viewed as a .NET Core version or a .NET Framework version number.
Enterprise will no doubt keep legacy .NET Framework 4.8 around for legacy apps—the same way they do Framework 1.1 and 3.5.
> It's like merging Java and JavaScript "for clarity".
Not really. .NET Core can be viewed as just a production-ready but not feature complete early release of the next major version of .NET Framework, which involved major reengineering, and which will be released as .NET 5 when it is feature complete.
You already need .NET Framework 1.1, 3.5, and 4.8 to ensure you can run anything ".NET" due to past compatibility breaks. This is just another one in the chain and why major version numbers exist. You'll be able to install all of them side-by-side just like you can now and the only issue is if you want to use dependencies that only target a different version than you're currently using.
That reborn C++ is being driven partially by the Windows team, that owns C++ at Microsoft and never was big friends with the idea of managed code on Windows.
As for Windows, being stagnant, unless one is living in SV, it is quite relevant for anyone doing desktop, laptop and 2-1 software.
> Or will I need to buy yet another VS upgrade to enjoy it in full ?
Don't most developers using non-Community VS get it via a Visual Studio subscription, either annual Standard (formerly, MSDN) ir monthly Cloud, both of which also include current and former Visual Studio downloads?
My take on this, is it means that .Net Framework and Mono will cease as separate platforms... and .Net 5 will be effectively Standard 3.0 with code from Core, Mono, etc as a single, unified framework.
The are deprecating all of the past in favor of .Net 5
I don't think they would deprecate Framework yet. A lot of application rely on it. I think they would support it less (see OWIN implementations), but Framework still feels very active.
I'm curious and don't see anything. But what about things like IPC? Is WCF available yet? Is there an abstraction for namedpipes for all the platforms?
I'm primarily a .NET developer - I haven't seen WCF used in a new project for maybe 10 years or so. It lost out to simpler, JSON-over-HTTP a long time ago, and good riddance!
Ok, I get if they're looking to scale and have them on multiple machines. But I tend to use namedpipes and/or shared memory because I need fast access between multiple services on the same machine. I don't need to scale.
Semi-tangent, but as someone who didn't try to follow AOT compilation but very much wants to, would anyone have tl;dr instructions using the current version of .NET on how to turn a HelloWorld.cs file into a native HelloWorld.exe? You'd think it's just calling a couple of commands on the command line, but every time I've searched for it I've come across pages and pages of documentation I had no time to look through.
1. Get Visual Studio.
2. Install .NET.
3. New > Create New Project.
4. Choose Console Application (C#).
5. Rename Program to HelloWorld.
6. Go to properties and change Startup object to "ProjectName".HelloWorld.
7. Run
That just gives me a .NET EXE, not a native EXE. Also I was looking for compilation instructions I can run myself (like csc HelloWorld.cs), not an IDE to run everything for me.
This is basically .NET Core + stuff, hard to believe they'll relicense it. The Windows-only add-ons might have different licenses but I think they've Open Sourced even those bits.
Is it just me, or are all critical comments being downvoted here. It seems like this thread is overrun by PR folks and microsoft employees.
In the techcrunch windows terminal thread, one of the top comments starts with "I've been developing on both MacBook Pro's and Windows laptops for 15+ years now, on a daily basis, and I can confidently say that Windows laptops are superior to MacBook Pro's for development in every way.".
It reads like an infomercial. What is going on? Did the "hacker" community suddenly fall in love with Microsoft?
Another gem: "Satya seems to be the rare visionary CEO of a megacorp, instead of just defaulting to a defensive and reactionary stance like most other leaders."
I see many for and against points towards Microsoft. I don't pay attention to Satya comments but I feel the same can be said for those as well. More importantly, why do you believe the opinion of the dev community towards Microsoft should be swayed one way or another?
If they do a good job at supporting development on all platforms, and their intentions are clear and any intrusive additions can be spotted and built out effectively, why should they not be commended for it?
The problem isn’t migrating the code, that’s actually doable. The problem is that we are maintaining actively developed apps that we want to keep on the latest and greatest runtime, expect yearly performance improvements and also have tons of third party proprietary .Net 4.x dependencies for. The people manking those (one example in my case: AutoDesk) may or may not port these libs to core/5 ever. And without them we are stuck on the old framework and now even the old C# version.
It would be great to see a binary conversion/transpiler tool that converted 4.X libs to 5, checking the API compatibility and maybe even shimming some known holes.
Looks like MS realized they made a mess with .net core ...before thinking through how they should have done this...
It was really not difficult to see ..if they wanted to make .net open source and their BA, PM and developer should have seen this coming... after MS bought Xamarin..they could have worked on mono and make things easier for everybody... Now they are abandoning again this new '.Core' bandwagon...so much money and time was spend by community on creating and building libraries product...
I just convinced my PM and team, that we should consider .net core and they have agreed...we have started development of our new app..
This news will make things more complicated...Sigh
Edit: Quite negative votes..No need to down vote..just explain your viewpoint with more civilized means using "reply"
> Looks like MS realized they made a mess with .net core
Looks like .NET Core did exactly what it was supposed to; provide a early-usable bridge to where .NET was headed for the people who didn't have legacy compatibility requirements while the implementation hat was the future got to the point where it could subsume the role of the legacy .NET Framework.
> Now they are abandoning again this new '.Core' bandwagon...
No, they are abandoning the old .NET Framework, because everything needed will now be implemented in .NET Core. They are also then skipping a major version in the numbering for .NET Core (so that the version number is also greater than the last-ever .NET Framework version) and dropping the modifier “Core” from the branding because there is no longer a “.NET Framework” for core to be contrasted against.
actually i think .net 5 will clear a lot of stuff up. basically there is no more naming confusion and once we are on asp.net 6 no version conflicts will ever be there.
its the best step they could do.
they also communicate clearly now that there will only be one dotnet implementation in the future, .net 5 and forward. in the past there was no clear message what will happen with mono, .net4x, etc...
Sure, but you can view things as "where do I assign blame" or "what are my fixed inputs." If you look for something to blame, maybe it's that people lack reading comprehension. If it's enough people getting confused, and it matters to you that people understand things -- even if things would be solved by them reading/understanding the right things, you need to change what you can change, because you can't change your fixed inputs (in this case, your audience).
The differentiation of .NET Core allowed the team to leave legacy problems behind and focus on multi-platform first and foremost. Now that .NET Core has been established and has more or less reached parity with .NET Framework, there's little reason to continue promoting the latter, and thus the name "Core" is redundant because it is the only future for the .NET platform.
I think it's safe to think of this not as abandoning .NET Core but conversely they're promoting the technology behind .NET Core as THE future.
I would expect the migration from .NET Core 3.1 to .NET 5 to be quite straight forward.
This announcement just means they'll call the next version of .NET Core .NET 5 and kill the original Framework for good. They are not abandoning .NET Core, just changing the branding.
This is .NET Core still. They're just dropping the "Core" word from the name since all the other frameworks (Framework, Mono, Xamarin, PCL) are now retired.
If you're building with .NET Core now, you have nothing to worry about.
vNext has already been historically used in the context of ASP.NET to refer to ASP.NET (not to be confused with ASP.NET MVC) v6. We restarted the versioning back with ASP.NET Core, now on version 2. Entity Framework used to be a .NET framework component but is now standalone, and has a Core version? Does Blazor (or is it Razor Components now) share the .NET branding?
Separate to the web stuff, we have the .NET platform - .NET framework is the non-cross platform version for which we're on version 4, but it implements .NET Standard v2 along with .NET Core, which has a Linux runtime. Mono also implements .NET Standard v2 and has a Linux runtime.
I remember many years ago when we also had Microsoft .NET Passport.. which was completely unrelated to everything else that I've mentioned related to the .NET brand.
And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?