ASP.NET Core 3.0 will only run on .NET Core | Hacker News Reader

ASP.NET Core 3.0 will only run on .NET Core

github.com

178 pointspolskibus218 comments

This is good news I think. The fragmentation is quite annoying and not needed I believe. We moved everything (15 years of code) to Core 2 and it was not a lot of work. I could not be happier; the experience for developers is so much nicer.

How is it nicer? It's a .NET shop but devs are free to use linux as their OS?

Also not tied to visual studio to build. `dotnet` is an node style command line tool.

You haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.

You've never needed Visual Studio to build .Net projects. They have supported MSBuild from v1.0, you just needed to write the project files by hand - a very tedious process.

It's just that building from Visual Studio is by far the most convenient method.

MSBuild was introduced around .NET 2.0 after Ant's introduction in the Java world.

Before there was a project format, callable with devenv command line tool.

Speaking of the project files, the new csproj format is my favorite thing. We used to always get conflicts in them, and now we basically never do.

But there was no good way to edit .csproj files without an IDE and you needed to edit them for every source file you added (or moved).

Now you don't have to edit them as often (wildcards for files), they're easier to edit by hand (because they contain almost no clutter) and there are also command line tools to edit them (like dotnet add package).

Wildcards have been supported for source files for many years.

    <Compile Include="**/*.cs" />

I was doing this back in the .NET 3.5 days.

But nitpicking aside your point is well taken, the developer experience is far better with dotnet core.

As I understand it, if you ever opened such project in VS, it would replace the wildcard with the current list of files. So the usability of that approach was very limited.

Correct. It wasn't really usable.

Ah, I see. I wasn't using VS (which is why I found the wildcard trick). It seems like VS was the issue then, and one of the reasons donet core has a better experience is because it's much less bound to VS.

It also makes running Docker a whole lot easier. I know there is Docker for Windows, but it feels like a red headed step child compared to Docker on Linux.

^ that's now how Docker works. aka, the whole point of Docker is it doesn't matter what the host OS is.

That's not really true, OS definitely matters with Docker, both on the host and the container. Docker for Windows uses a VM to run Linux containers.

> OS definitely matters with Docker, both on the host and the container.

What OS in the container? A docker container is not a VM. Most of my containers are on the order of 10s of MB, and just contain a single binary.

I'm not disagreeing to any of that, what I'm saying is that to run a Linux Docker container on Windows, you'll need a Linux VM which runs Docker, which is exactly what Docker for Windows does for you using HyperV.

You're right on that, but there's no "OS" inside of a container to speak of.

A 10mb Linux container will still share the Linux kernel with the host, hence it's still running on Linux, even if it doesn't have any dynamic dependencies.

There's no OS "inside" the container, no, but it's still dependent on an OS.

I think we agree. :)

Docker can also make use of Windows containers.

I know, which is why I said Linux containers. Although, Docker on Linux can't run Windows containers, can it?

Certainly not, containers are a kernel level feature.

And Mac OS X, also a lot of work was done to make Core nice; it builds fast, low latency for ASP.NET and more. I use vim under Linux and I could not be happier. I was always against the choice for .NET because of the lock in; now that that is gone, it is great.

One improvement that doesn't get enough attention, IMHO, is that Asp.net core is now performant as hell.

https://www.techempower.com/blog/2016/11/16/framework-benchm...

Well it has always been performant. The whole Stackexchange is built with ASP.net, and it render things 10x faster than Ruby Rails while requiring 10x less hardware resources.

[1]https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

I think many were more concerned about .NET performance against tech in the same class, mainly the JVM, which previously blew .NET out of the water in the benchmarks for a number of years.

From the Techempower blog post I linked to above:

"The degree of improvement is absolutely astonishing, going from 2,120 requests per second on Mono in Round 11 to 1,822,366 requests per second on ASP.NET Core in Round 13. That’s an approximately 85,900% improvement, and that doesn’t even account for Round 11’s hardware being faster than our new hardware.

That is not a typo, it's 859 times faster! We believe this to be the most significant performance improvement that this project has ever seen."

In the past, TechEmpower benchmarks only ran on Linux, so their benchmarks for .Net actually used the Mono project's implementation of ASP.NET, which was slow.

That's why the increase was so significant. If they were comparing ASP.NET Core with .Net Framework on Windows, the difference would have almost certainly been much smaller.

I see - good point.

I saw claims of a 30% perf increase moving to .net core for a major software company. Can't remember which one, but that's still pretty impressive...

Perhaps you're thinking of Microsoft moving Bing to ASP.NET Core 2.1, with a 34% performance improvement: https://blogs.msdn.microsoft.com/dotnet/2018/08/20/bing-com-...

Mono has always had terrible performance. It was mostly useful as a way to sell developers who wouldn't normally go for a Windows-only solution on something that was effectively Windows-only in practice, if you cared about things like performance.

As well as the underlying .NET Core framework, and .NET in general. We have great new memory types like Span<T> and Memory<T> and tiered compilation, along with thousands of other improvements that has made major improvements in performance.

Which aren't being fully backported to .NET Framework, whereas many libraries still don't run on Core.

So? We're talking about .NET Core here. These new APIs are compatible with netstandard, so they can still be used with Framework but wont be as fast. What libraries are using these newer APIs but refusing to target Core?

ODP.NET for example.

Managed ODP.NET for Core is a partial implementation of the ODP.NET for the full .NET Framework.

Libraries using EF 6, because EF Core is still playing catchup with EF 6, and even .NET Core 3.0 won't support 100% of the EF 6 tooling.

Libraries using WCF, which lack budget for anyone to rewrite them and the respective clients into other transport protocols.

Plenty of other examples.

It is a completely different architecture from the ground up, completely re-written with modern development in mind.

For one example it has native support for dependency injection, and in general testability has massively improved since it was a core design goal.

