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.
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.
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.
* 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.
.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).
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.
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.
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).
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 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.
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.
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.
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.
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.
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"
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.
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.
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.
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).
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.
> 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.
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.
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?
> 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.
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.
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].
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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?
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:
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.
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.
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.
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.
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.
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.
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?
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.
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.
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)?
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.
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.
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.
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.
.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.
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.
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.
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#...
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?
"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.
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 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?
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.
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.
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.
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 :)
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.
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.
221 comments
[ 2.5 ms ] story [ 245 ms ] threadThis is more like a major library dropping support for a legacy runtime going forward.
Also, thanks for SignalR! It's a great library!
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.
Presumably, as Teams gets closer to eating S4B it will catch up on more of the rest.
* Server-side WCF endpoints. We're currently exposing WCF endpoints, which we must maintain for our current users.
http://www.evopdf.com/netcore-html-to-pdf-converter.aspx
.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).
Source: I'm working on the Mono BCL+Tools team at Xamarin/Microsoft.
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.
From my point of view the grass is still greener in this side.
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
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.
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).
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.
Like every monoculture things either stagnate, or we start getting features just to work around botherom instead of actual innovation.
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.
Specially when comparing with the likes of Sublime, which I gladly payed for.
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.
https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting...
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.
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.
https://visualstudio.microsoft.com/vs/mac/
And there is always JetBrains Rider for Linux
https://www.jetbrains.com/rider/
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
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 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"
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.
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.
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).
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.
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.
Isn't .NET the runtime/environment and C# the language?
What about webforms? I haven't been able to find any info on that one.
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.
Also it probably means blazor (which runs on mono) won't be able to share libraries with asp.net core...
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.
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.
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 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.)
This wasn't possible with the .NET Framework, it needed a global install and, from 4.0, it upgraded in-place only.
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.
Then again, two hard problems in CS, etc. etc.
(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.)
Though ASP.NET Core was never really a subset of ASP.NET.
.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-...
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.
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.
It's just that building from Visual Studio is by far the most convenient method.
Before there was a project format, callable with devenv command line tool.
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).
But nitpicking aside your point is well taken, the developer experience is far better with dotnet core.
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.
There's no OS "inside" the container, no, but it's still dependent on an OS.
I think we agree. :)
https://www.techempower.com/blog/2016/11/16/framework-benchm...
[1]https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
"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."
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.
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.
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...
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.
I've not been very impressed with the desktop application at all (although the web-site is "fine").
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.
I'm trying to decide between .NET and Rails 4 for a new project.
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.
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.
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?
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.
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.
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.
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.
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)?
The Python 2/3 split originated a decade ago, after all.
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.
What large framework deprecations? I've been around and I don't feel burned at all.
Basically the entire enterprise stack.
And I’m not even talking about the whole original .net and com stuff.
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.
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.
This is just about the specific combination of ASP.NET Core on .Net Framework, which will be supported until 2021, possibly longer.
In contrast, .NET Framework/Core split is mostly political.
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.
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.
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.
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?
Why do you want/need to port something if it's already working fine?
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?
It's all circular.
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?
There should not be .NET Framework. There should not be .NET Core. There should be .NET, a singular powerful platform that does it all.
> why do I have to choose?
.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 cross-platform. That is a massive change that you seem to just ignore.
With desktop (WinForms etc) added to Core3 I don't see what project you'd choose the framework for.
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.
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
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?
.NET Core 3 will support WPF -https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...
I guess Avalonia is the only option for cross platform .NET UI?
https://github.com/AvaloniaUI/Avalonia
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.
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.
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.
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