The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop
github.com
github.com
Now, keep in mind that I actually thought (and still think?) that .NET and C# make for a very productive development environment. I didn't leave due to antipathy; no axe to grind here.
But...
"netcoreapp2.0"? "netstandard1"? "net4"? Huh? What?
From Scott Hanselman's reply:
.NET Core is side by side and it’s moving fast. It’s WAY faster
than .NET (Full) Framework can move which is good. By building
ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a
SUPERSET of .NET Standard) that means stuff can be built faster
than NetFx or even Netstandard.
And .NET Core is a superset of .NET Standard? How does that make sense? "Core" sounds like a stripped-down version of... something? But, apparently it's a superset. Because nothing makes sense any more.
My only point here is: at first glance, this is an utterly bewildering set of choices. I'm sure there's a pretty simple relationship between all these things, but the .NET people probably aren't doing themselves any favors this these naming choices and (what appears to be) fragmentation between .NET development targets.
* .NET Core - a new spin on .NET Framework for the cloud and such, not always compatible with .NET Framework but sometimes compatible. * .NET Framework (or "Full") - the .NET Framework we've known and loved, what was a few years ago merely known as .NET * .NET Standard - the bridge between the two, made after .NET Core so that they could break backwards compatibility to some extent, or they realized "whoops we gotta make a compatibility layer" or some other reason...
I'm not even sure what .NETfx is, nor what ASP .NET vNext was, and if it was just an alpha, all I know is in Sublime Text I don't have sane / easy options. On Visual Studio Code I can just install the "C#" plugin on the other hand and get going. It's not as good as Visual Studio's IntelliSense though.
One nice thing about .NET Core is the ability to develop from any platform and to deploy to any platform. .NET Framework needed Mono for that, I wonder how much of .NET Core will become Mono Core or something similar (if at all?).
.NET Standard is a standard that the 3 different implementations of .NET try implement (.NET, .NET Core and Mono). Any implementation of .NET Standard can add in extra functionality, hence superset, it's a bit silly.
.NETFX = .net framework.
their naming is a mess.
It's actually pretty smart if it's implemented correctly (Which it's not, there is another article floating around the moment which says that .net standard isn't working correctly because people pick and choose what to implement anyway).
So the .net standard is essentially like "interfaces" in code. It says, if you want to say you are .net standard 1.6 you must implement these things.
When you go to write a library and you want to release it to the masses. You would normally have to go "OK, do I want to write this for .net core or .net framework?". With .net standard you can write it in a way that you know that a call to some method will always be there no matter what platform is actually running the library.
A bit more info here : http://dotnetcoretutorials.com/2017/01/13/net-standard-vs-ne...
.NET standard something your libraries can conform to, which allows it to run on the old .NET framework and the new core frameworks.
Honestly having used python, node and java I don't think its that difficult compared.
It's just .net foreign to most people, so they don't know the terminology.
.NET core is the new guy in town that is cross platform. ASP.NET Core is the web framework built on top of .NET core.
.NET Core is called a superset of .NET Standard because it implements everything and more.
.NET Framework - older desktop/windows-only that implements the .NET Standard. Various other smaller frameworks created over the years for mobile, embedded, etc.
.NET Core - newest cross-platform framework that implements the .NET Standard, although with less coverage than the full framework because it's new, but .NET Core 2.0 will have much more in parity and will eventually outpace.
ASP.NET - web framework built on top of the .NET Framework that offers webforms, mvc, web api, razor views, etc related to making webapps.
ASP.NET Core - web framework built on top of the .NET Core framework that offers a faster, streamlined pipeline/middleware model with mvc/web api, razor views, SPA services and integration, etc.
Yes Microsoft is one of the worst companies at naming -- however it makes perfect sense that ASP.NET Core (the web framework) targets .NET Core (the underlying cross-platform framework) which itself implements .NET Standard.
It's a case of superset functionality being layered on top. Eventually the .NET Core code will move faster and outpace .NET Framework, so you will be able to run .NET Framework libraries inside .NET Core apps but not run .NET Core apps inside .NET Framework.
I think you're being too generous. Microsoft branded it's Office Suite, BA Suite and Operating system .NET once upon a time. They'd have named their own variety of orange juice OJ.NET if they'd had one.
They are the worse company at naming.
I do think Microsoft could just hire a VP of Naming who's in charge of all names and improve productivity by billions but alas, this is where we are today. However, once the names become familiar, the actual issues are not nearly as dire as made out to be.
Today .NET Core is younger and smaller so it's easy to also run .NET Core apps on .NET Framework since .NET Framework is larger and has everything implemented already - but as we progress with new APIs in .NET Standard, .NET Framework will continue to fall behind (until it gets those major multi-year updates). So you can still use older ASP.NET Core versions (like today's 1.x) on .NET Framework but eventually the newer versions will be too far ahead of the .NET Framework.
However, .NET Core is cross-platform and runs just fine on windows, brings its own dependencies, and will be able to use .NET Framework libraries so this whole issue is overblown. System.Drawing, ActiveDirectory, and other APIs will be added to .NET Core soon enough. If you really need COM interop, then either just stick with .NET Framework apps or use older .NET Core apps.
Note to self: .NET Framework = .NET Desktop.
I don't recall ever seeing the term .NET Desktop used anywhere, I assumed it was some compact version of .NET Framework.
".NET Desktop" can be used instead, although it's also misleading since it has nothing to do with desktops. ".NET Full Framework" is also used often.
Perhaps the best name would be ".NET Legacy Framework" with the understanding that it is a heavy, slow-moving framework implementation that only runs on Windows (and is limited by the Windows version as well).
I give up.
I have better things to do.
Looking over an example doc of how to host .NET in IIS (by far the most common approach) really shows how out of control it has become: https://docs.microsoft.com/en-us/aspnet/core/publishing/iis
It's a mess.
There's nothing stopping you just using self hosted websites.
All those other settings are settings that were there before.
Is IIS just configuring http.sys at this point? Are modules still invoked during the request?
Ah, the old debate in .Net between the lumpers and the splitters.
Between the "just install .Net and that's it, it makes no sense to install all these little interdependent pieces one at a time. it's too complex and versioning is hell" and the "this web server doesn't need the WPF libraries, it's just dead weight, bloat, and makes it harder to start up new machines. It makes no sense to bring out a new version of WPF because there's a bug fix in ASP. Or worse, delay release."
The thing is, there is no one right answer, only opposing forces that have to be reconciled.
.Net core started out fairly radical, which favoured the early adopters and neophiles who tend towards splitters, but is now generally veering towards larger corporate adoption, which tends to wards lumpers. But there are exceptions.
> The thing is, there is no one right answer, only opposing forces that have to be reconciled.
Really? I thought this was a mostly solved problem. I certainly see it as such when I use modern packaging systems that were developed almost two decades ago.
I'm not sure if you have something specific to say about the nuget package management system; how it was used to deliver packages in .Net core and how and why the strategy has changed from delivering the framework as lots of small packages to delivering it as few larger packages; or if you are just being flippant and ignorant.
On the other hand, I've seen both strategies (large and small packages) in use, and the better dependency resolution mechanisms and package building tools, the better small packages work. I don't need to install plethora of GNOME and Python packages, I just run `apt-get install exaile' and have it installed. From programmer's perspective this works equally well; I may want to include some specific part of Boost library, but I can also run `apt-get install liboost-all-dev' and be done, and leave detecting the actual dependencies to package builder's tooling.
Right, so what specifically are you adding to today's discussion? What drew you to it?
First is that MSBuild hard-codes references, so building a multi-targeted project with references to a multi-targeted NuGet package is a nightmare. From what I've read in the documentation, Paket (an alternative package manager) is supposed to be designed to help with this, but it was already enough of a struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual Studio.
Second is the fragmentation of the .NET frameworks, a la this article. Combined with how .NET makes native interop fairly easy (i.e. platform dependent packages), you get either bloated monolith packages or a proliferation of satellite packages.
Other than that, I've had a fairly easy and straightforward time with NuGet. But then again, I've never seen a project with more than a dozen or so dependencies, compared to using Maven in Java where you pull in dependencies like hotcakes.
I'm split. I'd love to see the churn settle down so the surrounding ecosystem can mature. On the other hand, there are definite pain points with the existing tooling. I remember seeing declarative package references as a feature request for Roslyn, which would be absolutely wonderful, but even if it's released fairly soon, it's probably going to take years for adoption to spread.
And I don't see why "proliferation of satellite packages" is supposed to be bad. It works in Debian's APT, including development packages. Maybe somehow NuGet is not okay, after all? Certainly something is different between the two.
This has changed radically with Visual Studio 2017 and the newer MSBuild tooling. See https://github.com/khellang/Scrutor/blob/master/src/Scrutor/... for an example. It has three targets with both conditional and common package references.
There are other cases e.g. using EC2 Vms in AWS where it's moot; machines come and go, there is only ever one app per machine. So installing per machine or per app are both 1 install, except that the per-app install has the potential to be slimmer not 1-size fits all.
In short, it's more friendly to new scenarios involving clouds and containers.
They're better at "download this and everything will work" than any equivalent I've found in the ecosystem for other languages (though elixir/phoenix is there, too). I'm impressed (as a .net newcomer).
With postgres support through npgsql, I'm doing my latest side project in C#. We'll see how it goes.
.NET Core is a new project with a vast amount of reworking and as usual, version 2.0 tends to be the best release to wait for. Considering it's not even out yet, not sure what all the outrage is for.
==
I can see why this is initially a scary WTF moment. Let me explain because it’s less freaky than it seems.
You said .NET customers are going to need to interoperate. Totally agree. We can share netstandard libraries between ASP.NET Core 2.0 and EVERYWHERE. We can even reference many net461+ assemblies from ASP.NET Core 2.0 because of typeforwarding and netstandard20 You said WebApps may need to use: AD – Totally, this is a gap IF you want to call LDAP directly. You can certainly auth against Windows Auth NOW. We plan to have specifically the DirectoryServices namespace for Core 2.0 around summer timeframe Drawing – Totally, this is a gap. We plan to have this for Core 2.0 around summer timeframe. Until this, these netstandard options also exist ImageSharp, ImageResizer, Mono options, etc COM Automation – This has never been possible under Core 2.0, but you can certainly PInvoke if you want to hurt yourself. You could also local WebAPI to a net461+ process if you really want to hurt yourself. Sharing code with WFP Apps – YES. Totally possible with netstandard2.0. This is a weird change to make. Feels like it but… Think about it this way. WPF isn’t netstandard2.0, it knows it’s on net461+ and that’s OK. It’s optimized, but it can reference netstandard libs. ASP.NET Core 2.0 is optimize for Core 2.0 but it can reference shared libraries. Xamarin is the same.
.NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard.
NetCore > Net Standard > NetFx when it comes to development speed and innovation.
Point is, if you are doing new work, netstandard20. If you have older net461+ libraries, MOST of those can be referenced under ASP.NET Core 2.0.
ASP.NET Core 1.1 which runs on .NET Framework will be fully supported for a year after we release 2.0. That workload is fully supported thru at least July of 2018.
The remaining large gaps missing in .NET Core 2 are System.DirectoryServices and System.Drawing. We are working to have a Windows compat pack which would enable both of those on .NET Core on Windows this summer.
What we need from you all is a clear list/understanding of WHY you think you need ASP.NET Core 2.0 to run on net461+. Be specific so we can close those gaps and let everyone be successful.
How does the reassure you? To me that reads:
Boys! We've been caught. Quick, do Jazz hands and pretend it doesn't matter!
That does not seem like a sane response to me. We move fast and break things and that's good is not something we should be hearing as a justification at this point.
And he's making a deal out of it being supported till 2018! A whole year! What do they think people are making on their framework? Apps that disappear after a year? Once you commit to a framework you'll be supporting it for 5 or 6 years.
Am I totally misreading it, as to me that is really not a reassuring response at all, quite the opposite. It seems to me that they've completely lost touch with their customers who want a stable, fast and predictable new version of MVC 4.
We built on top of ASP.NET Core because of the option to use it with netfx, and we built things which were intended to last 5-10 years, not for 1 year of support max. This is what the ASP.NET name means in business and it's why large, slow-moving organisations choose it over flavour of the month frameworks.
They should take a look at MS history and look back at the Windows Mobile (6) -> Windows Phone transition for what can happen worst case when you crap all over your enterprise customers.
But one big difference is: Official support means updates in case of critical vulnerabilities and guarantees that, at least with IE11, it won't simply stop working after an update.
ASP.Net Core 1.x won't have any such guarantees after 2018.
And that's kinda hefty when the ASP.NET Core website (https://docs.microsoft.com/en-us/aspnet/core/) still refers to this page for guidelines as to which .NET Runtime to choose for ASP.Net Core(!) projects:
https://docs.microsoft.com/en-us/dotnet/articles/standard/ch...
Also, if you started using asp.net core 1.0, and you do actually do need stuff that's .net 4+ only, you're stuck.
There are a ton of people/businesses that use old .net libraries, that now have no way forward, no way to gradually introduce asp .net core. I'm going to assume that, if this is a new policy, that all the other new core stuff (entity framework core, async enumerable) might also become core only, which would be an even bigger issue.
Also, I can't think of a good reason this happen. Are they trying to force people to .net core? Was supporting two .net versions that big of a burden?
> ASP.NET Core 1.1 which runs on .NET Framework
I thought it runs on .NET Core?
At least over in JVM land things are somewhat clearer.
It's usually for large projects that these backwards compatibility issues tend to crop up and be show-stoppers. You're likely better off with Mono in that case.
VSCode (with ionide), vim (vim-fsharp binding), emacs (fsharp-mode) already support it, with full intellisene. VSCode also support debugging.
About the aspnet stack, same future limitation of C#, as discussed on the post. But there are also alternative web stack, like Suave.
That isn't the issue, the issue is that when I play with things I restrict myself to playing with things that I can potentially use in production at some point, I don't have a lot of 'play time' so it makes sense to prioritise things that have a potential return.
He's classifying changes in library as either:
- (backwards compatible) growth
- breakage
Hickey's Clojure introduce breaking changes even in minor versions[1] how this is more sensible?.
[0]https://docs.microsoft.com/en-us/dotnet/articles/standard/li... [1]https://github.com/clojure/clojure/blob/master/changes.md
Clojure code written for 1.0 (May 2009) works just fine in Clojure 1.8 and you'd find it challenging to find an item in that linked document that actually breaks compatibility.
EDIT: Replaced .NET Desktop with .NET Framework, which is more accurate.
I just don't see .NET Core having any stability. Meanwhile, node just landed promises in core[0] a few minutes ago.
[1]: https://github.com/aspnet/Home/issues/2022#issuecomment-3000...
Microsoft, although demonstrably more open-source friendly, still moving the cheese.
I love working on both sides, but sometimes we get into these kind of issues.
On Java side I never liked that Sun engineers never grasped the expectations of what being a desktop developer actually means (AWT, Swing, Java 3D, JAI, JDI...). Which is an area, where Oracle actually managed to handle slightly better, but lets see.
The only .NET enterprise pattern I can relate to is MVVM.
When your users are below a certain threshold CQRS/Event Sourcing that pattern would be a extreme overhead.
(And I'm not sure if .NET made them popular, the only thing I know is that microsoft actually has very good documentation about them and martin fowler actually made good block posts about it in early as of 2005 or so, but the first time I heard of it was probably in Object-Oriented Software Construction (Java Book))
I wish they would make a chart, diagram...call it what you may, on MSDN or the Github repo, indicating all the frameworks, a description and what developers should target when using one e.g. Desktop, Web or API, Mobile, Cloud etc.
That way, when comes the time to develop an app, we reference the chart and go from there.
Nothing that would stop me from using .net.
Microsoft is really good to keep developers dangling. Can / should I still use WPF? Did it secretly continue under a different name?
«Can / should I still use WPF? Did it secretly continue under a different name?»
You can still use WPF if you are happy with it. The Universal Windows Platform (UWP)'s .NET/XAML stack is the relatively open and acknowledged successor to WPF. It should be quite familiar to existing WPF developers and offers some nice new features and performance. Porting to UWP is still sometimes tough from WPF, but Project Centennial/the Desktop Bridge can make it a lot easier to do the transition a piece at a time.
Bloaty McBloatface - .NET Standard
Fleabiscuit - .NET Core
First, this is about a preview version only.
Second: Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. This version will be supported by desktop .Net 4.7 (win7+) when the standard is RTM. This will be the point where depending technologies will be RTMd as well. We should revisit this discussion then.
Read the issue carefully, they've done the exact opposite and have started changing ASP.NET Core 2.0 packages from targeting .NET Standard to now only target .NET Core netcoreapp2.0 so they will no longer be able to be referenced from the full .NET Framework.
They've also just announced that ASP.NET Core 1.x will be the last version that will be able to run on the Desktop CLR:
[1]: https://github.com/aspnet/Home/issues/2022#issuecomment-3000...
I also agree with the opinion that ASP .NET Core shouldn't have run on the full framework to begin with to set the right expectations. We seem to be in yet a transitionary period by Microsoft and if the point is to decouple it from .NET Framework, it shouldn't have had legs in it.
WPF will probably never work on .NET Core, so after that they're going to have to have some kind of elaborate multiprocess solution if they want to stay in supported versions.