They've also de-coupled several layers, which is hugely powerful since you can write your own middleware. For example check out this article on "Handling Errors Globally with the Custom Middleware"[0].

If you want to see how different it is from .Net Framework look at this diagram:

https://msdnshared.blob.core.windows.net/media/2017/06/06221...

[0] https://code-maze.com/global-error-handling-aspnetcore/#buil...

The diagram (and your comment) appear to be about ASP.NET and don't tell anything about .NET Core compared to, say, .NET Framework 4.5.

Frankly because nothing outside of the .Net Core's Web/Asp.net/MVC/WebAPI improvements actually matters. And the changes there are massive and significant.

While you can technically create Forms, WPF, and UWP applications using .Net Core on Windows, that isn't really the direction or focus of the framework. Just a niche for legacy software or people who continue to need Windows specific desktop applications.

https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2F...

Console applications might have a future for cross-platform headless sever loads. But outside of that it is a web framework that happens to support non-web projects on the side.

It is competing primarily with e.g. Java, Ruby on Rails, Node.js, PHP, etc.

It really depends on how much you are dependent on third parties that don't update. I've been stalled at 3.5 then 4.5 waiting on my dependencies in the past.

Just curious what dependencies are causing you so many issues?

Skype for Business SDKs, primarily. That is basically our business. Teams is the new hotness, but doesn't have any Api access.

Makes sense. They keep claiming Skype for Business is dead, but Teams in my opinion is very far away from being a realistic replacement.

I've not been very impressed with the desktop application at all (although the web-site is "fine").

I have deployed teams in 'island' mode for our org and I'm a bit disappointed with it - we've had firewall problems with external attendees and have had to switch back to skype for that case. A few users have had the teams client crash repeatedly during calls. I don't see how anyone will move to it with issues like these.

Could you encapsulate these dependencies into a separate service? I did that a while ago in a similar situation but as always it depends on your specific situation.

One big one that isn't mentioned yet is Entity Framework. Now, before you say "But there's an Entity Framework Core!" it's not the same at all. It has nowhere near the same amount of features and performance nor integration into Visual Studio like EF has. This is the biggest blocker for us to move completely to .NET Core.

EF6 is part of .NET Core 3.0: https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on...

Partially, there is no guarantee of all EF 6 related tooling like the data designers will fully work with the Core 3.0, just the actual code execution.

Yes, I'm glad of it too.

I no longer need Windows to develop nor host, while keeping on a platform which is hard to beat (for my requirements).

This isn't change for the sake of it, it's to keep .NET relevant. VS and Windows have become pain points.

What kind of requirements fit .NET best?

I'm trying to decide between .NET and Rails 4 for a new project.

I chose core over node, because it has a better standard library with less 3rd party reliance.

On my last project, dealing with the multiple layers of dependencies with node became troublesome.

(static vs dynamic has equal balance, in my experience)

However, if it where not for Linux support (and Rider), I would have gone with node.

REST API + frontend framework => .NET

Greater than or equals..... ?

How soon we forget. That is obviously a CoffeeScript fat arrow function, after you're done adding the Rest API to the front end you callback to the .NET framework to execute it.

Looks like a Scala type alias to me.

Start by asking yourself whether you like static typing.

VS is a pain point? It remains one of the best IDEs out there IMO. What are your specific issues with it, aside from needing to run it on Windows?

I think VS is painful.

It's slow to open. It crashes frequently. It's hard to extend. It's absolutely AWFUL on system resources. Its settings are a complete clusterfuck (admittedly, mainly because it tries to be/do absolutely everything).

I also think VS is actually a bad teaching tool for new developers. It simply tries to hand-wave/magic away parts of the system you're working on that REALLY matter. It's like VS is stuck in the era where the idea of opening a configuration file in a text editor is "uncouth". Which is frankly insane, since navigating the frustrating and byzantine guis it throws up instead is an absolute nightmare. Worse, you really need to care about those config files and settings, having them hidden helps nobody.

Basically, I think VS Code is a better IDE (yes, IDE, not editor) in every way. It takes more work to get off the ground, but it's literally miles away a better experience.

I have no clue why VS is so bad. You would hope that as a commercial and primary development tool for a company as large as MS, they would be able to make it stable and fast. It's horrible. But so is XCode... I guess both try to cram in too much features and developers will (have to in many cases) use it anyway.

Then use VS Code?

But as a .NET developer of over 15 years now I disagree. VS Code is currently using 1,200 MB of ram on my machine while Visual Studio is using 1,700 MB. I have a much larger project open in visual studio. Out of the 64 GB of ram on my machine, this isn't even a factor. What kind of machines are you running on where this is actually a problem?

VMs

VS + Resharper (or better yet + VsVim) is a miles better experience

next on the list after VS would be Rider,

then VScode...

I cannot remember the last time Vs crashed, a bit slower to open, but percentage wise, I spend hardly any time opening it. Extensions are sort of more involved to set up, but it's not that hard to do. It uses a bunch of resources, but I have lots of resources for it, settings don't seem too out of the ordinary, like most things, it just works out of the box and has a deep set of settings to customize it.

Resharper absolutely tanks my performance. Not only does it slow down cold start by ~5x, it introduces input lag on each keystroke. Back in VS2013, R# was indispensable, but with VS2017 the only feature I miss is namespace refactoring. It's also clunky how it gives you effectively two IDEs with two databases mushed into a single window.

I'm trying to wean myself onto VS code now (with vim keybindings), but being forced to stay in a single window is tough to swallow.

I keep being disappointed by performance on InteliJ products.

Maybe because I don't have 16 GB, Xeons with SSD at my disposal?

So far Eclipse and Netbeans still outperform them, unless I turn on laptop mode and disable the majority of plugins.

I loved VS, having used it since it was MSVC.

The UX of VS2013 was the tipping point for me. And they removed macros. Dropped setup projects with no real upgrade path. The direction it moves is what benefits Microsoft.

And the cost has become unjustifiable, now that it's no longer a "must have".

Without ReSharper (which just adds to the bloat), it's primitive (but improving).

The debugger, however, has always been the best I've used.

So in other words Microsoft doesn't think .net standard is a practical approach to prevent the fragmentation of the .net ecosystem and won't use it themselves.

Also it probably means blazor (which runs on mono) won't be able to share libraries with asp.net core...

The core issue is that it is too hard to update the full .NET Framework without making breaking changes in this Operating System component. As actually mentioned by David Fowler, if there are missing API that are required in .NET Core, requests for them can be made.

I cannot find the comment from @terrajobst in Github anymore but it states that it is simply not possible to port some of the breaking changes to the .NET framework (because they are breaking changes in the CLR, and maintaining a third CLR version (2.0, 4.0, vnext) is very hard because of a number of shared components used).

edit: It appears some comments have been deleted, luckily we have still mail notifications from Github.

> > Do what you promised: make .NET Framework a stable framework that evolves slower instead of a dead end for the ones who trusted you when migrating to ASP.NET Core.

> That still makes the assumption that .NET Framework will eventually get all features .NET Core has, but with a time delay. We learned that's simply not realistic. We can either decide not to innovate drastically in .NET Core or accept the engineering reality that a good chunk of the new features will never make it back to .NET Framework. We believe that we serve our customers best to preserve .NET Framework's core value prop (a mature & rich development platform) while also allowing customers to exploit new capabilities on .NET Core. Moving forward, I'd expect that we'll be more willing to innovate in areas that require runtime, library, and language changes like we did for Span<T>. While these things are costly, they also allow us to change the way people can write code. A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

And later on:

> > What prevents you from introducing a new side-by-side .NET Framework version (let's say .NET Framework 5) that includes those "risky" changes? Again, it's not a technical issue.

> What makes you think it's not a technical issue? Shipping side-by-side versions of .NET Framework isn't a workable solution. First of all, it's fairly expensive due to the fact that it's an OS component and thus needs to be serviced. You have no idea how complex our branching/servicing/patching strategy for .NET Framework 3.5 and 4.x is. Adding a 3rd one is close to impractical. Secondly, just doing that also has risks, as we need to make changes to activation in order so select the correct runtime for things like COM activated managed components. And that begs the question of whether or not we support in-proc side-by-side as well and with how many combinations. It's not a simple task and not free of risk either.

> A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

I suspected that but it's good to see it written. It means not only the target will become independent and incompatible but that also the C# syntax will diverge between Core and Full. That's a death sentence for Full.

I think that writing has been on the wall for a couple years now. .NET Core 3.0 supports WinForms and WPF, as additional death nails for those keeping score.

It's not really clear to me what the difference between .NET Core 3 and a '.NET Framework 5' would be.

For users, having to install .NET Core 3 runtime (if the app doesn't ship it internally) doesn't seem like a different thing than having to install .NET Framework 4.x when it first came out.

It wouldn't be surprising if future versions of Windows started shipping with .NET Core pre-installed.

Why is .NET Core so different from this perspective?

The full framework is part of Windows, and contains shared components such as COM activation, and is also part of IIS when applicable etc.

> It wouldn't be surprising if future versions of Windows started shipping with .NET Core pre-installed.

The UWP .NET stack seems close enough to .NET Core (esp. when using .NET Native) to posit that this is already the case. (Though there are still subtle differences between UWP .NET and .NET Core, they seem very close to converging.)

The .NET Core runtime (for a specific platform) can be bundled with the application so the user doesn't need to install it, and every application can ship with the exact version it prefers.

This wasn't possible with the .NET Framework, it needed a global install and, from 4.0, it upgraded in-place only.

Exactly, to ensure critical vulnerabilities do not get patched in your app when one patches the machine! One would have thought Microsoft would have learned from the experience of java...

In .NET Core you have the option. You can do a standalone deploy or depend on the system wide installed version of .NET Core. In the latter case it is an sysadmin issue.

Are there solid reasons why blazor cannot move to .NET Core? I know they require an ultra slimmed down runtime, but maybe there's ways to achieve that which could be upstreamed.

It is a simple matter of programming!

I suppose Blazer would eventually move to CoreRT when it is ready.

Depends on what your definition of "solid" is. Since most of the shiny new stuff is coming out on .NET Core first (think Span<'T>), it means that if a project is targeting .NET Standard (a set of APIs that can run on .NET Framework or .NET Core) it has to wait until that new stuff is ported to the other frameworks and a new version of .NET Standard is released.

> most of the shiny new stuff is coming out on .NET Core first

I hadn't fully appreciated prior to this post that .NET Core has things that aren't in .NET Framework, let alone .NET Standard. I thought it was a portable subset (a core, if you will) of the full .NET languages and APIs. I don't know whether that makes me more interested in Core, but I'm certainly less inclined to target any other flavor.

ha, Yes it often seems that MS is intentionally trying to confuse developers with their naming. I truly do not understand it.

Then again, two hard problems in CS, etc. etc.

Core is one of those Microsoft branding words that wound up used everywhere, denotes one thing, but means almost something else entirely. (Not unlike the .NET brand itself in its early years.) In the developer side Core has meant "open source rewrites that can break backward compatibility to move forward".

(Windows has also had several Core-branded things, at least as internal brands that have externally leaked over the last few years or been used to describe Windows Insider initiatives, but there they seem to more actually mean "core" as denoted as pure subset, though it sounds often in those cases they did imply nearly-from-scratch rewrites like the Developer initiatives with that branding.)

Well, .Net Core started as a subset of .Net Framework APIs. Now that they're adding a lot of them back with .Net Core 2.0 and 3.0, it's no longer accurate.

Though ASP.NET Core was never really a subset of ASP.NET.

.NET Core was never a pure subset of .NET Framework API: it broke compatibility in some places, and it had new features/capabilities in others, leaving the full .NET Framework to catch up on those. (There's an interesting overview of some of that in the histories of the .NET Standard versions < 2, when it sometimes felt unsure if the Full .NET Framework would be .NET Standard compatible, because .NET Core had the wheel on .NET Standard.)

Span<T> only requires .NET Standard 1.0, so it came out for Core and Framework at the same time [1].

.NET Framework only has the portable implementation though. The fast implementation requires support in the runtime, and Framework may never support fast Span<T> [2].

[1] https://www.nuget.org/packages/System.Memory/4.4.0-preview1-... [2] https://github.com/dotnet/coreclr/issues/18280#issuecomment-...

Did not know that, thank you!

Also, .Net Framework still doesn't have support for Span<T> on existing types like Stream. Though those APIs will be in .Net Standard 2.1, so presumably they will be in some future version of .Net Framework too.

Isn't Blazor is becoming part of ASP.NET with .NET core 3.0?

I feel like .NET Core has become a technology I should be considering for my team, not least because it is so much easier to find .NET devs in the UK than just about anything else (apart from php WordPress and Magento peeps).

I feel I know nothing about it at all, and I wonder if anyone would be kind enough to suggest some resources? I'm primarily going to be working with enterprise CRUD apps, and ERP stuff.

Out of interest, what are the options for cross platform desktop apps, if the Windows GUIs are going to remain closed source?

> Out of interest, what are the options for cross platform desktop apps, if the Windows GUIs are going to remain closed source?

.NET Core 3 will support WPF -https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...

No, it's not cross platform. WPF will be supported on .Net Core runninng on Windows platform only - previously you needed .NET framework to run WPF apps - given everything will be .NET Core going forward this move makes sense.

Oops, you’re right, didnt read my own link closely enough.

I guess Avalonia is the only option for cross platform .NET UI?

https://github.com/AvaloniaUI/Avalonia

There is no official cross platform desktop GUI solution for .NET core. There are third party efforts however, take a look at avalonia and eto.forms.

Or alternatively think of doing a web app in ASP.NET core. If you don’t need a bells and whistles SPA then ASP.NET core MVC is a very performant solution.

Thanks. I think ASP.NET core MVC is what I should be looking at. Are there any books you could recommend?

A nice trick a lot of .Net devs don't use is code generation(T4 templates). Generate a Enitity Framework context, use Visual Studio to add a controller, select the context, basic crud and HTML generated.

I take that, style it, copy the code into the service layer and 70% of the boring code is done. I can't type fast enough to make that much code that error free and quick.

I've never had T4 in a project where I didn't immediately have problems. It also doesn't seem to really be a thing for .NET Core...

If you use Visual Studio, the Add Area, Add Controller's are all using T4 templates. VS Code may have a plugin for it, but that is why I mentioned Visual Studio, which I have to pay for so I use it more :)

Fine by me. The faster we can get everyone off of .NET Framework, the better.

Agreed. Having both around is a nightmare, I still can't believe they ever did it this way.

I completely understand why they did it, and it actually makes a lot of sense to me. I wish PCLs never happened and I wish .NET Standard happened a lot earlier (seriously, the idea of platform profiles vs a standard API is idiotic and completely unmaintainable).

The other place MS has not executed well is versioning/naming and the communication of those versions/names. But soon(?) it'll all be .NET Core and we can put this behind us.

Its actually very nice, you can update your framework projects to 4.7 which can cross compile as dotnet core 2.1 then after you are comfortable with the dotnet core build you can drop framework.

Any way you could provide more information about this? I have some legacy projects on 4.7 that I would love to migrate over to core 2.1

If you're using .Net Core version of csproj, it's the difference between e.g. <TargetFramework>netcoreapp2.1</TargetFramework> and <TargetFrameworks>net47;netcoreapp2.0</TargetFrameworks>.

I don't know if there's a good way to migrate the csprojs automatically (maybe https://github.com/hvanbakel/CsprojToVs2017?), but it shouldn't be that hard manually (by creating a new project), assuming you have just a few projects to migrate.

Does this mean .NET framework is being dropped slowly for new projects?

I am using asp.net core 2.1 for .net framework because it comes handy to load third party .net framework dlls inprocess. I do not have any power to convince third parties to move to .net core.

Slowly, but yes. This is already happening for ASP.NET on .NET Core 2.1. And .NET Core 3.0 will support some desktop cases.

Most major libraries have been ported. What are you using?

Very niche, proprietary libraries

Adomd lib for communicating with SQL Server Analysis Services (from MS) has not been ported. WCF is also absent from .net core which makes migrating to .net core much harder for existing projects.

I'm not sure (haven't tried it), but I believe there are few tricks where the assembly can be loaded on .NET Core _but_ the called APIs in the assembly must of course be present.

WCF support is in Core, we use it extensively to communicate to legacy systems. It is missing some features, like WCF Relays. As for hosting WCF services on Core, we've been trying to distance ourselves from WCF in favor of other technologies.

I think OP is referring to server-side WCF in Core, see also this discussion: https://github.com/dotnet/wcf/issues/1200. As we're currently exposing WCF endpoints, this is also something that's holding us back.

There are a lot of first-party Microsoft dependencies that have not been updated and probably never will be. For instance, I do a lot of work with the Skype for Business SDKs, which are old and have D-level engineering assigned to them.

Skype for Business is going away too. As soon as we moved to Teams I stopped opening my SfB client completely.

Unfortunately Teams has no usable extension API that would allow the funtionality of the old UCMA and UCWA apis.

Some of it has already (Beta) moved into the Microsoft Graph super-API: https://developer.microsoft.com/en-us/graph/docs/api-referen...

Presumably, as Teams gets closer to eating S4B it will catch up on more of the rest.

ExcelDNA, Google OR-Tools, COM apis.

I didn't hear about Google OR-Tools before now, but they seem to support .Net Core: https://developers.google.com/optimization/install/dotnet/so....

COM support is coming to .NET Core 3.0

* EO.pdf for converting HTML to PDF. It uses a headless Chrome instance to render the page and then converts it to PDF. We have a lot of complex page layouts, such that switching rendering engines wouldn't be a simple tasks either.

* Server-side WCF endpoints. We're currently exposing WCF endpoints, which we must maintain for our current users.

EVO PDF has a .NET Core version

http://www.evopdf.com/netcore-html-to-pdf-converter.aspx

.NET Framework isn't going anywhere. It is and will remain the basis for Xamarin.

.NET Framework 4.8 will be the last release though. Innovation will happen in .NET Core and the packs available for it (e.g. the Windows Desktop Pack).

For current binaries. But what makes you think we won't start to see some syntax changes that can only run on .net core? That's the spirit of this evolution.

Xamarin isn't based on the .NET Framework. It is based on Mono which is in turn already consuming a lot of code from CoreFX (== .NET Core) and that share will only increase over time.

Source: I'm working on the Mono BCL+Tools team at Xamarin/Microsoft.

Does this mean .NET framework is being dropped slowly for new projects?

Yes.

It's not a secret. Microsoft has said that .Net Framework is basically in maintenance mode and "will move slower". They are moving EF6, Winforms, and WPF to .Net Core (Windows only).

https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on...

I've been developing on top of Microsoft environments for over 20 years and .Net is by far my favorite language. But, the writing is on the wall. Anyone who wants a long term career in development needs to run away from Windows as fast as possible and slowly move away from focusing exclusively on .Net.

Linux even dominates on Azure.

https://www.zdnet.com/article/linux-now-dominates-azure/

Microsoft knows that Windows can't compete in the cloud and selling Windows for desktops is not the future.

I will keep holding on to .NET and Java, regardless of ongoing issues, until an alternative is able to match at least half of the existing tooling, libraries and supported platforms.

From my point of view the grass is still greener in this side.

Parent post was confusingly worded.

he's saying windows as a programming platform is dead. You can keep .Net and Java, its just going to be .Net core and Java, and its going to run on linux machines.

Its a matter of time until Visual Studio runs on linux, but that's the direction they're heading. Visual Studio Code already does

he's saying windows as a programming platform is dead

Not exactly. I'm saying that Windows as a deployment platform is dead. You can keep developing on Windows and deploy to Linux. I do it all of the time.

I'm not convinced this is the case. MS is developing various alternatives to Linux, such as a CLI only version, and a version with a different faster kernel.

But I agree that frameworks which can ONLY deploy to Windows (.Net Framework) will die in favor of those that are cross platform (.Net Core).

What competitive advantage does Microsoft gain by having a non GUI server OS? That just becomes a more expensive server OS than Limux.

Tooling and Windows still does a couple of things better than most UNIXes.

Windows Server Core 2016 has barely any usage. Nano Server came and died, basically being an empty shell that can only be a base image for Windows containers.

Linux won a long time ago and is so far ahead in tooling and ecosystem support that it just isn't worth it to compete in the server OS space. And that's better for everyone since we can consolidate effort and products.

I don't fully agree that a Linux monoculture, or even a POSIX one, is better for everyone.

Like every monoculture things either stagnate, or we start getting features just to work around botherom instead of actual innovation.

I wouldn't be surprised to see VS Code replacing VS entirely. Visual Studio is built on WPF and it's probably as massive of an effort to port all that over as it is to bring Code up to snuff.

The Electron pleasure.

I tremble to imagine how many cores and GBs would be needed to have VSCode with the same capabilities of Visual Studio Ultimate, while running at comparable performance.

VSCode has performance sensitive bits (such as file search) written in Rust and (I believe) C++, so it's not out of the question...

I am forced to use it in a couple of projects and fast it is not.

Specially when comparing with the likes of Sublime, which I gladly payed for.

Will never, ever happen. Electron is not feasible, and moreover, the VS team is not going to rewrite all their funcionality, when they can't even give us a 64 bit VS.

> when they can't even give us a 64 bit VS

Wouldn't that encourage a switch to a totally new system? If you have to do a ton of ground-up work to get VS working 64 bit, you could argue you as well expend the same effort in getting VS Code to a level where it can be used instead of VS.

I dunno, people have been hoping for a 64-bit VS for like a decade. The excuses have been unconvincing.

What are the reasons for wanting 64-bit?

Microsoft's semi-official stance on why VS isn't 64 bit...

https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting...

I thought this was crap three years ago, and I think it is worse now.

Because?

Because solutions and IDE functionality is getting more complex and processes needs access to more RAM, which is cheap and plentiful and pointless to not use. Saying that every extension should be its own process isn't sufficient and ignores the extra complexity, inefficiency and resources that approach takes.

What's worse is that VS doesn't even follow its own recommendations. Even with the massive upgrades over the past year, it's still extremely slow and laggy on any sizable solution.

Actually being its own process it is something I came to agree upon.

In process plugins look cool, but they just bring everything down when they misbehave, plus it is another opportunity for exploits.

Peformance can be improved by actually writing the plugins in languages that compile to native code and eventually use shared memory.

Now if one uses node for everything naturally it doesn't scale.

Visual Studio depends heavily on WPF and COM. I don't think it's going to be running on Linux anytime soon.

There is already a version for Mac from Microsoft.

https://visualstudio.microsoft.com/vs/mac/

And there is always JetBrains Rider for Linux

https://www.jetbrains.com/rider/

Visual Studio for Mac is just Xamarin Studio rebranded, not really related to VS for windows.

There are two separate trends with the direction that the industry is going. One trend is moving faster than the other.

Windows -> Linux: Using Windows on the server is a dead end. Every time I have to use anything Windows based, especially in the cloud, it's a double hit -- the same compute resources cost more because of licensing and you need more resources to run Windows. I can't imagine why anyone starting a project today would tie themselves to Windows. Even if you like Windows and .Net as a development platform (I do), it makes no sense to deploy to Windows if you don't have to.

.Net Core -> Javascript Everywhere. I hate the trend as much as anyone, but, I don't see .Net Core getting much adoption for greenfield projects unless their developers are already .Net users. Even the more career driven .Net developers are moving toward Node for resume reasons.

Out of the two, it's career suicide to focus solely on Windows. .Net Core has a longer shelf life and you can remain marketable if you know .Net (Core/Framework) + Windows and Linux

There are plenty of Windows shops out there using Windows servers.

Also the cloud is still a foreign word to many companies.

Finally, every time I have to touch Node eco-system it saddens me, npm gets several thousand modules for a plain Hello World and lets not pretend V8 is the same performance ballpark as using a strongly typed language that can be AOT/JIT to native code, with real multi-core support.

I'm not arguing that Windows is dead. But, I think you will see your career stagnate at best if you focus solely on Windows.

I'm also not arguing that every company will eventually go to the cloud or that every company will move toward Node. But, staying in the MS ecosystem will also lead to career stagnation. I'm nowhere near the west coast and I'm mostly your bog standard "Enterprise Developer/Architect". But the minute I put "AWS","Linux","Node" on my LinkedIn profile, the more serious discussions I had with consulting companies (not recruiters) with offers of $20K-$30K more than companies were offering "Windows Enterprise Developers"

Here in Europe most enterprises are pretty much focused on Java/.NET.

Plus as you notice from my comments I do polyglot development, and luckily there are other options than spending 8h with Node every day.

Also building up soft skills and domain knowledge is another way to keep relevant, while staying on the same stack.

Agreed on Windows -> Linux. Disagree on .NET. I think that .NET has just opened up a HUGE market by 1. open sourcing and 2. working on linux.

I know that I was completely uninterested in learning it while it was a Microsoft proprietary project. But that was always a shame because from a language perspective, it's exquisitely designed. Now that's free'd up, I expect a lot more adoption.

Node is great, but it's actually pretty slow. And it doesn't have anything to compete with Rails/Laravel/Django/ASP.NET MVC which are still super-productive.

- Yours, a Frontend/Node/Python/PHP Dev.

I hope C# does become more popular outside of large enterprises, but I am not seeing it yet. I’m not abandoning it but I am adding Node to my tool belt just to play it safe.

.NET isn't going anywhere, it's just going to be Core.

I wish they would open source Winforms and/or WPF, both technologies could do with some love.

Effectively, this is what is happening now AFAIK, as they're being ported over to .NET Core, which is open source.

No they aren't. They are porting WinForms and WPF to Core but keeping them closed source.

I believe MS said they're considering open sourcing them when they're included in .Net Core 3.0. But either they didn't decided yet, or they decided against it.

Linux even dominates on Azure.

This has more to do with per hour billing. Over the long term no company wants to pay 2x for the same compute resources that they don't need to maintain.

For the on-premise enterprise you will continue to see sizable market share with Windows Server for the foreseeable future, since those companies already have Windows-trained sysadmins to manage them (along with their huge inventory of Windows corporate desktops).

And that's an issue for Windows sysadmins. They are a commodity. They are cheap compared to Linux admins and are easily outsourced.

Then what do companies need Linux guys for? If what you say is true, there's a large incentive for the industry to put you guys next on the chopping block by similarly lowering the complexities of Linux, or improving the Windows ecosystem to do everything else at least as well as Linux can.

Microsoft’s future is in the cloud. They don’t really care if you use Windows Servers anymore. They have no real motivation to make Windows lightweight enough to compete with Linux.

But I’m not a “Linux guy” yet. I’m trying to move up to being an overpriced “consultant” that tells companies how they can save money via automation, using best Devops practices, etc. and why they don’t need as many infrastructure people.

I’m a software architect who plays the role of an AWS Architect when necessary.

> Microsoft’s future is in the cloud. They don’t really care if you use Windows Servers anymore.

The Azure guys will happily tell you that they believe the best way to automate and run Linux servers is as VMs and containers on Windows Servers.

> and .Net is by far my favorite language.

Isn't .NET the runtime/environment and C# the language?

Yes, colloquially people use them interchangeably.

> They are moving EF6, Winforms, and WPF to .Net Core (Windows only).

What about webforms? I haven't been able to find any info on that one.

> Does this mean .NET framework is being dropped slowly for new projects?

Unfortunately, yes. I would've liked to have seen support for netstandard rather than a particular runtime, I worried that it means people will get sloppy and just target whatever their web framework is targeting.

You've luckily got three plus years of support, so hopefully in that time you'll be able to make a plan about 3rd party dependencies.

The v2.0 attempt's uproar: https://news.ycombinator.com/item?id=14297974

Note that one difference is that the 2.0 attempt was noticed by a user following commits to the repo. This time, they've made a public announcement about it.

I guess my thinking is that if ASP.NET Core 3.0 requires a different framework and there's no way to easy the transition through .NET Standard code, why should I consider ASP.NET Core 3.0 over any other framework? What makes moving to ASP.NET Core 3.0 appealing for an existing project is exactly .NET Standard.

If that goes away, then what's the draw? The product line will need to have a version with a compatibility break no matter what. Why should we favor ASP.NET Core 3.0 over anything else, especially when the vendor just screwed us for picking their last product, ASP.NET? Why wouldn't the same thing happen again when Microsoft releases ASP.NET Core Futuro 1.0 in 2030?

A link on the original announcement page states "Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.". If this is right the high coupling between the CLR and what really is a framework/library on top astounds me and is somewhat worrying. I'm foreseeing future deployment horrors. One of the advantages of .NET is portable IL code across anything that can interpret it similar to Java. If this is broken and I can only use .NET/ASP.NET Core CLR with certain native system dependencies installed then this big advantage of the .NET platform IMO is gone and creates some surprising non-intuitive issues.

You can see one example of this in the issue here: https://github.com/aspnet/AspNetCore/issues/3307. I install the package; then also need to install a system wide package using my package manager to back it? If I install the package I should be able to use it. It seems as if the GAC is back just for ASP.NET however? Unfortunately as I experienced recently installing the right asp net runtime doesn't necessarily fix the problem either; it just allows the app to start but then other run-time issues pop up. The only fix is self-containing the app - tough luck if your on a distro not supported. Maybe these are teething issues but the constant change between minor versions has been painful.

ASP.NET is no longer just another Nuget library it seems - it's now been promoted to be part of the CLR and this decision is the logical extension of that.

Now that Microsoft no longer has a "Windows or Office" angle to everything they do, what is their angle here (i.e. how does a cross-platform .NET target contribute to their bottom line)?

I know they generally want to grow (1) Azure, and (2) developer mindshare. I see how a cross-platform .NET Core contributes to Microsoft's developer mindshare, and perhaps how Azure could follow up by cornering the market on really great back-end .NET Core hosting and operations. Is there anything beyond that?

There are libraries for .NET Core that play very very nicely with Azure. And there are parts of Azure that play very nicely with their Enterprise software like Active Directory.

It's all circular.

Think about how many cross-platform products Microsoft itself is working on. And how many engineers it has that are already proficient in .NET and C#...

Microsoft will make major updates to ASP.NET Core, including integration of projects and frameworks, tighter integration with .NET Core, and integration with third-party open source kits, these improvements will help developers complete development work faster

The way the project is referenced and run on ASP.NET Core changes as the version’s iteration changes. In 1.0, ASP.NET Core itself is a “package” and appears in the project just like any other NuGet package reference. This has its advantages and disadvantages. Over time, this model has evolved. In 2.1, ASP.NET Core eventually evolved into a “shared framework” for .NET Core.

To know more about.net core follow our Website: https://crbtech.in/programmes/dot-net-training-programme

Worst PR move Microsoft could ever take. Developers don't need another Python 2 vs 3 debacle.

There should not be .NET Framework. There should not be .NET Core. There should be .NET, a singular powerful platform that does it all.

"platform" is vague and doesn't describe much on its own. .NET is vast, and the runtimes are what actually run the code packages on various devices.

.NET Framework has been the original Windows implementation and now we have a fast, lightweight and modern cross-platform implementation with .NET Core. It makes sense to consolidate on a single runtime that now works well on Windows and is at 99% parity with legacy features.

.NET Core is not on par. It is seriously lacking in vision and attitude. It has some nice properties like portable deployment and that's basically it. The rest is just one to one copy from .NET Framework, plus a bit of quick and dirty additions here and there without a further thought. Please note how the latter statement signifies the endangered future state of the platform.

"vision and attitude" is 100x more vague than platform. Care to actually explain what you think it should be then?

.NET Core is cross-platform. That is a massive change that you seem to just ignore.

Hopefully Core 3 has better serial port support. I've run into all kinds of edge cases for serial ports where things work great on the .Net framework but are flakey or non functional on Core 2. It's my only major complaint about .Net Core.

I've had better luck using OS api calls for serial ports. It's not portable, but it's the only way to understand the behaviour of the underlying driver, which can vary greatly with different hardware. It's very hard to get a vendor to fix their driver and firmware when you can't tell them which API calls they're making a mistake in.

That's probably what Core3+ will be. They will let the old framework (which was initially "COM+" remember, a windows only java replacement) just stay around for compatibility.

With desktop (WinForms etc) added to Core3 I don't see what project you'd choose the framework for.

Hm... Making a circle to reach the starting point.

I would suggest another approach: let .NET Framework incorporate the useful features of .NET Core, and then eliminate .NET Core altogether as an experimental and dead-end branch. Thus stopping the segmentation and saving the technology for the greater benefit of customers. Somewhat controversial, but much saner approach product-wise.

Having said that, I don't think Microsoft has the balls to pull the compatibility tricks like this anymore.

You could make the same argument about Visual Basic 6 vs VB.NET

Why was VB.Net & .Net needed at all? Why didn't Microsoft just continue development on Visual Basic 7 & incorporate some of the VB.Net features into it?

Personally I'd still prefer to be on .NET Core than on some hypothetical Visual Basic version 16, with a ton of compromises made for some slowly changing Frankenstein language of various backward compatibility hacks built in

Makes perfect sense, and seems to have been general expectation of the community for a long time. No need to keep maintaining 2 runtimes when there is a modern, fast, lightweight version that is cross-platform and will now be beyond parity at the next release.

I wonder if Stackexchange has moved everything to .Net Core and Linux along with ASP.Net 3.0?

They've already started moving to .NET Core: https://twitter.com/nick_craver/status/1031858480888639488

Is this the beginning of python 2 vs 3?

I somehow doubt it, most of the APIs (with the notable exception of some of the reflection APIs) are at parity and the language is the same.

This is more like a major library dropping support for a legacy runtime going forward.

What reflection APIs are you talking about? Do you mean things like AppDomain and remoting?

Yes, at least when I last checked, that stuff wasn't present.

When porting some reflection heavy code to .net standard I encountered several breaking changes. They were all easily fixed by using GetTypeInfo(), which is where a lot of reflection functionality seems to have moved. I remember reading that it was for performance improvements.

What version of netstandard?

I just checked the project.json from that library and it appears to have been 1.6.0. It was a while back.

Also, thanks for SignalR! It's a great library!

This is bullshit actually. They should also come out publicly and announce if .NEt Framework 4.8 is the last version or not.

Excellent.

I look forward to all of our .Net Framework only 3rd party dependencies being unsupported and abandoned instantly because there's no way anyone is going to bother supporting two distinct platform versions.

And also the humongous porting effort to move everything over if we want something that isn't half arsed and abandoned which is what happens in the long tail of any MSFT product cycle. When you phone partner support because something is broken and no one knows how to help you.

Another "fuck you" from MSFT. Just like that whole opt-out telemetry crapfest.

I want off this crazy train now. Anyone need a Python/C developer (where knowledge is valuable for more than a 3 year window)?

As a Python developer, are you actually surprised by breaking changes?

The Python 2/3 split originated a decade ago, after all.

Python 3 was released a decade ago.

Python 2 is still supported until 2020.

2to3 exists.

Python actually give a shit about their users.

What a lot of people seem to forget about .Net is that for those of us who have been around since day one, we've been burned over and over again by large product and framework deprecations over the years. This is one too many.

> burned over and over again by large product and framework deprecations over the years.

What large framework deprecations? I've been around and I don't feel burned at all.

WCF, WWF, UWP, AppFabric, EF incompatibility etc etc.

Basically the entire enterprise stack.

And I’m not even talking about the whole original .net and com stuff.

I feel similar. Espeically when you do desktop development it's hard to avoid being cynical about any Microsoft "innovation".

I'm using WCF on .NET Framework. The whole enterprise stack is still there.

Yes but the clock is ticking on its demise.

Assuming Microsoft ends .net framework at 4.8 that effectively ends new features. Although older code will keep working for the most part isolated that isn't the real issue. For example I ran into an issue last year where we had to retarget all of our .net 3.5 projects to at least 4.5 to support tls 1.2. Had that upgrade path not been available we would basically have had no other option but move to a new platform. Even though bug fixes can happen older code will effectively rot with time as other things improve.

Software rots just like physical products. Ongoing maintenance is required. Why would you expect old applications to be compatible forever?

> Software rots just like physical products.

No, it doesn't.

It may become less relevant/useful as market conditions change (like physical products), but it (apart from physical media it is stored on) doesn't also itself degrade over time the way physical products all do at varying speeds.

The binaries will run, but the world changes and if you want to keep up with those changes then the software needs maintenance, which is obviously the topic of discussion here.

> The binaries will run, but the world changes and if you want to keep up with those changes then the software needs maintenance, which is obviously the topic of discussion here.

Physical products both rot (degrade with time) and become obsolete. Maintenance addresses the former problem, redesign and upgrades address the latter problem.

Software becomes obsolete like physical products (and so needs redesign and upgrades), it does not rot like physical products (and so does not need maintenance.)

Software “maintenance” is a misnomer, and the idea that software “rots like physical products” is wrong or, at best, a poorly chosen metaphor, since what it does do is at best loosely analogous to rotting, but exactly the same as becoming obsolete, which is something physical products also do, so rotting is not the closest physical-product analog to what drives the need for continuous attention to software.

Fine then, the software is becoming obsolete as the environment changes. The original comment used "rot" so I continued, because I'd much rather have a productive discussion than a pedantic one.

.Net Framework (and ASP.NET) will be supported forever.

This is just about the specific combination of ASP.NET Core on .Net Framework, which will be supported until 2021, possibly longer.

Python 2/3 split had the real technological causes for it to be made.

In contrast, .NET Framework/Core split is mostly political.

Definitely not.

The original framework had decades of legacy and it can't just be redesigned without a major rewrite, which is not realistic or possible given the time and stability constraints. .NET Core is a new runtime with major differences (being cross-platform as a big change). This is much more technologically driven than Python 2/3 was.

You call it legacy. Many people call it the code their businesses rely on.

There is no need to rewrite it, god forbid. Instead, make it cross platform when possible, or exclude from shipping to other platforms.

Then, instead of shipping a segregated .NET Core infant, MS could (and still can!) ship .NET 5.0.msi, .NET 5.0.dmg and .NET 5.0.deb/rpm distributives.

Easy. No need to increase the amount of pain in this world. Just small, incremental, mindful steps towards the greater benefit of all living beings.

.NET framework isn't going anywhere. It'll be supported for years, if not decades, and will likely outlast many of the companies using it. What exactly is your concern?

Just because you use the word "easy" doesn't mean it is. I'm sure the .NET dev team understands their platform and created a new runtime as the most viable option to get all the new features and flexibility of .NET Core.

>I'm sure the .NET dev team understands their platform

They don't. People who initiated .NET Core are web devs. Good web devs. But they are million miles away from understanding the purpose, role and aim of the platform.

The guys who really got it are Sir William Gates, Mr. Steve Ballmer and Mr. Anders Hejsberg, to name a few. They shifted to other interest areas unfortunately.

Regarding the word "easy". Let's take a wider perspective. It should be easy for customers, right? There are a lot of them, say 10 million people. Making things easy is hard. So it gets hard for .NET dev team, say 50 people. The outcome: 10 million happy people, 50 people in pain.

Let's take a look at the current .NET Core approach: kind of easy for 50 people in .NET dev team. But hard for 10 million of customers. The outcome: 50 happy people, 10 million people in pain.

What outcome would you choose?

.NET Framework isn't going anywhere. Keep using it if you need to.

Why do you want/need to port something if it's already working fine?

yep. powershell is similar. because of the ongoing changes to .net underneath, moving to version 6 means supporting 2 versions; the legacy windows version (with all the modules), and the new .net core version. but because it's dynamically typed, its basically 1 million footguns.

Reply on news.ycombinator.com