aspnetcore 🚀 - The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop

This would be an extremely weird and bad change to make. I have written a lot of netfx-only asp.net core code and do not want to see that investment wasted. More generally, .NET customers are going to need to be able to interoperable between ASP.NET Core and Desktop code for the foreseeable future - imagine webapps which use Active Directory, or Office COM automation, or which do thumbnailing using some System.Drawing based library, or share code with a WPF app. It's trivial to think of a lot of scenarios like this and I hope we've simply misunderstood what's going on.

gulbanana on 5 May 2017

👍5

We're currently on AspNetCore 1.1.1 - i.e, the "current" support branch. If we cannot move to 2.0 due to dependencies on Net4XX, does that mean we'll be unsupported when 2.0+3months drops?

ctolkien on 5 May 2017

👍9

We use a combination of WPF and ASP.NET Core and target in both cases the full framework.
So I guess no 2.0 in the foreseeable future?

MJomaa on 5 May 2017

But full framework 4.6.1 will support netstandard 2? am I missing something? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

isn't this that the current tooling isn't updated?

aL3891 on 5 May 2017

it would be totally fine and expected to see asp.net core running on netstandard 2. the alarming thing is this prospect of moving to netcoreapp2.0, which would imply no longer being able to use legacy code inside of asp.net core websites

gulbanana on 5 May 2017

👍15

oh, that's an issue.. I suppose though that its mitigated a little by the compat shims in netcore2 that allows you to reference old assemblies, but still, it means porting all projects to the new project system and a lot of other work..

Would be nice to hear the teams reasoning on this

aL3891 on 5 May 2017

oh, so you think that netcoreapp2.0 projects will simply be able to reference netfx libs thanks to type unification? that would explain a lot. my question, if so, is how much code will actually work when run on windows but on the core CLR..

gulbanana on 5 May 2017

Wow. This would be totally blocking for us and basically make sure we could never update these packages for the far foreseeable future. We even might need to migrate our MvcCore project back to Mvc, because we currently cannot get around targetting net462+.

nphmuller on 5 May 2017

👍3

I'm extremely curious about this as well. I'm really hoping this in an intermediate (and short lived) step or a big miscommunication. It would certainly be a blocker to adoption for most of our applications as well.

Moving everything to Core is just too much for a large existing codebase (without stopping dev to do it), moving to the new ASP.NET Classes (HttpRequest, controllers, etc.) as an intermediate step has to happen for our main projects.

Perhaps @DamianEdwards or @davidfowl can comment on plans here? I'm also having trouble finding any additional reasoning.

NickCraver on 5 May 2017

👍5

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.

shanselman on 5 May 2017

👍110 😕35 👎8 ❤5

I thought .NET Standard 2.0 was all about compatibility and interoperability which bridges the gap between .NET Core and .NET fx that everyone is waiting for - this seems to kill that.

For whatever reason there's going to be lots of customers who will have dependencies that require .NET 4.x whether it be custom external dependencies, commercial components, legacy lib dependencies, etc.

Is it the intention that Customers wont be able to create ASP.NET Core 2.0 apps running on Desktop CLR so they can reference their existing .NET 4.x deps?

mythz on 5 May 2017

👍29

@shanselman Thanks for the reply - lots of good examples in there.

A follow-up about libraries:
Will all of the abstraction libs remain as cross-compiled? For example if I'm using HttpRequest, maintaining a 1.x and 2.x builds on which version of ASP.NET Core you're using (which now cleanly map to a TFM at least) would be something I'd prefer to avoid...so I'm hoping the abstractions will remain on netstandard. Is that the general plan?

We're already maintaining multiple variants for things that depend on ASP.NET/MVC because System.Web's HttpRequest is totally different, so that's another library entirely (e.g. MiniProfiler vs. MiniProfiler.AspNetCore). I just want to make sure we're keeping in mind the number of variants we're loading up on maintaining for any lib authors if their dependencies move off netstandard...and hopefully just avoid that headache all together.

NickCraver on 5 May 2017

👍5

I'm very happy this doesn't seem like as big a deal as it appears, thank you for the detailed clarification.

I do have two questions/concerns:

It sounds like consuming .NET Framework libraries from ASP.NET Core should have minimal friction. That's great! What about the other way around? There are probably .NET Framework or netstandard libraries and applications out there that are embedding parts or components from Mvc and other supporting ASP.NET Core libraries (I know because I have a couple). Those will break, correct? Are there any tips for how to work around that scenario? If netstandard libraries can no longer consume ASP.NET Core libraries, that seems like a big deal for embedded ASP.NET Core scenarios.
From a non-technical perspective it seems like this will cause a lot of confusion. Outside of the folks who are active on GitHub, follow along on Twitter, etc. there's already a great deal of confusion surrounding the different platforms, etc. I can see developers who've only been partly following along or who are just now getting up to speed getting very frustrated when they go to use ASP.NET Core (perhaps following an outdated tutorial) and can't get it to work on their .NET Framework platforms. Not sure what, if anything, can be done about that.

daveaglick on 5 May 2017

👍10 🎉1 👎1

We can even reference many net461+ assemblies from ASP.NET Core 2.0 because of typeforwarding and netstandard20

Unfortunately, this doesn't mean that a library compiled and designed for the full framework will work on .NET Core (the risk is high things will blow up at runtime!).

Many of the "old" APIs re-introduced in .NET Core 2.0 are stubs that will never (functionally) work. Not to mention that there are still many missing APIs, and even entire areas that were deliberately excluded from .NET Core (IdentityModel, WCF server, remoting, complete AppDomain support, etc.)

Trying to convince people that they can "safely" migrate their ASP.NET Core 1.0 w/ .NET Desktop apps to ASP.NET Core 2.0 w/ .NET Core is - IMHO - a lie.

.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.

I don't believe that's what (most) people are looking for. Many people don't need fast-moving libraries, they need stable stuff that can gracefully integrate into their older stuff without taking the risk of breaking everything.

kevinchalet on 5 May 2017

👍62

@daveaglick

Correct in that there's no implicit ability to reference netcoreapp2.0 from net461 or even netstandard2.0. The bridge goes one way. You can always work around it by specifying TFMs for package fallback, but that's obviously an escape hatch, not a supported scenario (although it will be enough to unblock many people). It's a non-trivial amount of work for us to support sub-systems of ASP.NET Core outside of the larger stack (which is what targeting netstandard is implying).
The potential for confusion goes both ways. E.g. we've had lots of feedback that the fact that "ASP.NET Core" can run on .NET Framework (which isn't .NET Core) is confusing. This change effectively makes ASP.NET Core part of the .NET Core stack meaning if you're using ASP.NET Core, you're using .NET Core.

DamianEdwards on 5 May 2017

😕9 👍8

@shanselman BTW, you didn't say why cross compilation was not an option. ASP.NET Core components that could benefit from netcoreapp2.0-only APIs could have both net46/netstandard1.x/netstandard2.0 and netcoreapp2.0 TFMs and make the new cool/fast stuff .NET Core-only.

kevinchalet on 5 May 2017

👍1

@NickCraver currently the plan does not include leaving the *.Abstractions packages targeting netstandard. The separation simply isn't as clean as that across the board. For the purposes of someone attempting a migration like what you're suggesting however, using package target fallback should get you there anyway (but I might be misunderstanding you).

Also you're point about the clean TFM split is correct, and is an advantage of this plan, in that a single package can now target ASP.NET Core 1.x and 2.0+ simultaneously using the TFM as a pivot.

DamianEdwards on 5 May 2017

👍2 👎1

I've toying around with the idea of "mixed applications". E.g. a WPF application exposing a Web API or a Server offering both a REST API and WCF endpoints (this might be for compatibility with earlier clients). These scenarios are made impossible with this change and makes ASP.NET Core only suitable for new applications rather than being "just a library".

ap0llo on 5 May 2017

👍2

@PinpointTownes as @shanselman stated, we're very interested in the specific requirements and blockers that customers have with regards to needing to continue to target .NET Framework directly. Our work with customers in this boat so far has indicated that System.DirectoryServices and System.Drawing and the No.1 and 2 blocker and we have a plan to address that. Beyond that, we're looking at the feedback and we'll assess.

Cross-compiling is an overhead that must be balanced with customer and product needs. This is why we want to get this feedback so we can more concretely define what the landscape looks like for both our customers and us as we continue to evolve ASP.NET Core moving forward.

DamianEdwards on 5 May 2017

@DamianEdwards Thanks for the further clarification. The netstandard -> ASP.NET Core libraries are kind of a big deal for me. I embed Kestrel (which also looks to be moving to netcoreapp) in several netstandard libraries. I also embed Razor in several places, and I know you're working on the new more modular version, but if that only targets netcoreapp too it'll hurt. There's also tons of libraries that are "part" of ASP.NET Core but that have lots of utility outside of it.

In other words, I'm much more concerned about removing the ability for netstandard libraries to consume ASP.NET Core packages than I am about the reverse. It seems like this is removing an entire class of use cases from consideration.

daveaglick on 5 May 2017

👍19

@daveaglick Razor itself (the engine) will continue to target netstandard. Again, there's a cost involved in supporting particular sub-systems of a large complex graph (like ASP.NET Core 2.0) on different platforms. For things like embedding there are other options (source embedding, copying, etc.) but of course they come with their own trade-offs.

Definitely hear you on the different classes of use cases front, we indeed have different customer groups to consider when designing and shipping a stack like ours.

DamianEdwards on 5 May 2017

I share @daveaglick's concerns here: ASP.NET Core wanting to use the latest APIs is totally understandable, but for everything else downstream to require the same gets a little messier. You don't get any choice after 1.0 of stable or upgrading, you're on the fastest train available with netcoreapp2.0 and that's the only choice. If all of the bits (even the basic abstractions) can't be consumed without making users consume netcoreapp2.0, that means there is effectively no netstandard2.0 for that entire line of libraries...and everyone that depends on them.

I get the core application stack moving, but I don't necessarily agree with the abstractions in particular moving. One of the major points of the abstractions was to avoid the tight coupling like this, at least from my view as a consumer. I'd be very curious to see some examples where netstandard2.0 doesn't have the APIs needed for them but netcoreapp2.0 does - are there some examples out there? Is this mainly around new types in method parameters? I don't doubt there's ample reasoning, I'm just very curious - seeing examples would help show the maintenance cost which we don't have nearly as much daily insight to.

The Kestrel case is more complicated, but I certainly see the arguments for having it on the latest API set. I'd imagine new APIs will continually be created for Kestrel given the work it's driving.

NickCraver on 5 May 2017

👍25

@PinpointTownes as @shanselman stated, we're very interested in the specific requirements and blockers that customers have with regards to needing to continue to target .NET Framework directly.

As a consultant, I helped a bunch of clients move their apps to ASP.NET Core and I often had to target .NET Desktop to be able to use third-party (closed-source) libraries depending on IdentityModel/WCF or relying on AppDomain support.

Not having these things in ASP.NET Core 2.0 would be a major blocker for them.

There are also libraries that wouldn't work on .NET Core even if the APIs were there, because they'd be functionally different. Here's a concrete case I've seen many times:

On .NET Core, RSA.Create() returns a RSACng instance on Windows, but on .NET Desktop, a RSACryptoServiceProvider instance is returned. Yet, many libraries - including the BLC itself - try to cast RSA to RSACryptoServiceProvider, which will always fail on .NET Core, as RSACng can't be cast to RSACryptoServiceProvider.

kevinchalet on 5 May 2017

👍17

@NickCraver which abstractions in particular? The problem with moving just the abstractions is that next you'll end up wanting everything that builds upon those abstractions as well (unless you're literally saying that you only need Microsoft.AspNetCore.Http.Abstractions and nothing else)

davidfowl on 5 May 2017

@davidfowl Yep, only the abstractions: e.g. HTTP, Hosting, HTML, and Logging. It looks like Microsoft.Extensions.* are covered by earlier comments, which is most of these. Those are the ones I'm interfacing with today.

For a concrete example: the MiniProfiler Middleware doesn't reply on anything but abstractions (link)

If you're using MVC and such on top, well then you're on netcoreapp2.0 anyway, and that is what it is (and IMO, that's just fine). But currently I have freedom to split up APIs logically where shared and do so easily because they're abstractions. I'm very much a fan of the current split, please don't lock that down unnecessarily.

NickCraver on 5 May 2017

👍7

Heh. As a consultant, I've definitely heard the "What? ASP.NET Core runs on desktop .NET Framework!?" question quite a few times. The fact that "ASP.NET Core" literally has ".NET Core" in the name is really unfortunate.

Anyway... Just as I was a fan of dropping obsolete/legacy/broken APIs when .NET Core started out (a "fresh" start), I'm also a fan of this change in order to get a faster, leaner framework with more features and a higher rate of innovation.

With that said, I'm also sympathetic to all the devs out there that can't, for some reason, migrate all their code to .NET Core before June next year.

This includes my current client, which has an insanely big legacy library/framework, targeting .NET Framework, consumed by multiple ASP.NET Core projects currently being developed in parallel. By the time these systems goes into production, there will be little to no time to either a) port everything to .NET Core, or b) move everything to full framework ASP.NET, before ASP.NET Core 1.x is unsupported.

Is one year of support really enough here? I can imagine there are other similar cases out there...

khellang on 5 May 2017

👍11

@khellang as previously stated, they'll be able to continue referencing libraries/frameworks targeting .NET Framework, and that will work just fine assuming the APIs they call are part of the closure of netstandard2.0. Do you know if they rely on things outside of that space? That's what we'd really love to get feedback on so we can assess the priority of porting those APIs (like System.DirectoryServices and System.Drawing).

DamianEdwards on 5 May 2017

So hosting a web api (say communication layer) or even upcoming asp.net core sockets is going to become impossible for a current windows service or WPF desktop app? (with supported versions).

dasMulli on 5 May 2017

👍5

I imagine there will be a list forthcoming of things that used to be netstandard1.x that are now netcoreapp2.0

I've browsed the repos and it seems MVC specific things are netcoreapp2.0 but HttpAbstractions, Logging, Configuration, etc are still netstandard Or is there more change to come?

adamhathcock on 5 May 2017

@NickCraver I see you're using Extensions but are still using System.Web. Do you have plans to shim Microsoft.AspNetCore.Http.HttpContext with System.Web.HttpContext? Do you have an idea how much of the API you need?

If you're using MVC and such on top, well then you're on netcoreapp2.0 anyway, and that is what it is (and IMO, that's just fine). But currently I have freedom to split up APIs logically where shared and do so easily because they're abstractions. I'm very much a fan of the current split, please don't lock that down unnecessarily.

I'm not talking about MVC though, I'm just talking about other helpers that expose more functionality on top of the underlying abstractions. The big value of the "abstractions" pattern we chose is that other things can build on top of them, not so much the abstractions itself. My gut tells me that if we make the ASP.NET abstractions netstandard then we'll end up having to make all of the middleware netstandard as well.

@dasMulli windows services will work once we have the API ported over (there are also open source libraries that support windows services on .NET Core).

WPF desktop app? (with supported versions).

Yes. This won't be the default anymore. We won't support it out of the box anymore with .NET Core 2.0.

davidfowl on 5 May 2017

👍1

@davidfowl I'm not sure you looked at the right pieces there:

but are still using System.Web

...not in the same libraries, because of this split. To achieve minimal overhead and not a truckload of dependencies for consumers, there's MiniProfiler for ASP.NET MVC < 6 (System.Web) and MiniProfiler.AspNetCore/MiniProfiler.AspNetCore.Mvc (lots of NuGet).

I think you're talking about System.Web vestige that was that was on MiniProfiler.Shared - I was waiting to clean those up until the NuGet issue fixed just last night on framework assemblies. I just removed it to clear things up.

NickCraver on 5 May 2017

@DamianEdwards I'm not 100% on the closure of netstandard2.0, but I would be happy to (with their permission) do a portability analyzer run and share the results. Is portability analyzer still a thing and up to date?

khellang on 5 May 2017

👍1

ASP.Net Core is quickly becoming the new Python 3*; only worse. This seems like a move in the wrong direction to me. This just means a ton of scenarios will force developers to maintain (and write new) code on the "old platforms" for many years to come instead of moving. "Faster development" doesn't seem like a very good argument if all it means is you get to a worse/unsuitable place "Faster".

*I like Python 3, but it's been out almost a decade and the Python community is still fractured

jhurdlow on 5 May 2017

👍27 👎6

Just to be clear - is there any technical blocker (fancy perf stuff) or is this just to save the cost of maintaining compatibility in the future?
I think most of us knew this move would come but no one expected it so soon.. given the transition time is still going on (like libs being ported, .net standard 2.0 around the corner but no libs are yet bing built for it) - it would be great to keep net* support for at least one release (e.g. 2.0, not 2.1).

dasMulli on 5 May 2017

@shanselman I see your points and i personally even agree, but _alot_ of people are not going to see it that way.

The primary issue is not calling net46 assemblies from core, the compat shims deals with that in most cases. The problem is existing net46 code and asp.net core 1.* code running on 46. As someone mentioned, the whole point of netstandard was to allow code, including asp.net, to run everywhere, this is going to feel like a step away from that and perhaps even a failure of that vision to some people.

I don't think the problem is that people don't _want_ to move to net core. The problem is that organizations, managers, CTOs and the like has to be convinced that the cost/benefit of doing so is worth it. Not only is porting time consuming enough to eat into deliveries, it also introduces risks of regressions etc.

in other words, its not always technical reasons that prevent people from moving. I'd even say its rare, _technically_ almost any project can make the jump. But motivating that cost/delivery slip, that's the problem. It can be a very hard sell, one that i've had to make a fair few times. In those cases being able to say, "but you can run on full framework" has been a way to drive that move though

If you want to hurt yourself

This is exactly it. Net46 devs and management will not see it like that, they'll see it as _you_, microsoft, want to hurt them in order to keep up with the latest release. "Well don't move then" one might say but with the support of asp.net core 1.x as short as it is, they kind of have to, at least from the perspective of managers who has to be held responsible if a bug causes downtime or information loss. (even if the framework is not responsible)

A lot of devs that really pushed for asp.net core 1.1 are also going to feel betrayed that they now wont be able to move to 2.0 without core. That may or may not be justified but i'm just telling you, alot of people are going to feel that way, they'll be the ones who have to answer to their more conservative colleagues

Does any of that matter? Will asp.net core2/dotnet core2 "die" because of this? No, but it will slow adoption and fracture the ecosystem and that's really sad imo. I want people to be able to use all this great stuff coming in 2.0 and cutting cross compilation to net standard will impact that. Certainly, most people who hang out in these repos wont have a problem, its Joe and Jane dev and even more so, their manager that's the problem.

@DamianEdwards
I agree that this has been a source of confusion, I've had to explain it many times, but the result of that has always been turning a disappointed dev into an excited one because they thought they were not able to use the new cool stuff but it turned out they could.

To summerize, I'm sure this decision was not made lightly but if you have to do this i think you have to be really _really_ careful about the messaging.. You have to show that migrating to asp.net core, especially from 1.x on net46 is _super_ simple and super polished. The story for referencing other netstandard libraries from net46 both as project references and otherwise has to be rock solid. I think you need to show/adress this explicitly to avoid people freaking out

aL3891 on 5 May 2017

👍56 ❤14

@khellang paging @terrajobst for the Portability Analyzer question.

DamianEdwards on 5 May 2017

@khellang

Yes, we just updated the VSIX for 2017, but I simply use the command line version from here.

terrajobst on 5 May 2017

@NickCraver Sure, you can write a piece of middleware that targets netstandard, what good does that do for you as a library author if ASP.NET Core supports netcoreapp2.0.

@aL3891 great summary! One big issue we do have going forward is how we take advantage of new APIs for things that are also in netstandard. .NET Core will get new APIs that we need to implement new features (one that comes to mind is SSLStream ALPN support for HTTP2 support in Kestrel). So you could argue we stay on stay on netstandard and constantly use the highest version (which .NET Framework doesn't support yet) but then we'd be in the same boat.

davidfowl on 5 May 2017

One big issue we do have going forward is how we take advantage of new APIs for things that are also in netstandard. .NET Core will get new APIs that we need to implement new features (one that comes to mind is SSLStream ALPN support for HTTP2 support in Kestrel).

According to https://github.com/dotnet/corefx/issues/4721, ALPN support for SslStream won't be ready for .NET Core 2.0. Assuming this is eventually implemented a few months later, does that mean that one will be able to use it when targeting the netcoreapp2.0 TFM? In this case, what will happen if I decide to release a netcoreapp2.0-based library that uses new APIs that were not part of the initial netcoreapp2.0 shape if my users use an older .NET Core runtime? Will it crash? Or will netcoreapp2.x be aligned with netstandard1.x, whose contract can't be changed without incrementing the TFM version?

kevinchalet on 6 May 2017

@davidfowl for other implementations of any piece of the stack and testing. And because with the way abstractions are (not requiring MVC) as a decent split between 2 libraries instead of "assume everyone has MVC and wants all dependencies".

If the abstractions aren't actually abstractions and are so tightly coupled to ASP.NET Core itself, why don't we just remove those packages? It's an honest question, as that'd make life easier and clearer if that's the overall relation goal. I'm trying to understand the point of having abstractions as separate packages are if they're effectively tied to a simple implementation/use. I'd posit that no one outside of Microsoft wants to or has the resources to dedicate to a competing netcoreapp2.x web server (happy to be corrected there!).

Can you clarify what the point of the abstractions would be in a netcoreapp2.x world? Or if there are plans to simply deprecate them in 2.0?

NickCraver on 6 May 2017

👍1

According to dotnet/corefx#4721, ALPN support for SslStream won't be ready for .NET Core 2.0. Assuming this is eventually implemented a few months later, does that mean that one will be able to use it when targeting the netcoreapp2.0 TFM? In this case, what will happen if I decide to release a netcoreapp2.0-based library that uses new APIs that were not part of the initial netcoreapp2.0 shape if my users use an older .NET Core runtime? Will it crash? Or will netcoreapp2.x be aligned with netstandard1.x, whose contract can't be changed without incrementing the TFM version?

ASP.NET version x will just align to .NET Core version x. The TFM will be updated to align with every release of .NET Core. It's a single product that can finally be treated as such. That's one of the major simplifications we're doing as @DamianEdwards mentions above. We won't break people building libraries by adding new APIs in the core without changing the TFM.

@NickCraver

for other implementations of any piece of the stack and testing.

What other implementations? Are there other pieces of the stack that implement ASP.NET Core.

If the abstractions aren't actually abstractions and are so tightly coupled to ASP.NET Core itself, why don't we just remove those packages? It's an honest question, as that'd make life easier and clearer if that's the overall relation goal. I'm trying to understand the point of having abstractions as separate packages are if they're effectively tied to a simple implementation/use. I'd posit that no one outside of Microsoft wants to or has the resources to dedicate to a competing netcoreapp2.x web server (happy to be corrected there!).

Can you clarify what the point of the abstractions would be in a netcoreapp2.x world? Or if there are plans to simply deprecate them in 2.0?

We could put everything into a single assembly but the refactoring allows us future flexibility that we wouldn't otherwise have if we did this. It even opens up the possibility to have other implementations and doesn't really preclude it in the long term.

Simply put, abstractions are about lowering the number of dependencies, not about platform portability.

davidfowl on 6 May 2017

We won't break people building libraries by adding new APIs in the core without changing the TFM.

You guys said that you wanted to opt for netcoreapp2.0-only as it was moving faster - compared to .NET Desktop and by extension, .NET Standard - but what's the point of targeting netcoreapp2.0 instead of netstandard2.0 if you can't benefit from new .NET Core APIs without changing the TFM? (e.g netcoreapp2.1)

kevinchalet on 6 May 2017

You guys said that you wanted to opt for netcoreapp2.0-only as it was moving faster - compared to .NET Desktop and by extension, .NET Standard - but what's the point of targeting netcoreapp2.0 instead of netstandard2.0 if you can't benefit from new .NET Core APIs without changing the TFM? (e.g netcoreapp2.1)

Sorry, I misspoke, I mean netcoreapp2.x not netcoreapp2.0.

davidfowl on 6 May 2017

Okay, I'm totally confused, now.

Sorry, I misspoke, I mean netcoreapp2.x not netcoreapp2.0.

I'm not sure I understand. Do you mean there'll be an equivalence between the ASP.NET Core 2.1 packages and the netcoreapp2.1 TFM?

kevinchalet on 6 May 2017

👍2

Do you mean there'll be an equivalence between the ASP.NET Core 2.1 packages and the netcoreapp2.1 TFM?

Yep. Think of the 2 as one in the same. See https://github.com/aspnet/Home/issues/2022#issuecomment-299544884

davidfowl on 6 May 2017

So what prevents you from adopting a similar pattern, but with netstandard? It would be the best approach, IMHO: new APIs could be adopted via new TFMs and people who need to support .NET Desktop could still run their ASP.NET Core apps on the full framework.

ASP.NET Core 2.1/.NET Core 2.1/.NET Desktop 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET Desktop 4.8 -> netstandard2.2.

kevinchalet on 6 May 2017

👍3

@PinpointTownes because .NET Framework on desktop can't ship fast enough, that's the crux of most versioning issues with Core. It's a hard problem in an immense chain.

NickCraver on 6 May 2017

👍3

.NET Standard will not move at the same speed as .NET Core. Nowhere near it in actuality. A move in .NET Standard essentially leaves all platforms behind, until they catch up, and .NET Framework is both the slowest moving and the largest.

DamianEdwards on 6 May 2017

Point token, tho' I'm not sure how fast .NET Framework is supposed to ship (e.g the new ECDSA APIs were ported from CoreFX to NetFX in less than a year, which seems to be a reasonable time frame for such sensitive crypto components).

Cross-compiling is an overhead that must be balanced with customer and product needs.

When you have a minute, I'd love to know more about the exact nature of the overhead caused by cross-compilation. Thanks.

kevinchalet on 6 May 2017

👍1

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.

At the moment, we need the fullframework version of WCF client libraries - as the netstandard / netcore versions (https://github.com/dotnet/wcf) are not close to complete.

ctolkien on 6 May 2017

When you have a minute, I'd love to know more about the exact nature of the overhead caused by cross-compilation. Thanks.

There will be a time in the very near future where we literally can't polyfill features like ALPN support for SSLStream. Also we haven't even begun to stretch our legs and add APIs into .NET Core, so far we've been bogged down with porting things back to .NET Standard and .NET Core 2.0 (the entire purpose of .NET Standard 2.0). We're going to be adding new APIs and finally consuming them in ASP.NET Core on day 1.

At the moment, we need the fullframework version of WCF client libraries - as the netstandard / netcore versions (https://github.com/dotnet/wcf) are not close to complete.

@ctolkien That is a problem and it's the reason we ported the WCF client in the first place. Do you know what's blocking you? This is a good chance to help us prioritize.

davidfowl on 6 May 2017

@davidfowl https://github.com/dotnet/wcf/issues/8

There may be more, this was just the first hurdle we hit before transitioning to full framework wcf.

ctolkien on 6 May 2017

There will be a time in the very near future where we literally can't polyfill features like ALPN support for SSLStream.

How is that a problem? AFAICT, no here has ever said that the .NET Desktop and .NET Core flavors of ASP.NET Core had to support the same exact feature set. If a feature is not available on .NET Desktop due to missing APIs (e.g HTTP 2/0), why not making it .NET Core-only and throwing a PlatformNotSupportedException telling the developer that the feature he's looking for is not available?
It would be far better than making all the ASP.NET Core packages .NET Core-only, even though most of them will be unlikely to use new BCL APIs.

kevinchalet on 6 May 2017

👎4 👍2

@davidfowl I guess one major fear is that things don't get fixed in say netcoreapp2.3, it gets fixed in netcoreapp2.4. If ASP.NET Core is focused on the fastest train, how long with each minor version get love? If we have to constantly upgrade, then every consumer has to constantly upgrade.

That's great for getting the latest and greatest, but it's not the best for most companies. So we either have to maintain many versions (each minor version) with our libraries for each consumer of ASP.NET Core (to not depend on the latest and keep up), or drag users to the latest version to keep up. This isn't friendly to things like validated environment.

Unless the abstractions need to rev as fast (examples?), having them disconnected would be preferred. That way you're not dragging the entire ecosystem along with every upgrade. I guess I'm more concerned not that they'll be on netcoreapp, but that they'll be continually updated and everything is tightly coupled.

If the abstractions will maintain each minor version and shift the pain (to be frank) to your side, I'm a lot less worried. Can you guys elaborate on intentions with revisions here?

NickCraver on 6 May 2017

👍5

@PinpointTownes:

why not making it .NET Core-only and throwing a PlatformNotSupportedException telling the developer that the feature he's looking for is not available?
It would be far better than making all the ASP.NET Core packages .NET Core-only, even though most of them will be unlikely to use new BCL APIs.

Noooooooo, please no. That's a runtime failure and very much not desirable behavior. We want to have as many compile-time assurances that our libraries will work as possible. There have been many debates on this, that simply isn't a good path. PlatformNotSupported should be avoided as much as humanly possible.

NickCraver on 6 May 2017

👍46

That's a runtime failure and very much not desirable behavior.

This is exactly what will happen with the "bring your .NET Desktop assemblies on .NET Core" approach if your assemblies try to use an unsupported API, except you'll get a MissingMemberException instead of a PlatformNotSupportedException.

With my approach, you could at least define a better tooling story with things like Roslyn analyzers that could determine at compile-time whether the APIs you're using are supported or not.

kevinchalet on 6 May 2017

👍8

And BTW, throwing a PlatformNotSupported would be really a corner case. With cross compilation, the best option would be to simply exclude the unsupported APIs from the public contract.

kevinchalet on 6 May 2017

@PinpointTownes I thought this way as well, but the reality is new platforms ship and it's just not that simple. After discussing this many times my mind has changed greatly on how to do compat here. Going with the netcoreapp direction allows fixes to be shipped in minor versions. Going the other way means you have to wait on .NET Desktop to ship fixes, which...good luck. That's a very slow vehicle for resolutions.

AFAICT, no here has ever said that the .NET Desktop and .NET Core flavors of ASP.NET Core had to support the same exact feature set. If a feature is not available on .NET Desktop due to missing APIs (e.g HTTP 2/0), why not making it .NET Core-only

The first half of that is what netstandard is. Differentiating to netcoreapp is exactly what they're doing here. Without the intentional exceptions. It's a proper contract this route.

You want to go the direction of the thing that can be fixed and improved faster when gaps are involved, not the other way around. "PlatformNotSupported" exceptions can be fixed in the library tomorrow, instead of waiting for the platform to rev 3 months from now. .NET Core can support them faster because the actual code ships with it, not separately as forwarders most of the time.

NickCraver on 6 May 2017

👍2

[@PinpointTownes] If a feature is not available on .NET Desktop due to missing APIs (e.g HTTP 2/0), why not making it .NET Core-only and throwing a PlatformNotSupportedException telling the developer that the feature he's looking for is not available?

We need to balance simplicity in API surface & reach with developer productivity. So far, we've primarily used PlatformNotSupportedException in order to deliver an API surface that is compatible with the past. We don't intend to use PlatformNotSupportedException as a way to deliver disjoint feature sets moving forward. Instead, we'll either drop support for versions of the .NET platforms that don't have the features or deliver the feature as an independent NuGet package that itself isn't supported everywhere.

terrajobst on 6 May 2017

Going with the netcoreapp direction allows fixes to be shipped in minor versions.

How is that different to the 1.0 approach? @davidfowl said new APIs would require new TFMs, which means you'll have to opt out of LTS to get fixes relying on new .NET Core APIs. Not really an ideal situation.

Differentiating to netcoreapp is exactly what they're doing here.

Differentiating is totally fine and I definitely agree .NET Core should be the preferred target for ASP.NET Core. But that doesn't imply ditching .NET Desktop completely, specially when alternatives like cross compilation exist.

We need to balance simplicity in API surface & reach with developer productivity.

Sure. But you also need to balance that with the fact legacy libs - developed for .NET Desktop and using features not available on .NET Core - should work fine in the ASP.NET Core 2.0, just like they did in 1.0.

kevinchalet on 6 May 2017

Instead, we'll either drop support for versions of the .NET platforms that don't have the features or deliver the feature as an independent NuGet package that itself isn't supported everywhere.

That's totally fine in theory. But thing is the platform that's currently lacking important features is .NET Core, not .NET Desktop. This will probably change in a few years, but what's sure is that people will still find missing features in .NET Core 2.0.

kevinchalet on 6 May 2017

👍3

Might be worth having a forward-port repo in dotnet where people can make api requests for specific items they consider missing from .NET Core from .NET Framework?

Then feedback, reviews and guidance can be done outside of the day to day noise of the code repos? Or a general api review/spec repo (Sort of like csharplang vs roslyn)

Also will be a good go to for: "I have conversion issue and need to search for issue related to X api" Whereas corefx is very noisy for that.

benaadams on 6 May 2017

👍7

[@benaadams] Might be worth having a forward-port repo in dotnet where people can make api requests for specific items they consider missing from .NET Core from .NET Framework?

I'd say these are simply issues in CoreFx. Also, our promise generally is: if the type is shared between .NET Framework and .NET Core, we intend to port newly added members to .NET Framework. In very rare cases this might not be possible, but the stake in the ground is that they are automatically considered.

[@benaadams] Or a general api review/spec repo

Not sure it's worth it. API reviews are already somewhat heavy handed; extracting them to another repo seems to amplify that. I'd rather we keep streamlining CoreFx so that adding new APIs is as simple as doing it in, say, ASP.NET.

terrajobst on 6 May 2017

as previously stated, they'll be able to continue referencing libraries/frameworks targeting .NET Framework, and that will work just fine assuming the APIs they call are part of the closure of netstandard2.0

@DamianEdwards What about the APIs not in the closure of netstandard2.0? Most 3rd party libraries are closed source. How am I able to tell that every edge case is in the closure of netstandard2.0?
As @PinpointTownes hinted, this is a kinda like playing Russian Roulette.

MJomaa on 6 May 2017

👍4

@MJomaa tooling will help here but obviously the only way to know for certain is the actually run it. That's actually no different from a .NET Standard library running on a .NET Standard supported framework. API's existing don't replace the need to test these libraries. That's not to say that netstandard implementations don't aim to be compatible, but they are edges, e.g. https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt

Those are APIs that exist in NS 2.0 but not in .NET Framework 4.6.1.

davidfowl on 6 May 2017

👍1

I got really nervous about this change, but after reading the thread it seems fine in theory. We have 5 ASP.NET Core apps with 4 of them on full framework, but that was mostly just us being defensive than anything else and taking the path of least resistance.

I think some sort of tooling baked into VS like the .NET Core Portability Analyzer could help the devs who aren't up to date on Twitter/GitHub and aren't aware that this extension even exists. The "suggest an extension" pop up comes to mind, but I'm not sure what action a person would be taking to trigger that. Trying to add a net46x lib to an ASP.NET Core 2+ app maybe?

Stuff Microsoft can't control like 3rd party support with Telerik, Syncfusion, etc. will be a potential blocker too depending on what they're doing.

The messaging in this GitHub thread needs to get out into a blog post ASAP with an FAQ or something. I feel like I've been staying on top of everything, and I still wasn't 100% sure if this meant we could reference net46x libs or not. I clearly wasn't the only one confused by that either.

To echo what others have been saying. I have talked with at least 10 devs who didn't know ASP.NET Core could run on full framework. I had the same experience as @aL3891 though where devs were really happy they could run ASP.NET Core on full framework and their internal libs would just work. Again - the messaging about .NET Core 2.0 having a vast majority of use cases will be very, very important. The piece about having at least a Windows-only solution for like System.DirectoryServices in the works will also be important too. A lot of NET devs I talk to give a shrug when they hear that .NET Core is cross-plat and care more about their existing code working than x-plat/perf.

scottsauber on 6 May 2017

👍7

Guys, this is kind of garbage :(
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. Let me move on to the concrete use cases..

I work in a tooling group which builds line of business libraries and applications for use internal to a company and for sale to 'enterprise' clients. Mostly government organisations in our case but I'm sure you'll be hearing the same thing from the private sector. We have internal frameworks which encode business patterns into common abstractions - think "IDatabaseConnection", "IEntityProvider", "IWizardFlow", "ICodeGenerator" - and build RAD frontends on top of these pluggable backends.

In our stack, ASP.NET Core is a 'plugin' - it's an HTTP destination, used as a datastore abstraction and for hosting services and so on. It's also a 'frontend' - obviously a bunch of the LOB apps out there are websites, and it's a great new framework for webapps. So we have bidirectional interoperability requirements - A.N-C code which references random other components, and random other code which references A.N-C.

We're totally fans of Core CLR and portability, and we've ported a bunch of our components to target or multitarget netstandard. We've got one app that's hosted on Linux so far and hope to have more to come. However, there's no way that everything is going to be ported any time soon! We have still-live, actively-developed code which relies on

NTLM authentication (including advanced scenarios around tokens and SPNs)
System.Drawing as above (interesting wrinkle here: we need old image formats like TIFF, which new OSS libraries don't support)
Connecting to WCF/SOAP apis - still tons and tons of these out there
Windows crypto apis (including RSACng, ECDSA, and CSP for PKI tokens)
WPF guis - our clients are not switching to windows 10 any time soon and even when they do they won't want Store apps
Microsoft Office interop (particularly access and excel) for data import and export
Visual Studio extensibility
Third party plugins like the Oracle ADO.NET provider

Some of these technologies are never going to be supported by Core CLR. But they are real technologies, which are the basis of new app development - we need a version of .NET which has access to this stuff. Right now our position is manageable: we isolate "legacy" (really: platform-specific) dependencies into their own components which are net461 specific. Specific business apps then take a dependency on netfx if they need these features, and not otherwise. I envisage a future where this is rare for new apps.. but it's hard to imagine it ever being 0%.

You did all this work on csproj and the SDK because interop is important. ASP.NET Core is the carrot, the reason to want interop. I do not think it makes sense to take it away. And no, "you can load your references in one direction, but they will likely fail at runtime" is not interoperability.

gulbanana on 6 May 2017

👍36 ❤4 👎1

@gulbanana Can you describe the parts of the system that use ASP.NET Core why they need to be in the same process as .NET Framework. I appreciate the list (Visual Studio plugings, office interop etc) but are you embedded ASP.NET Core in all of those places today (I don't have a good picture from the above description)?

Also what were you using before ASP.NET Core existed? Or is this just a new endeavor that never used ASP.NET but took a 5-10 year bet on ASP.NET Core on .NET Framework being a thing? Did you look at Katana?

davidfowl on 6 May 2017

OK, here are some specific case studies. I'll say up front that I'm sure a lot of these could be handled by running the desktop-specific work in a separate process, though it seems like a huge hassle to basically turn a bunch of interface implementations into RPC. It's not like we can just use remoting or binary serialization between core and desktop CLRs, either..

NTLM/AD

For Single Sign On purposes we have apps which rely on the browser passing Windows login credentials through to IIS, which passes them on to an ASP.NET Core website. Part of the authentication process is then looking up information like whether the user is in a particular AD group. I'd really like to hear more about the "windows support pack" and whether it's intended to cover things like this.

System.Drawing

This is used in a webapp which creates thumbnails and basic image edits (rotation, watermark overlay). Many of the images being used date back to the time of dinosaurs, so there are things like TIFF in there. They're data maintained by a government department relating to particular property listings and land management. In this case the application was initially ASP.NET MVC, and got upgraded/rewritten through MVC 2, 4, 5 and now Core.

VSIX

This is a case of embedding A.N-C in netfx instead of the other way around. We have Visual Studio extensions for code generation which run 'templates' for various RAD scenarios. Some of these templates were created for web development and refer to A.N-C types at design time (they're created using preprocessor/runtime T4).

Crypto

This one really does have to be in-proc I think - we have licensing scenarios where the code is very security-sensitive. Broadly speaking, it's decrypting and verifying license files with respect to the environment the code is running in - this is a common library used in the backend of webapps as well as desktop apps. Eventually .NET Core seems likely to get enough crypto support that this one can be ported, but it hasn't today. For example, we one option we have today is Fortinet/ePass2003 PKI token support, where their middleware definitely does not support Core (and there's no timeframe for doing so).

Oracle ADO.NET

Using Entity Framework 6 with an Oracle backend doesn't have to be in-proc but it sure would be inconvenient for our websites to add an extra tier just to get to a database!

WPF Interop

We use Microsoft.Extensions.Logging in all our desktop applications these days- the logging abstractions themselves will need to be in-proc, even if implementations aren't.

gulbanana on 6 May 2017

👍12

As for what we used before ASP.NET Core - ASP.NET MVC! We could go back but it would be a great shame to give up all the benefits.

As an architect it's my screwup to have not looked into whether "ASP.NET Core runs on full framework" would persist beyond the first version. It honestly never occurred to me that it wouldn't. I just didn't imagine the possibility that as early as 2018 there might e.g. be no supported version which could load Office documents...

gulbanana on 6 May 2017

👍31

One thing I'm not clear about is where ASP.NET Core is used in each of those scenarios you mention.

NTLM/AD

This one makes sense and I'd like to understand what APIs that ends up mapping to. Is this just System.DirectoryServices? That one is actively being worked on (you can see it in corefx).

System.Drawing

This is a known gap that we're looking at addressing. I don't have any answers here yet and I won't suggest rewriting using ImageSharp (though that is an option). This will need to be addressed.

VSIX

Where's the ASP.NET Core here? Is it running inside of a visual studio extension?

Crypto

Is there a corefx issue for this one? Why wouldn't it just be ported? Unlike .NET Framework, .NET Core releases are decoupled from the OS so it's possible that this could happen sooner rather than later if deemed important. (Disclaimer: I don't know enough about crypto to understand the implications of doing this cross platform).

Oracle ADO.NET

Where does ASP.NET Core come in here? Are you just saying the Oracle provider hasn't been ported to .NET Core yet?

We use Microsoft.Extensions.Logging in all our desktop applications these days- the logging abstractions themselves will need to be in-proc, even if implementations aren't.

Microsoft.Extensions.* will remain netstandard so you're covered there.

davidfowl on 6 May 2017

👍5

Why no announcement/discussion?
I love what aspnet/.net core team do, but I have the same fears as @jhurdlow.

YuriiPovkh on 6 May 2017

Glad to hear about M.E.L. On the other points-

NTLM

Here's one class which is used in most of our applications. It makes pretty trivial use of the API, stuff which hopefully could be ported in theory (but hasn't been).
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

The codegen templates specific to asp.net core use the action/routing system (IFileProvider etc) to discover controllers and views etc and fill in our scaffolding. We're not hosting an ASP.NET webhost inside of visual studio, just introspecting over ASP.NET applications.

Crypto

I suspect the algorithms we use will be ported, but they haven't been yet. This would all look a lot different if the premise was, like, an announcement of a long-term plan to drop support for asp.net-core-on-netfx and discussion of when that might be possible!

Oracle

Yep, this would be resolved if an Oracle port happens (assuming it's full-featured and so on).

gulbanana on 6 May 2017

👍3

One more use case:
One of our applications imports legacy data from an Access application. Right now that import process runs on a server in an asp.net core website. It uses COM interop to load acedao.dll from the accdb/jet engine redistributable, reads tables into our entity abstractions, then saves them into a more modern SQL database.

This is another case of 'could be out of proc, but why should it have to be'. We'd essentially be using A.N-C as a frontend to a WebAPI 2 website or something, in which case we've gone back to that dependency on the past :(

Overall our goal is to move the vast majority of what we do to .NET Core. We would like as much interop as possible for as long as possible while we move things over...

gulbanana on 6 May 2017

WTF !!! 😨
Are you saying that ASP.NET Core 2 will not target Full .NET framework 4.x anymore !!!
We just starting a project 1 month ago with ASP.NET Core 1.1 and we targeted .NET 4.6 because we reference some Full .NET Lib. And we were going to upgrade to ASP.NET Core 2. But what I'm hearing from this post... 😞
Look, we chose ASP.NET Core because of its benefits (DI, merged API and MVC, ... powerful), so, please give as a change dude.

ikourfaln on 7 May 2017

👍2 😄1

We just starting a project 1 month ago with ASP.NET Core 1.1 and we targeted .NET 4.6 because we reference some Full .NET Lib

What do those libraries do? Did you read @shanselman 's initial reply https://github.com/aspnet/Home/issues/2022#issuecomment-299536123? It's possible to reference some .NET Framework libraries in .NET Core 2.0 (assuming they stay within the subset of APIs).

davidfowl on 7 May 2017

What do those libraries do? Did you read @shanselman 's initial reply #2022 (comment)? It's possible to reference some .NET Framework libraries in .NET Core 2.0 (assuming they stay within the subset of APIs).

@davidfowl yes I read @shanselman 's comment, we use some Libs made by company some of those lib uses WCF, all those Libs are stable, they target .NET 3.5, and we cant touch them.

ikourfaln on 7 May 2017

This is going to be a very common situation. I'd love to know whether any information has been gathered (telemetry?) on just how many users of ASP.NET Core are on .NET Core vs .NET Framework so far.

gulbanana on 7 May 2017

I am personally not emotional about this, but some observations:

most customers I have today use the asp.net core 1.x/full framework combination because they are scared to go all-in on the new stuff
telling from the nuget package download numbers, adoption of asp.net core is not great. With that move it will be even a bit harder to sell something that doesn't sell well right now.
it is great that you have identified the LDAP stuff to be a gap (I think I never seen anyone in the last 10 years using those libraries but maybe that's just me). The bigger issue will be 3rd party libs. These will be the real reasons why people will not move to .net core

This whole situation is again another good example of MS just making a decision without any heads up. Only because some people follow the check-ins, this thread here exists.

I might be wrong, but I thought .NET Core is now under governance of the DNF - so these decisions are not purely MS internal anymore.

leastprivilege on 7 May 2017

👍34

The LDAP/AD stuff is definitely a reason why I need to stay on top of net462 right now. I'd love to completely go, BAM -> NetCore completely, but this is a drawback.

I'm also using XML-RPC.net in one of my projects. It uses some serious Reflection.Emit in it, and I'm not sure whether NetCore 2 will support it completely. I'll have to try the Portability Analyzer to see for sure, though.

snickler on 7 May 2017

I find this whole situation a bit disheartening with just how quickly and easily an important decision like this which affects the future of .NET can happen without any transparency, at the last minute, yet again. Lots of energy has been invested in selling the existing .NET ecosystem on migrating to ASP.NET Core with the messaging (from my understanding) being that .NET Standard 2.0 will focus on compatibility and will be the release that bridges the gap with .NET v4.x to finally produce a solid, stable .NET platform the ecosystem can finally depend upon. I personally don't believe .NET Core will really take off until after .NET Standard 2.0 is released as I anticipated it to be the "promised stable land" we're all waiting for - now I have no idea what ".NET Standard 2.0" means, what exactly it's going to cover and which libraries are planned to be .NET Core only.

As there has been no prior official announcement, request for feedback, polling or rationale given, this decision "appears" to be have been done with zero community involvement or impact analysis to the existing .NET ecosystem and will likely fragment the entire ecosystem for many years to come. Removing .NET v4.x support removes a smooth migration path for many enterprises to be able to migrate their existing code-bases to ASP.NET's new development model. This won't encourage them to jump to .NET Core faster, it effectively prevents them from even attempting to, causing a massive fragmentation that will fracture the .NET ecosystem in two. I don't see how this will end up being any different than Python 2/3 which has been irreparably harmed by the fragmentation which it still hasn't been able to recover from in nearly a decade.

Most existing .NET code-bases are brownfield being developed behind-the-scenes by "dark matter" .NET developers, most of which won't have any idea that this decision was made given .NET Core 1.1 supports .NET v4.x and the messaging for .NET Standard 2.0 was the promise of improved compatibility. I'm expecting a massive backlash once the news and impact of this decision finally hits home. Many devs who have been selling adoption of .NET Core internally within their organization are going to feel betrayed given they've effectively have been migrating to a dead-end platform (if they're unable to fully migrate to .NET Core for whatever reason) a harsh reality they'll need to face just after they've succeeded in the monumental decision of convincing stakeholders in their organization to approve the resources required for their current migration.

Most organizations need to migrate their existing code-bases "in-flight" where they need to continuously deploy their existing systems whilst migrating their code-base "in parallel" which are going to want to deploy to .NET v4.x first, then after everything has stabilized and all issues have been ironed out they can then plan on a full migration to .NET Core from there.

This decision is also being made in the context of years of breaking changes to ASP.NET which IMO have eroded the trust that .NET is a stable platform that organizations can depend on. I love .NET Core's new development model, but IMO what we need most is a stable platform we can depend upon that the rest of the ecosystem can catch up to. .NET Core is still in uncanny valley, with immature tooling, incompatible dependencies, runtime issues, out of date documentation, etc - I haven't seen .NET this unstable since the early days when it was first released.

Why not run a poll on what .NET devs want more? i.e. a a solid, stable polished platform or a "fast moving" platform that delivers new features faster? I understand it would require a lot less effort to not have to worry about back-porting features to .NET v4.x but it would be invaluable to have a version of ASP.NET Core that focused primarily on delivering a stable compatible platform with long term support that can run on either .NET v4.x or .NET Core.

Has this ship sailed or is there an option to keep ASP.NET Core 2.0 as it is? i.e. with most libraries and abstractions covered by .NET Standard 2.0 and then in the next ASP.NET Core 3.0 release announce that the next platform will be .NET Core only? This will allow organizations to continue to move forward and adopt ASP.NET Core 2.0 and allow the rest of the ecosystem to catch up to, with stable and well supported tooling and libraries, whilst having a clean split from where .NET Core only platform/features start.

It's possible to reference some .NET Framework libraries in .NET Core 2.0 (assuming they stay within the subset of APIs).

This breathes uncertainty, very few people are going to want to risk their reputation and the health and stability of their systems and attempt a full migration to .NET Core when uncertainty exists on exactly which of their dependencies will and will not be able to run on .NET Core, which means more people staying on .NET v4.x for the foreseeable future.

I don't really know how this will ultimately play out and what the true impact of this decision will have on the entire .NET ecosystem, but the fact that important decisions like this with broad impact can happen without any external community involvement is concerning.

mythz on 7 May 2017

👍78 ❤14

I wish you guys were a little less hell bent on bifurcating your user base.

My point of view when creating a library is to make it easy to use as possible, for as many people as possible, in as many places as possible. It is a pain in the neck (search for #if compiler directives in Newtonsoft.Json and you get 1300+ results) but "It just works" is a powerful selling point.

JamesNK on 7 May 2017

👍45

Why not run a poll on what .NET devs want more? i.e. a a solid, stable polished platform or a "fast moving" platform that delivers new features faster? I understand it would require a lot less effort to not have to worry about back-porting features to .NET v4.x but it would be invaluable to have a version of ASP.NET Core that focused primarily on delivering a stable compatible platform with long term support that can run on either .NET v4.x or .NET Core.

Genuine question, ASP.NET Core 1.x currently supports .NET Framework and .NET Core. Lets say it was the stable platform you mention above, that we bug fix and support on both runtimes but didn't get more features. Would that be enough?

ASP.NET Core and .NET Core are the fast moving feature rich platforms for .NET at this point. It's a version of .NET that isn't tied to any operating system and that gives us the agility needed to innovate rapidly and release faster.

Has this ship sailed or is there an option to keep ASP.NET Core 2.0 as it is? i.e. with most libraries and abstractions covered by .NET Standard 2.0 and then in the next ASP.NET Core 3.0 release announce that the next platform will be .NET Core only? This will allow organizations to continue to move forward and adopt ASP.NET Core 2.0 and allow the rest of the ecosystem to catch up to, with stable and well supported tooling and libraries, whilst having a clean split from where .NET Core only platform/features start.

We're always open to feedback and ASP.NET Core 2.0 hasn't shipped yet. If ASP.NET Core 3.0 was the release that dropped .NET Framework would that make things better? If you look at some of the feedback from @gulbanana and @ikourfaln, there are technologies that are likely never to get ported and thus will never work on .NET Core, doesn't that mean supporting .NET Framework pretty much forever? Wouldn't we just have this same discussion a year from now? Maybe by then the ecosystem or libraries that support .NET Core would be bigger so it has less of an impact? What about those enterprise libraries that will never be updated (or where the source code was lost)? Will those change in a year?

davidfowl on 7 May 2017

👎10 👍5

My point of view when creating a library is to make it easy to use as possible, for as many people as possible, in as many places as possible. It is a pain in the neck (search for #if compiler directives in Newtonsoft.Json and you get 1300+ results) but "It just works" is a powerful selling point.

No offense @JamesNK but JSON.NET is a JSON parser and for the most part a single package (I know there are a few more). ASP.NET Core has > 200 packages.

davidfowl on 7 May 2017

👎41 😕8 👍4

No offense but I'm one guy working part time. Your problem is harder but you have exponentially more resources.

JamesNK on 7 May 2017

👍57 😄25

After reading through this and looking through the dependencies we have, I'm far less convinced this is a good idea.

As plans stand, we can't port any of our apps over to netstandard/netcoreapp until System.DirectoryServices is available (CoreFX issue #2089 here). So while we can port to ASP.NET Core 1.x, we can't go to 2.0. Looking at the applications here: Opserver, Stack Overflow itself, our internal apps...nothing would be ready as 2.0 is pitched to be at this point. According to the standup this week, critical things like DirectoryServices would still follow in a 2.x later release.

So between 1.0 and 2.0 it's changed from something I was preparing to move to, into something I can't go to. So yeah, I'd say it's not ready. ASP.NET is a way to expose the bits I need over HTTP. ASP.NET Is not the thing I need in itself. I'm not using .NET just for the web bits, I'm using it for the platform...as are a great many people. The platform is not ready for the wide variety of use cases users demand, so forcing users onto that platform causes pain and blockers.

The bottom line is that if we need AD auth (a huge part of the platform), we've just been abandoned on the 1.x line. That's where I was headed with our apps...but if this is the direction then there's no point is putting in effort here until the bits I need are available at the destination.

If we can say these critical things like System.DirectoryServices, System.Drawing, and the other top items people need will be ready with ASP.NET Core 2.0, my opinion changes a lot. If they're an afterthought (as current schedules show), please continue supporting the .NET Framework until they are.

Moving fast is great. I love it. I'm running alphas in production right now. But none of that matters if it doesn't work for your use case in the first place.

NickCraver on 8 May 2017

👍33

One thing I'm personally struggling with is the "stable platform" vs "new features" thing. On one hand, we want the platform to be stable and reliable and compatible, on the other hand nobody wants to stay on 1.x because it's doesn't have 2.x features. Are there super compelling features in ASP.NET Core 2.x that are pulling people in that direction or is it just the fact that we have more features than we had in 1.x (because it's new and shiny)?

If it's the latter, then do those people care about stability? If the answer is yes, then why isn't ASP.NET Core 1.x sufficient?

I'm not using .NET just for the web bits, I'm using it for the platform...as are a great many people. The platform is not ready for the wide variety of use cases users demand, so forcing users onto that platform causes pain and blockers.

Agreed, but in your opinion, how does that relate to ASP.NET Core 2.x dropping .NET Framework support? When more dependencies come online, they'll work every where so in a sense, as the platform moves forward the broad set of runtimes will get the benefits. All versions of ASP.NET Core applications would suddenly be able to take advantage of of those features.

davidfowl on 8 May 2017

👍4

If it's the latter, then do those people care about stability? If the answer is yes, then why isn't ASP.NET Core 1.x sufficient?

Everyone always wants new features, the possibility of new features, or at least knowing that they'll have the option to get more goodies sometime later. When you close off a platform and put it in "stable"/"maintenance mode, people see that as no longer being paid attention to.

clairernovotny on 8 May 2017

👍7

Are there super compelling features in ASP.NET Core 2.x that are pulling people in that direction or is it just the fact that we have more features than we had in 1.x (because it's new and shiny)?

Support - that's what we're paying for.

If the answer is yes, then why isn't ASP.NET Core 1.x sufficient?

Because support ends just about a year after release (according to Scott above). And I may barely be done porting Stack Overflow by then.

how does that relate to ASP.NET Core 2.x dropping .NET Framework support?

Because libraries I have to have aren't there. And I don't know when they will be. So I'd be stuck on 1.x and I have a time bomb until support ends. Will I have enough time to port from 1.0 to 2.x (or 3.x) before support ends? Probably not.

Large codebases can't just stop and port, they need time, it needs to happen in stages. Doing a .NET 4.6.x port onto ASP.NET Core was feasible as an intermediary step. Going to core at once is much harder, takes much longer, and requires longer-lived branches and more pain. If we can't do this in stages, I honestly just can't see us ever making the move off the the now-abandoned ASP.NET 5 line. There's no way I can justify the time, cost, and development impact it'll have.

I think many OSS authors are like myself as well - it's an extension of our day jobs. If we aren't using the platform or dogfooding it, the libraries are far worse off or don't get created. And we can't justify the time to maintain them with company hours that we spend today. And every library we make comes from a need we hit in production. The ecosystem dropping use cases has a lot of downstream impact that's not sudden, but still adds up.

Currently my view is this: there's a new platform that works until about July 2018. After that: I know nothing, I just hope what I need is available on netstandard/netcoreapp by then. And hope I have enough time to port before support ends. I'm not paid to hope though, I'm paid to make platform decisions for our company, and ASP.NET Core is a bad bet (for us) with this change and no date for a version that will work.

Let me offer a one-line summary: without .NET Full Framework support, ASP.NET Core does not offer a supported platform for our use cases for the next 2 years.

NickCraver on 8 May 2017

👍75

As a short version, it's this:

Priority 1: This has to work on net461, no matter what ifdefs, perf there is.
Priority 2. If you can make it 10x faster on .NET Core 2.0, then that's awesome. It's a great reason for people to choose the platform and/or migrate when they can.

The key thing here is that for long term support, it still has to work on the full framework, even if it's slower there.

clairernovotny on 8 May 2017

👍15

Priority 1: This has to work on net461

And if .NET Core was fully compat with net461 (within reason); so anything written for net461 worked on Core; would that then be ok?

Basically, at that point you have a more stable platform than net4x as you can do side-by-side and self contained (touch of x-plat too). Whereas net461 has whole machine changes to 4.6.1, 4.6.2, 4.7 etc

Obviously somethings will never work; like partial trust - but that never worked anyway.

benaadams on 8 May 2017

Genuine question, ASP.NET Core 1.x currently supports .NET Framework and .NET Core. Lets say it was the stable platform you mention above, that we bug fix and support on both runtimes but didn't get more features. Would that be enough?

I would love a to see a LTS release of ASP.NET Core 2.0 like Ubuntu / Redhat does with their LTS releases which they support for 5+ years. It would provide a solid compatible target that the rest of the ecosystem can have the confidence to commit to adopting.

I'm personally more interested in a stable .NET Standard 2.0 more than any future .NET Core-only features as I would love to get back to .NET development where everything just works again, the tooling isn't broken, the popular .NET packages all provide support for, the surrounding deployment and hosting solutions are polished and there's plentiful docs, posts, videos and knowledge-base available for a stable ASP.NET Core we can start building solutions on.

Wouldn't we just have this same discussion a year from now? Maybe by then the ecosystem or libraries that support .NET Core would be bigger so it has less of an impact? What about those enterprise libraries that will never be updated (or where the source code was lost)? Will those change in a year?

In an ideal world .NET v4.x and .NET Core would both support ASP.NET Core in the foreseeable future and it's only new .NET Core-only features which will only be available in .NET Core-only packages. But if MS is destined on leaving .NET 4.x behind then a ASP.NET 2.0 LTS release before you officially part ways would be the next best thing. By definition no-one is depending on new features that don't exist yet so no-one is going to be forced to upgrade to a .NET Core-only v3.0.

With the freedom of only having to support 1 platform you could potentially deliver new features that would entice developers to adopt the next latest and greatest version with continual new stream of features, personally I'm happy with the functionality ASP.NET has now and so I'm more interested in a stable version where everything's polished so I can go back to being productive again and focus on developing solutions on it instead of chasing an always moving platform.

mythz on 8 May 2017

👍8

Firstly, thanks @davidfowl for jumping into the thread and standing up/asking questions, etc. When there's a heated community asking heaps of Q's, it's easy to not step in and avoid being 'a target'. So thanks for getting involved, constructively. /me salutes you.

I see two main points/threads coming out of this conversation:

Request to support .NET desktop in vnext. (that's 99% of the replies in here)
Lack of community consultation over such an important decision. (the 2 or 3 replies in here).

TL;DR;

Can we please be more open with big important vnext changes.
Allocate some time for some RFC from the community about these vnext changes.

@mythz stated it nicely in his opening sentence to his (at this point), ~most recent~ 2nd most recent comment:

I find this whole situation a bit disheartening with just how quickly and easily an important decision like this which affects the future of .NET can happen without any transparency, at the last minute, yet again.

This is what really hit me personally and I would love some official replies/comments from the appropriate folks at MS who make these calls plz. "We" have been around this community for a hella long time - familiar faces, familiar names and it's pretty fair to say - all following the same positive goals. I'd even go on to say "we" are a pretty large, extended family, warts-and-all.

So I feel that with the new direction MS has taken (OSS-all-the-things, etc) and with some recent mega-uber-.NET-threads in the last 12/18 months (read: learning from those community discussion experiences) ... that "we" are all in this together and that some of these Really-Big-Things ™️ would be discussed in the open, way ahead of time.

So - can we please have some of these big decisions talked about in the open, before hand? Get some positive community consultation and discussion?

Note: I do accept that this project(s) are not a democracy and that the _decisions_ are made by MS. No probs. I'm not criticizing _that_. I'm talking about the steps way prior to that. Also, I'm not asking for _everything_ to be put up for RFC, etc. Just the odd major ticket item - like what this thread has started.

PureKrome on 8 May 2017

👍44 ❤11

But if MS is destined on leaving .NET 4.x behind then a ASP.NET 2.0 LTS release before you officially part ways would be the next best thing. By definition no-one is depending on new features that don't exist yet so no-one is going to be forced to upgrade to a .NET Core-only v3.0.

I don't understand. No one is depending on features in ASP.NET 2.0 yet either as they don't exist in a release. So isn't ASP.NET Core 1.x that version? It runs on full framework, core 1.0 and core 2.0 and can act as the stepping stone to ASP.NET Core 2.x?

benaadams on 8 May 2017

👍1

@onovotny

Everyone always wants new features, the possibility of new features, or at least knowing that they'll have the option to get more goodies sometime later. When you close off a platform and put it in "stable"/"maintenance mode, people see that as no longer being paid attention to.

Yes but it's really hard to guarantee the same level of quality when .NET Framework is the big stable supported tied to the OS component. As @terrajobst said, some things will definitely be ported at some point but others will need to be figured out. The fact is, ASP.NET Core runs best on .NET Core because we have the ability to rev the entire stack all at once. So far, there are big performance differences between the 2 runtimes and we've yet to take dependencies on new APIs because of .NET Framework support. As we move forward, we will be adding new APIs that may or may not appear on .NET Framework at some point and we don't want to rev at the pace of the most stable and slowest moving runtime (.NET Framework).

@NickCraver

Because support ends just about a year after release (according to Scott above). And I may barely be done porting Stack Overflow by then.

I'm not sure that's entirely accurate. When 2.0 is available 1.1 will still be supported. So what is this "support" you're talking about? Do you mean paid support or do you mean that we'll fix issues when they come up?

Because libraries I have to have aren't there. And I don't know when they will be. So I'd be stuck on 1.x and I have a time bomb until support ends. Will I have enough time to port from 1.0 to 2.x (or 3.x) before support ends? Probably not.

Like I said though, those libraries will light up irregardless of the .NET Core version. I think what you're saying is that you want to use the latest version of ASP.NET Core (whatever that is) and you want it to be supported on .NET Framework until there are enough libraries on .NET Core so that the port is easy for you specific scenario.

Large codebases can't just stop and port, they need time, it needs to happen in stages. Doing a .NET 4.6.x port onto ASP.NET Core was feasible as an intermediary step. Going to core at once is much harder, takes much longer, and requires longer-lived branches and more pain. If we can't do this in stages, I honestly just can't see us ever making the move off the the now-abandoned ASP.NET 5 line. There's no way I can justify the time, cost, and development impact it'll have.

How does ASP.NET Core revving versions affect that? If we dropped .NET Framework support in 3.0 (as people seem to be eluding to in this thread), wouldn't you be in that same dead end regardless? You'd have your ASP.NET Core 2.0 application ported running on framework for a year and when 3.0 comes out, you'd be unable to upgrade. You would be able to do this anyway with ASP.NET Core 1.1.x which runs on .NET Framework and is supported even when ASP.NET Core 2.0 is out.

Currently my view is this: there's a new platform that works until about July 2018. After that: I know nothing, I just hope what I need is available on netstandard/netcoreapp by then. And hope I have enough time to port before support ends. I'm not paid to hope though, I'm paid to make platform decisions for our company, and ASP.NET Core is a bad bet (for us) with this change and no date for a version that will work.

So one more year is enough time for everyone? That's not the feeling I'm getting from this thread.

davidfowl on 8 May 2017

👍4

Priority 1: This has to work on net461, no matter what ifdefs, perf there is.
Priority 2. If you can make it 10x faster on .NET Core 2.0, then that's awesome. It's a great reason for people to choose the platform and/or migrate when they can.

The key thing here is that for long term support, it still has to work on the full framework, even if it's slower there.

The only reason .NET Framework works as well as it does today is because we were intentional about supporting it. It didn't come for free, it's not "just faster on core", we had to intentionally design the system so that it was possible to make it work on .NET Framework. Even though you don't see it yet, the feature gap will grow between the 2 once we decide (and we've decided) to take dependencies on APIs that don't exist in .NET Framework as yet. We can do what @PinpointTownes says and start throwing NotSupportedException when those feature gaps appear but IMO that's a pretty bad experience.

davidfowl on 8 May 2017

👍5 ❤1

We spent a large development budget on porting our ASP.net MVC5 app to ASP.net core full framework to make it work nice with Azure Service Fabric. The whole project was multi-month in which there were several weeks dedicated to porting our web application (and frankly, wrestling with the awkward VS2015 tooling).

The only reason that worked was because full framework was supported, since we're currently running SignalR on ASP.net core (to @davidfowl discouragement). As far as I can tell, SignalR still isn't supported on Asp.net Core?

Then we spent a week or so migrating to the new VS2017 tooling. Fine.

_Note that up to this point there are no improvements to the product at all, it's just adjusting code shape to fit into Microsofts platform and tooling requirements._

Now you're telling me that within 12 months I'll have to perform more featureless development effort with no guarantee that I'll even be able to do it, depending on a bunch of hand waving and should be able to's? No thanks.

First, get everything Microsoft branded that people are using in ASP.net core full framework today working on ASP.net core only. Second, find out what else (if anything) would be blocking the ecosystem from adopting ASP.net core as desired. Then, and only then, drop support for Netfx as is being discussed.

jahmai on 8 May 2017

👍7

We can do what @PinpointTownes says and start throwing NotSupportedException when those feature gaps appear but IMO that's a pretty bad experience.

That's not exactly what I said: when going with cross-compilation, ifdefs should definitely be the preferred option to exclude APIs unavailable on a specific platform, but if for whatever reason you absolutely MUST have this API signature in the public contract, then you can go with NotSupportedException.

kevinchalet on 8 May 2017

I don't understand. No one is depending on features in ASP.NET 2.0 yet either

I'm expecting most devs are waiting for a stable and highly compatible .NET Standard 2.0 that their dependencies are supporting before they commit to migrating to ASP.NET Core. They're not going to want to adopt .NET Core 1.1 now knowing it's been EOL'ed and MS doesn't have a good history of providing long term support for any old DNX/.NET Core version. If there was a highly compatible stable LTS release that the rest of the ecosystem can safely adopt, enterprises should have everything they need to run their systems on it and they wont feel obliged to upgrade to .NET Core vNext as they'll have everything they need on v2.0 and when the time comes it will be a lot easier to plan their migration from ASP.NET Core 2.0/.NET v4.6 to a future .NET Core only version.

mythz on 8 May 2017

👍6

@mythz

I'm personally more interested in a stable .NET Standard 2.0 more than any future .NET Core-only features as I would love to get back to .NET development where everything just works again, the tooling isn't broken, the popular .NET packages all provide support for, the surrounding deployment and hosting solutions are polished and there's plentiful docs, posts, videos and knowledge-base available for a stable ASP.NET Core we can start building solutions on.

Agreed with everything there but I don't see how this decision affects anything you said. I want all of those same things 👍 .

With the freedom of only having to support 1 platform you could potentially deliver new features that would entice developers to adopt the next latest and greatest version with continual new stream of features, personally I'm happy with the functionality ASP.NET has now and so I'm more interested in a stable version where everything's polished so I can go back to being productive again and focus on developing solutions on it instead of chasing an always moving platform.

Right, isn't that ASP.NET Core 1.x? If support was extended on 1.x wouldn't that be enough? We could just make sure that ASP.NET Core 1. which is netstandard 1.x runs on .NET Core 2.0 (which it already does) and support that for say another year or so.

davidfowl on 8 May 2017

👍5

That's not exactly what I said: when going with cross-compilation, ifdefs should definitely be the preferred option to exclude APIs unavailable on a specific platform, but if for whatever reason you need to have this API signature in the public contract, then you can go with NotSupportedException.

I'm not even talking about exposing public API. I'm talking about APIs we need to call that won't exist in netstandard. #ifdefs don't help here. We would just throw as the gaps increase.

davidfowl on 8 May 2017

@davidfowl Totally valid questions - answers:

Do you mean paid support or do you mean that we'll fix issues when they come up?

Active fixes for issues - will 1.x receive fixes for all the things we break, or will we be told to upgrade for a fix in some cases? (note: that's an upgrade we can't do until our libraries like DirectoryServices are there...and even if we can it's nowhere close to a free or even cheap, it's likely months at a minimum). We're big, we're fast, we will find breaks in the framework. We have for every major and minor release for years. Support is critical to us.

I think what you're saying is that you want to use the latest version of ASP.NET Core

Nope, I want a version that works and a path forward. With 1.x, we only have the first half. Until this issue, the second was kind of assumed.

How does ASP.NET Core revving versions affect that?

Because if you're dropping support for full framework, we're forced to make a major change to stay in support.

If we dropped .NET Framework support in 3.0 (as people seem to be eluding to in this thread), wouldn't you be in that same dead end regardless?

Maybe? The point is having parity in use cases before making the dive. It's my career, I can't tell our company to jump when the other side may not support us. That'd just be irresponsible on my part. If our use cases were supported in the 2.x timeframe, then there's a clear path forward and it's far safer to make bets on ASP.NET Core.

So one more year is enough time for everyone?

The absolute length of time doesn't really matter - it needs to be use-case compatability + time (IMO). If our use cases worked today (e.g. AD auth), then 2 years is enough, yes. But currently that's not the case, so agreeing that an arbitrary point in time from now is okay is, at best, premature.

It didn't come for free, it's not "just faster on core", we had to intentionally design the system so that it was possible to make it work on .NET Framework. Even though you don't see it yet, the feature gap will grow between the 2 once we decide (and we've decided) to take dependencies on APIs that don't exist in .NET Framework as yet.

Then no offense, but why not just say that and close the issue? That statement seems like there's nothing more to discuss, and our time is better spent elsewhere. If that's not the case, please clarify?

The main problem is we can't port our workloads to netstandard today, or, as currently proposed, at launch. If what we already have doesn't work, why would we care about new features? The team keeps talking about performance (and that's awesome, really), but something I can't use running fast really doesn't matter much.

As an architecture/platform lead, I have to decide what bets we make. Currently, this is a bad bet. When version 1 supports you but version 2 doesn't but hopefully will someday, that's a really bad gamble to make with other people's time and money. At least for us, we chose .NET for the features, ecosystem, and support. Currently, in the new word we've gone from all 3 of those to 1. The ecosystem isn't there yet (API surface, libs), and support is far shorter than we're used to, without any guaranteed upgrade path and an unknown amount of time to do so.

NickCraver on 8 May 2017

👍15

@jahmai

The only reason that worked was because full framework was supported, since we're currently running SignalR on ASP.net core (to @davidfowl discouragement). As far as I can tell, SignalR still isn't supported on Asp.net Core?

Even the SignalR 2 isn't supported on ASP.NET Core (though people have hack it to make it work). SignalR is still under development and won't even be out with ASP.NET Core 2.0, it's coming later.

Now you're telling me that within 12 months I'll have to perform more featureless development effort with no guarantee that I'll even be able to do it, depending on a bunch of hand waving and should be able to's? No thanks.

Are there features you need in ASP.NET Core 2.0? Or are you just speculating that eventually you'll need to upgrade to the next ASP.NET Core and at that point things won't work on .NET Framework?

First, get everything Microsoft branded that people are using in ASP.net core full framework today working on ASP.net core only. Second, find out what else (if anything) would be blocking the ecosystem from adopting ASP.net core as desired. Then, and only then, drop support for Netfx as is being discussed.

As part of netstandard 2.0 lots of work was done identifying important APIs to bring back so that libraries that targeted .NET Framework were for the most part binary compatible with it. Of course there are areas that just won't work like WCF, WPF etc. but it will help as we did some research and ~60% of the libraries are API compatible with netstandard 2.0 (correct me if I'm wrong on that number @terrajobst) and may just work on .NET Core 2.0.

davidfowl on 8 May 2017

Right, isn't that ASP.NET Core 1.x? If support was extended on 1.x wouldn't that be enough?

I expected .NET Standard 2.0 was going to be the stable platform which bridges compatibility with .NET 4.x so it makes more sense LTS support will be around that. No-one is expecting 1.1/.NET v4.x to be EOL'ed mid-release so it would be respectful to announce LTS on the latest version when it's released, not pulling .NET 4.x support before it's released, no-one does LTS in retrospective to old versions like that.

I know we're maintaining our .NET Core packages in a separate *.Core packages so we can remain on a separate release cadence that follows the latest .NET Core version as the moment we merge into the main NuGet packages it means we're committing to a stable release that we're going to officially support, so we need to be highly confident we have a version we can support for the foreseeable future which I expected from .NET Standard 2.0, not the current .NET Standard 1.1/1.3/1.6 mix. I remember there was also a time where there was going to be a 1.7/8 stop gap release that was going to be incompatible with 2.0 breaking the .NET Standard versioning expectation which aren't signals of a stable platform.

I've been anxiously expecting .NET Standard 2.0 was destined to provide the much sought after highly compatible surface area and much needed stability.

mythz on 8 May 2017

👍2

Even the SignalR 2 isn't supported on ASP.NET Core (though people have hack it to make it work). SignalR is still under development and won't even be out with ASP.NET Core 2.0, it's coming later.

Not sure how you intended that statement, but I feel it just reinforces my concerns.

Are there features you need in ASP.NET Core 2.0? Or are you just speculating that eventually you'll need to upgrade to the next ASP.NET Core and at that point things won't work on .NET Framework?

I want to move to netstandard2 at some point for reasons. I'll need to move to move my web app to asp.net core 2 for that, right?

As part of netstandard 2.0 lots of work was done identifying important APIs to bring back so that libraries that targeted .NET Framework were for the most part binary compatible with it. <...>

Sure, and I like what's being done with netstandard, but if something was missing from netstandard you can work around because you can target full framework in applications that need it. We now have a handful of pure netstandard 1.3 libraries (our source) shared across: Xamarin.iOS, Xamarin.Android, net46, Asp.net core 1.1 - because we can suppliment missing funtionality in netstandard with specific framework targetting libraries, including net46 stuff in our asp.net core web app.

The _only_ reason we have these netstandard libraries is because we needed to port our huge web application (as I mentioned previously). I would _like_ to not have to expand our platform specific code base for other platforms, and instead keep moving up the netstandard chain. I really don't want to be stuck on netstandard 1.3 because there is no path to move to asp.net core 2.

jahmai on 8 May 2017

Active fixes for issues - will 1.x receive fixes for all the things we break, or will we be told to upgrade for a fix in some cases? (note: that's an upgrade we can't do until our libraries like DirectoryServices are there...and even if we can it's nowhere close to a free or even cheap, it's likely months at a minimum). We're big, we're fast, we will find breaks in the framework. We have for every major and minor release for years. Support is critical to us.

I don't think there's an issue with support. I actually don't think this would be a huge problem and if it made people feel more confident in taking a bet then maybe it's worth extending support for 1.x to a longer timeframe.

Nope, I want a version that works and a path forward. With 1.x, we only have the first half. Until this issue, the second was kind of assumed.

It just means you need to stay on 1.x until all of your dependencies are ported no?

@NickCraver All of your complaints are talking about things missing on .NET Core rather than ASP.NET Core. In .NET Core 1.x and ASP.NET Core 1.x those 2 entities ship together but are completely decoupled. I haven't heard a single reason for wanting to use ASP.NET Core 2.0 specifically other than valid concerns about v1 supporting something and v2 not supporting it. I think we'd be having the exact same discussion in a year if there was another reason you weren't able to port to .NET Core only (maybe during the development of ASP.NET Core on full framework you took some new dependencies that will never be ported as an example).

Then no offense, but why not just say that and close the issue? That statement seems like there's nothing more to discuss, and our time is better spent elsewhere. If that's not the case, please clarify?

I'm here answering and replying because I'm trying to figure out why we need to support .NET Framework if so, for how long. I'm still getting a mixed vibe on this thread about those time frames. Also there's a general fear I can understand about being "relegated to ASP.NET Core 1.x" but nothing concrete in terms of specific features that are needed in 2.x.

One of the major things I like about coupling .NET Core and ASP.NET Core is that it solves some of the versioning and naming madness. Lots of people don't even know ASP.NET Core runs on .NET Framework (it even confuses new comers to the stack). That said, we have lots of customers with lots of different needs and we listen to their feedback.

davidfowl on 8 May 2017

👍7

@mythz

I've been anxiously expecting .NET Standard 2.0 was destined to provide the much sought after highly compatible surface area and much needed stability.

Sure, but like I said, ASP.NET Core, .NET Core and .NET Standard in 1.x are completely decoupled. You can use any .NET Standard library on any version of .NET Core that supports it. So if .NET Core 2.0 is a new LTS, we could still declare that ASP.NET Core 1.x is supported on it.

@jahmai

I want to move to netstandard2 at some point for reasons. I'll need to move to move my web app to asp.net core 2 for that, right?

No, that's not right. You can move to netstandard 2 whenever you want without moving your web app to ASP.NET Core 2.0.

The only reason we have these netstandard libraries is because we needed to port our huge web application (as I mentioned previously). I would like to not have to expand our platform specific code base for other platforms, and instead keep moving up the netstandard chain. I really don't want to be stuck on netstandard 1.3 because there is no path to move to asp.net core 2.

You don't need to be stuck on netstandard 1.3. The 2 things are unrelated.

davidfowl on 8 May 2017

👍2 ❤1

When version 1 supports you but version 2 doesn't but _hopefully will someday_, that's a really bad gamble....

This I think is the crux of the issue. We've had comments that _some_ of the gaps (DirectoryService, et. al.) are known and will be addressed. We need something more concrete then that.

I'm OK with ASP.NET Core targeting .NET Core and with us missing the 2.0 boat if the roadmap is clear on when we can expect these gaps (and which gaps) will be addressed (again, assuming there's enough time to port before 1.X becomes unsupported).

As things currently stand, the issue we're blocked on for WCF has been stagnant since May 2015 and may never get addressed.. Leaving us effectively stranded.

ctolkien on 8 May 2017

👍1

@davidfowl

No, that's not right. You can move to netstandard 2 whenever you want without moving your web app to ASP.NET Core 2.0.

Excellent. In that case, as long as Microsoft ensures that 1.x is supported (all kinds of bug fixes and operational support) until it offers customers a proper 2.x migration path (e.g. SignalR), then I am comfortable biding my time until we need asp.net core 2.

jahmai on 8 May 2017

👍4

It just means you need to stay on 1.x until all of your dependencies are ported no?

Correct, but that has to be a known timeframe. We have no dates, the only thing we've been told so far is "not in 2.0"...so that's not good. For example, System.DirectoryServices has been requested since Mid-2015, and is still missing yet is often repeated as the most wanted by users (followed by System.Drawing). Saying we're bringing .NET Standard 2.0 to ~60% API parity but missing the bits users have asked for most certainly sends mixed signals about what's important.

All of your complaints are talking about things missing on .NET Core rather than ASP.NET Core.

That is incorrect. I need the bits we need to run (e.g. AD auth) on a supported platform. The missing thing is support from the latter. Support for 1.x is certainly my main concern. We have no supported path forward or any timelines for when we can expect one.

I think we'd be having the exact same discussion in a year

I don't think that's the case. The problem is we couldn't port today. The APIs aren't there. As long as there's no single point in time we were even capable of porting, discussions about the future are a bit moot. I would expect .NET full framework support in ASP.NET Core to be deprecated once there was parity and most users could move over. And I'd expect that release to have a long support timeframe for people to move over.

If DirectoryServices, Drawing, etc. are coming in 2.x then awesome. That release should support .NET Framework, and be a LTS release. And 3.x should drop full framework support.

One of the major things I like about coupling .NET Core and ASP.NET Core is that it solves some of the versioning and naming madness. Lots of people don't even know ASP.NET Core runs on .NET Framework (it even confuses new comers to the stack). That said, we have lots of customers with lots of different needs and we listen to their feedback.

Fair enough, but all of the madness there is secondary to "does it even work?". Currently, that's a firm no. ASP.NET and .NET Core/Standard/whatever may be 2 sets of things inside Microsoft (and I totally get that), but to developers it's still 1 platform. The ASP.NET Side needs the APIs to be useful to many, and they're not there yet. This move further cuts down on the available APIs. The ASP.NET team may get the ones they want, but it's at the expense of the ones we need.

NickCraver on 8 May 2017

👍16

@ctolkien @NickCraver

This I think is the crux of the issue. We've had comments that some of the gaps (DirectoryService, et. al.) are known and will be addressed. We need something more concrete then that.

Correct, but that has to be a known timeframe. We have no dates, the only thing we've been told to far is "not in 2.0"...so that's not good. For example, System.DirectoryServices has been requested since Mid-2015, and is still missing yet is often repeated as the most wanted by users (followed by System.Drawing).

These gaps are related to .NET Core itself though and I can understand the anxiety not knowing when those dependencies will be available and that's why helping us prioritize these would be good. The good news is that netstandard 2.0 and netcoreapp2.0 laid the group work to make of other libraries easier to port. I expect that after once we ship 2.0, it'll be much easier to bring up other dependencies by porting swaths of code on top of our very compatible base.

davidfowl on 8 May 2017

👍3 ❤1

Will CSOM run in netcore 2? That would be a huge blocker for us and one area that I haven't heard anything on.

smbecker on 8 May 2017

👍1

@davidfowl I sincerely hope that's the case too, but I'm not betting our company on it. Dropping support before that happens, and not after, I strongly disagree with. I think this happening in the 3.x time frame after those critical APIs for many consumers are in place is totally valid. Doing so before they're ready just halts our adoption.

I was on the path to adopting 1.0 assuming that 2.x (or whatever's actively developed/fixed) would support full framework until those critical APIs were ready (I'm being serious - you know how much work I've put into libraries already). But at this point, I can't do that at Stack...it was a bad assumption. I cannot in good conscience tell our teams to use .NET Core while the future of any port is so uncertain. I really wish I could, but it's not worth the risk and the pain at the moment.

NickCraver on 8 May 2017

👍12

@NickCraver

I would expect .NET full framework support in ASP.NET Core to be deprecated once there was parity and most users could move over. And I'd expect that release to have a long support timeframe for people to move over.

What's the measure of "most users" here? What's the list of dependencies that need to be covered until we can drop support? Your list is different from other users on this list. I also expect some people will say forever or until .NET Core reaches .NET Framework parity (which is just unrealistic). I'll still pose that ASP.NET Core 1.x is good enough for that purpose and we should look at extending support for that until said time.

That is incorrect. I need the bits we need to run (e.g. AD auth) on a supported platform. The missing thing is support from the latter. Support for 1.x is certainly my main concern. We have no supported path forward or any timelines for when we can expect one.

What ASP.NET Component is missing for this scenario? When you say 1.x vs 2.x it would be useful if you mention ASP.NET Core vs .NET Core.

If DirectoryServices, Drawing, etc. are coming in 2.x then awesome. That release should support .NET Framework, and be a LTS release. And 3.x should drop full framework support.

I mentioned this before, what ASP.NET Core features do you need that ASP.NET Core 1.x isn't sufficient for this?

ASP.NET and .NET Core/Standard/whatever may be 2 sets of things inside Microsoft (and I totally get that), but to developers it's still 1 platform

Agreed but we need to clear up the FUD on this discussion so that we can properly evaluate the impact. ASP.NET Core 1.x targets .NET Standard 1.x (1.0 - 1.6) and .NET Framework 4.5.1. This means it can run on any platform that supports those versions of netstandard and .NET Framework. It means that ASP.NET Core 1.x will run on .NET Core 2.0.

davidfowl on 8 May 2017

@smbecker

Will CSOM run in netcore 2? That would be a huge blocker for us and one area that I haven't heard anything on.

I have no idea what that is. Is it this https://msdn.microsoft.com/en-us/library/ff798388.aspx? If so there was no work done to explicitly support it. It might just work based on the .NET Framework compatibility in .NET Core 2.0 but my guess is that it will never be ported to .NET Core (just based on my 5 minutes of looking at it), but I could be wrong.

davidfowl on 8 May 2017

What's the measure of "most users" here? What's the list of dependencies that need to be covered until we can drop support? Your list is different from other users on this list. I also expect some people will say forever or until .NET Core reaches .NET Framework parity (which is just unrealistic). I'll still pose that ASP.NET Core 1.x is good enough for that purpose and we should look at extending support for that until said time.

Let's start with the top missing APIs - those are what cause blocks for the most people. For us, that's DiretoryServices, which is number 1. If that's not even there, it's a really bad sign to the community. I agree lists are different, but if we're not even including number 1...

What ASP.NET Component is missing for this scenario? When you say 1.x vs 2.x it would be useful if you mention ASP.NET Core vs .NET Core.

I mentioned this before, what ASP.NET Core features do you need that ASP.NET Core 1.x isn't sufficient for this?

I mean support for the latest ASP.NET Core that supports Full Framework (and therefore the libraries I need). I hope that's 2.x, as we want modules, razor pages, etc. We have uses for a lot of 2.x features. But it sounds like our only option is 1.x at this point. We can't make the jump from ASP.NET 5 to ASP.NET Core and from full framework with all our working libs to netcoreapp in 1 move. It's too much. It's too costly. It's too risky. And now we're unsure if we can do that expensive, risky move inside a support window. That's a bad situation - so bad that it's better to not move (as things stand today). I think that's really unfortunate.

NickCraver on 8 May 2017

👍3

What ASP.NET Component is missing for this scenario? When you say 1.x vs 2.x it would be useful if you mention ASP.NET Core vs .NET Core.

Unless there's a way to handle AD authentication/queries through some Microsoft.Authentication.* NuGet package, then that's one big thing. I'm currently in that same boat, but since I'm running .NET Core 1.1 on top of .NET 462, I'll be able to pull that off. Outside of that, how would I be able to query any AD groups, metadata through supported means? I have seen in the corefx repo that there IS a lot of work happening on System.DirectoryServices though, so I'm happy about that at least.
System.Data.Common.DbDataAdapter/SqlClient.SqlDataAdapter. Currently, I'm only able to access that when running on .NET Core on top of the full .NET Framework. I guess it's more of a convenience thing, since I can still use the DbDataReader/SqlDataReader.

Basically I need to know that there will be a guarantee of SOME supported way to handle AD Authentication while using ASP.NET Core 2.x, without the need of the full .NET Framework.

snickler on 8 May 2017

I've been thinking about this a lot today and I'm finding that my concerns are different than most of those here (not that those concerns aren't just as important, if not more so).

I'm still kind of stuck on the use case of consuming ASP.NET Core packages on netstandard. Up until this issue I had assumed (perhaps wrongly) that netstandard was the de-facto target for libraries. In other words, the intended behavior for library authors would be to target netstandard unless there was a necessary and compelling reason not. This ensures not just compatibility with Framework but the other platforms like Xamarin and UWP. The work on .NET Standard 2.0 seemed to support this by trying to unify the API surface area of the various runtimes into a common don't-need-to-think-about-it target.

To me, this change signals something different. Granted, at the end of the day ASP.NET Core is just a library and perhaps it does have "necessary and compelling reasons" not to support the common netstandard surface area. But it's also one of the most visible Microsoft-developed .NET libraries and by saying "we want the latest and greatest so we're going to stop supporting netstandard" it signals to all the other library developers (or at least it does to me) that maybe they should stop trying so hard to support netstandard and just start targeting the Core runtime. Why bother with all that compatibility stuff when Microsoft doesn't even care that much about it? .NET Core 4 lyfe. And maybe that's for the best - it's certainly different than where I thought we were going with multiple runtimes and a mostly unified API surface area though.

This concern gets even deeper when considering that ASP.NET Core contains many, many libraries that are useful outside the context of ASP.NET directly. Maybe it was wrong to assume that those were ever intended to be used in isolation, but it would be an awful shame to loose them. Library authors who want to use them will have to decide to switch their own targeting to .NET Core as well or stay on netstandard and loose access to them. I suspect many will choose the former, further splintering library support for alternate platforms. At least if I've understood the comments here that targeting different platforms for the supporting libraries is too difficult.

Finally, I'm somewhat (though a little less) concerned about the comments here that as soon as it's possible new APIs will be added to Core to rev in conjunction with ASP.NET. Particularly that those new APIs may not ever make it into netstandard or .NET Framework. I certainly understand that there may be some exciting stuff that can be done if the legacy and compatibility concerns are dropped or loosened. But to be frank, I've gotten the impression that the ASP.NET Core team is often out there charging ahead. That's not necessarily a bad thing, but it's also led to a number of broader descisions that have had to be walked back. I can't help but wonder if this, and the subsequent rapid evolution of the Core runtime, will have the result of greatly fracturing the set of runtimes over time (and again, it's not just Windows/Framework that will be left behind - there's also Xamarin, Mono, UWP, etc.).

This whole thread has caused me to reorient my understanding of the future of .NET around .NET Core instead of netstandard. Maybe I'm being extreme and that'll soften in the coming weeks, or maybe that's even the intended position and it's all for the best - either way, I'm currently tempted to just go out and target .NET Core for my own stuff and only focus on that going forward from everything I've read here.

daveaglick on 8 May 2017

👍30

@NickCraver

I mean support for the latest ASP.NET Core that supports Full Framework (and therefore the libraries I need). I hope that's 2.x, as we want modules, razor pages, etc. We have uses for a lot of 2.x features.

Right now it's 1.1.1 (there's no modules in 2.0), Razor Pages is a good one, another is SignalR. Those are the 2 things I see being the most painful as part of this.

We can't make the jump from ASP.NET 5 to ASP.NET Core and from full framework with all our working libs to netcoreapp in 1 move. It's too much. It's too costly. It's too risky. And now we're unsure if we can do that expensive, risky move inside a support window. That's a bad situation - so bad that it's better to not move (as things stand today). I think that's really unfortunate.

Is it though? The move from ASP.NET Core 1.x to 2.x or 3.x assuming your dependencies have been ported would be trivial. If you plan on moving to ASP.NET Core in general, moving to 1.1 is a good first step and you won't be saving any work avoiding it.

davidfowl on 8 May 2017

@snickler

Basically I need to know that there will be a guarantee of SOME supported way to handle AD Authentication while using ASP.NET Core 2.x, without the need of the full .NET Framework.

Until System.DirectoryServices is supported on .NET Core then is there a reason you can't use ASP.NET Core 1.x on .NET Framework?

davidfowl on 8 May 2017

Until System.DirectoryServices is supported on .NET Core then is there a reason you can't use ASP.NET Core 1.x on .NET Framework?

That's what I'm currently doing. I'm just looking forward in hopes that I can not have to worry about the .NET Framework if I don't need to. Currently, it restricts me to my Windows machine as the System.DirectoryServices.AccountManagement namespace doesn't exist in Mono. In those same regards, will there be System.DirectoryServices.AccountManagement available outside of the constraint of Windows? That one little piece forces me to jump between machines while debugging my MVC project and my Xamarin.iOS app locally.

snickler on 8 May 2017

If you plan on moving to ASP.NET Core in general, moving to 1.1 is a good first step and you won't be saving any work avoiding it.

I totally agree, if we knew support was there until we upgraded to another platform that worked. Right now, we don't know when the necessary bits will be available in the .NET Core world so setting a time cap now and not knowing when those bits will come later is me betting on a promise. That's the core issue. If we have a supported, overlapping release that allowed porting then I'd be all set and happy to invest. If support is dropped before the APIs are there, we're jumping a gap on faith, with an unknown amount of runway.

I keep referencing DirectoryServices because that's what I know doesn't work on netcoreapp2.0 today. There will of course be other things we find that fall in the same boat. We need ASP.NET Core + full framework + support for several years on some platform. With 1.x, we don't get a lot of gains, we actually get very little. Performance isn't an awesome argument since we already render pages in ~18ms and it's dwarfed by transport time. 2.0 however, offers quite a few good items. Razor pages and the prospect of plugins makes it very appealing to port to. So much so as to be justifiable.

Right now, the only version to go to with support (1.1.x with longer support, is what I expect after reading this thread) isn't worth moving to. It'd basically be a lot of time and effort to get to where we are today. 2.x at least offers some decent improvements and bits we'd want to take advantage of. They help justify the cost of moving.

NickCraver on 8 May 2017

👍8

Performance isn't an awesome argument since we already render pages in ~18ms

On a minor OT rant, I'd like to know how you're able to render pages in ~18ms @NickCraver . That's awesome

snickler on 8 May 2017

@daveaglick

I'm still kind of stuck on the use case of consuming ASP.NET Core packages on netstandard. Up until this issue I had assumed (perhaps wrongly) that netstandard was the de-facto target for libraries. In other words, the intended behavior for library authors would be to target netstandard unless there was a necessary and compelling reason not. This ensures not just compatibility with Framework but the other platforms like Xamarin and UWP. The work on .NET Standard 2.0 seemed to support this by trying to unify the API surface area of the various runtimes into a common don't-need-to-think-about-it target.

Nothing has changed here. In fact a bunch of our libraries that we want to run on other platforms are still netstandard. If you re-read some of the above:

Microsoft.Extensions.* (Logging, DI, Configuration, FIleProviders etc)
EntityFramework
SignalR clients (they need to run on .NET Framework, Xamarin, UWP etc).

.NET Standard is the defacto way to write libraries that run everywhere. Library authors should aim to target netstandard where possible to get the broadest platform reach. Library authors have to decide if they want to have reach or not. That's why libraries like JSON.NET support netstandard1.x and .NET framework 2.0. They go the extra mile to make things "just work" as @JamesNK mentioned above.

ASP.NET Core moving away from netstandard in some places is more of a statement that these APIs aren't meant for UWP applications and we certainly don't test them there (as an example). It also tries to solidify that .NET Core and ASP.NET Core are a single product that versions together (since it has Core in the name). With ASP.NET Core 1.x supporting both .NET Core and .NET Framework that message was a little blurry and it causes confusion for lots of people (especially new developers) and we did it to ease the library gap problem.

This concern gets even deeper when considering that ASP.NET Core contains many, many libraries that are useful outside the context of ASP.NET directly. Maybe it was wrong to assume that those were ever intended to be used in isolation, but it would be an awful shame to loose them. Library authors who want to use them will have to decide to switch their own targeting to .NET Core as well or stay on netstandard and loose access to them. I suspect many will choose the former, further splintering library support for alternate platforms. At least if I've understood the comments here that targeting different platforms for the supporting libraries is too difficult.

I'm guessing those are still netstandard. Which ones aren't?

I can't help but wonder if this, and the subsequent rapid evolution of the Core runtime, will have the result of greatly fracturing the set of runtimes over time (and again, it's not just Windows/Framework that will be left behind - there's also Xamarin, Mono, UWP, etc.).

I think netstandard will evolve, but .NET Framework will always be the last to get new APIs (Xamarin and Mono are pretty fast to add things).

davidfowl on 8 May 2017

👍3

@snickler

That's what I'm currently doing. I'm just looking forward in hopes that I can not have to worry about the .NET Framework if I don't need to. Currently, it restricts me to my Windows machine as the System.DirectoryServices.AccountManagement namespace doesn't exist in Mono. In those same regards, will there be System.DirectoryServices.AccountManagement available outside of the constraint of Windows? That one little piece forces me to jump between machines while debugging my MVC project and my Xamarin.iOS app locally.

Make sure you file issues like that on dotnet/corefx. Assuming your dependencies will be ported (unless it's wildly popular) is the wrong thing to do.

davidfowl on 8 May 2017

👍2

@davidfowl Question: I want to File -> New Project with ASP.NET Core 2.0 and authenticate against AD. Will this be possible? I simply cannot imagine a Microsoft platform shipping without the ability to do this.

NickCraver on 8 May 2017

👍2

Agreed with everything there but I don't see how this decision affects anything you said. I want all of those same things

By dropping support for .NET v4.x it will kill a popular migration path and fragment the .NET ecosystem even further and prevent many devs and organizations from being able to adopt it which will reduce the wider community pool of knowledge and investment in ASP.NET Core since many .NET devs will need to support their existing ASP.NET v4.x code-bases indefinitely (which they get paid to work on full-time).

The smaller the market share .NET Core has, the lower priority it will be for library maintainers to support it and some likely never will if they work for an organization who'll no longer be able to consider migrating to ASP.NET Core because of this, which in turn effects anyone else depending on their packages, and so on. These are all side-effects of increasing the burden in adopting ASP.NET Core, by not having a stable platform, long term support guarantees and now killing off a popular migration path.

I believe everyone here wants the .NET ecosystem to thrive but it appears we're at odds with the MS team on how best to achieve it as I firmly believe dropping .NET v4.x this early on before a known quantity, highly compatible, stable LTS release is available is a mistake that will have detrimental effects for years to come.

mythz on 8 May 2017

❤10

@davidfowl Thanks - your comment helps a lot. I had (apparently incorrectly) gathered that most/all the supporting libraries were moving off of netstandard as part of this change. I use quite a few, and know others who do as well, so hearing that they aren't is welcome news.

daveaglick on 8 May 2017

👍1

@NickCraver what kind of auth are you using against AD today? OpenIdConnect, WsFed, NTLM, other?

Tratcher on 8 May 2017

@Tratcher AD auth, via DirectoryServices (we need to query group membership, etc. - the standard bits)

NickCraver on 8 May 2017

👍1

@mythz I think that's reasonable and I think extending the support lifetime of ASP.NET Core 1.x would be sufficient to cover most of the cases.

davidfowl on 8 May 2017

❤4 👍4

I see why you have to make this decision at some point but I too believe it's premature and would be happiest with:

ASP.NET Core 2.x being LTS and last to support Full Framework (surely since we were already in preview you are not too far gone) with also SignalR following later in the year supporting it so that it's the target framework for making the jump from ASP.NET to ASP.NET Core
3.x dropping support for Full Framework and being released when top dependencies are migrated over

Simply extending support for ASP.NET Core 1.1 in my view would not be enough as that platform is not mature/adopted enough to be a target for many ASP.NET migrations (in my case SignalR being the blocker).

rohatsu on 8 May 2017

👍6 😄1

Just for the lulz, I tried using EntityFramework 6 - that I've seen massively used in ASP.NET Core 1.0 apps I've worked on - with the latest preview2 .NET Core nightly builds. Guess what...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

Stop pretending assemblies designed and compiled for the full framework will work flawlessly on .NET Core: trivial cases (read hello world apps) will probably work, but in many cases, you'll end up being blocked by missing APIs or non-functional APIs.

What's absolutely terrible is that you'll only realize it doesn't work at runtime. In some cases, it won't even be obvious at all. For instance, .NET Core's SqlClient doesn't support ambient transaction enlistment nor distributed transactions with TransactionScope: even if you find a way to make EF 6 work, your TransactionScopes won't be effective at all and your DB calls won't use the isolation level you need.

kevinchalet on 8 May 2017

👍11 😕10

I feel it necessary to add my two cents here as far as my concerns with this move. We have a desktop application that is primarily Windows Forms with some of the newer areas developed in WPF. There is over 15 years of effort in that application and it will take years to move completely away from WinForms. I wish that weren't the case but it is. We have been working to build more modularity into the codebase so that we can consume the business and data access layers across a newer web interface and the existing WinForms application. I intended to move to ASP.NET Core for our newer web application very soon but as I just stated I will need to consume a large majority of our existing codebase that is targeting .NET v4.6.x. I know for sure we are using System.Drawing and System.Security.Cryptography. We also make heavy use of TransactionScope in ways mentioned above.

I have been greatly looking forward to gaining some of the benefits of ASP.NET Core like the ability to encapsulate areas of our web application into separate assemblies without needing to rely on MEF to bring it all together. There are many additional reasons but that one is the thing that makes it really nice. However, if I transition our application to ASP.NET Core I'll likely be stuck on 1.x for the foreseeable future because we have to maintain portability on our backend code with WinForms. I've been focused primarily on the Web product so I can't tell you where we are hooking into things like WMI, etc, and if it impacts the question of portability, but I know we are within our codebase. We are in a really interesting phase right now and the last thing I want to have to do is develop all the Web versions of our features onto ASP.NET MVC 5 and accrue a bunch of new legacy code that will need to be ported at some future endeavor.

I'm sure we're going to have a lot of usages that are going to keep us away from targeting .NET Standard even if/when we no longer use WinForms. We're a Microsoft Partner and we work directly with Microsoft for our product in several ways so I don't want to go into too much detail as to what we do here but I'd be happy to have a more private discussion with @shanselman or @davidfowl if you need more details into what we are doing. I'm also going to be at MS Build and could meet and talk to either of you there if you will be present.

I think you have not considered companies using your stack with these kinds of challenges. However, full disclaimer: I do intend to run the portability analyzer mentioned earlier to see where we are indeed stuck because of the need to maintain that portability within our codebase. I'll gladly provide you with a list of any .NET Framework APIs that fail that check.

millman82 on 8 May 2017

Mouahaha. Not sure if I should laugh or cry...

Here's the report generated by the ApiPort analysis tool for my trivial 23-line EF 6 app that doesn't work:

kevinchalet on 8 May 2017

👍4 😕3

Cross-compiling is an overhead that must be balanced with customer and product needs. This is why we want to get this feedback so we can more concretely define what the landscape looks like for both our customers and us as we continue to evolve ASP.NET Core moving forward.

Prior to this issue being opened, was there a feedback process?

brockallen on 8 May 2017

👍4

We're all talking about time frames and support for 1.1 but the fact that ASP.NET Core is going to drop full framework at all has come as a huge surprise to me.

My understanding was that the core framework was a cross platform play, a new framework that's made up of a subset of the full framework that isn't coupled to Windows. The 2.0 release was the one we've all been waiting for where we get most of the API's back.

ASP.NET Core was the dog food for this new framework, a new web framework which depended on such a small surface area of framework API's that it could run everywhere.

I was expecting that once the core framework made close parity with the full framework all new API's would be added to netstandard and eventually make it into both frameworks. We would all start targeting netstandard and everything would be rainbows an unicorns.

Now to find ASP.NET won't even dogfood netstandard and are going framework specific eh :/

jkells on 8 May 2017

👍5

@rohatsu

Simply extending support for ASP.NET Core 1.1 in my view would not be enough as that platform is not mature/adopted enough to be a target for many ASP.NET migrations (in my case SignalR being the blocker).

What if SignalR worked on ASP.NET Core 1.x? What else is immature about the platform that you need?

davidfowl on 8 May 2017

@millman82 Thanks for sharing that. It does sound like you would be stuck on the version before .NET Framework support was dropped for a while. So some of the suggestions here where we keep 2.x compatible and 3.x would drop it might not even work for you. Why not just stay on ASP.NET Core 1.x? What's missing from it that you need in your port? Or is it just the concern the same as @NickCraver 's (that 2.x not supporting it makes you nervous about taking a bet on it).

davidfowl on 8 May 2017

@jkells

I was expecting that once the core framework made close parity with the full framework all new API's would be added to netstandard and eventually make it into both frameworks. We would all start targeting netstandard and everything would be rainbows an unicorns.

That's not far fetched, it's just missing the time component. Will eventually make it into all framework that each ship on their own schedule.

Now to find ASP.NET won't even dogfood netstandard and are going framework specific eh :/

Part of it still targets netstandard as was mentioned several times in this thread.

davidfowl on 8 May 2017

Why not just stay on ASP.NET Core 1.x?

You can't - it's out of support 1 year from when 2.0 drops (assuming 2.0 is the next LTS).

ctolkien on 8 May 2017

@davidfowl It is definitely a large part of that. We also use OData and SignalR in our current web application and that needs to be in ASP.NET Core before we can move over. However, the one thing I don't want to happen is to be stuck in limbo when support for ASP.NET Core 1.x is dropped and there is no migration path with the framework parts we are using that aren't currently supported. I foresee ASP.NET Core replacing ASP.NET wholesale. It may be somewhere on down the road but it is coming. Knowing that I'd hate to rewrite our UI now in ASP.NET MVC 5 (we have a few things there now but it is easy to move because it is small) only to a few years later rewrite it again in ASP.NET Core once the end of life for ASP.NET arrives.

We could potentially be setting ourselves up to get burned badly if that migration path is nonexistent when EOL of ASP.NET Core 1.x does arrive if it is extended in the interim if we target Core 1.x now. We could probably navigate around some of it with micro services, however, that of course has its own concerns.

millman82 on 8 May 2017

@ctolkien

You can't - it's out of support 1 year from when 2.0 drops (assuming 2.0 is the next LTS).

Assume for a second that it isn't out of support when 2.0 drops. Isn't that enough?

davidfowl on 8 May 2017

However, the one thing I don't want to happen is to be stuck in limbo when support for ASP.NET Core 1.x is dropped and there is no migration path with the framework parts we are using that aren't currently supported

Replace 1.x with 2.x in that sentence. Do you think that in a year all of your dependencies would be ported?

davidfowl on 8 May 2017

Replace 1.x with 2.x in that sentence. Do you think that in a year all of your dependencies would be ported?

Not at all, however, I'd expect that when no longer able to target .NET Full they would be. I understand why you would want to push that up but I don't think you can expect companies to adopt something that will fall out of support with no means of transitioning to a newer version because the missing dependencies haven't been ported.

millman82 on 8 May 2017

👍4

I don't think you can expect companies to adopt something that will fall out of support with no means of transitioning to a newer version because the missing dependencies haven't been ported.

Why would it fall out of support? In my hypothetical world we'd be supporting ASP.NET Core 1.x on .NET Framework for longer.

davidfowl on 8 May 2017

Why would it fall out of support? In my hypothetical world we'd be supporting ASP.NET Core 1.x on .NET Framework for longer.

My question is how much longer? Also, is the team large enough to bring those necessary dependencies like SignalR and OData to ASP.NET Core 1.x and maintain support until all those missing dependencies have, in fact, been ported? Seems like it counters the arguments made earlier about why you would want to drop .NET Full support now. Honest question...

millman82 on 8 May 2017

My question is how much longer? Also, is the team large enough to bring those necessary dependencies like SignalR and OData to ASP.NET Core 1.x and maintain support until all those missing dependencies have, in fact, been ported? Seems like it counters the arguments made early about why you would want to drop .NET Full support now. Honest question...

I'll throw out a random number, 3 years. The ASP.NET Team doesn't own the Odata integration, the odata team does so I cant answer for them. As for SignalR, I think it would be possible to target ASP.NET Core 1.x.

The problem I see is that each person has a different set of "missing dependencies" which makes it impossible to reason about when it's even "ok" to drop .NET Framework support for everyone. It's also likely that some of those dependencies may never be ported (like CSOM).
Of course being on the 1.x train you'll get bug fixes and minor features but the bulk of the work would still be happening in the latest major of ASP.NET Core.

Also none of this prevents you from using .NET Core 2.0 or .NET Standard 2.0 with ASP.NET Core 1.x. I just want to make sure everyone is aware of that because this threads constant conflates ASP.NET Core with .NET Core (which is one of the reasons we want to target .NET Core only).

davidfowl on 8 May 2017

The problem I see is that each person has a different set of "missing dependencies" which makes it impossible to reason about when it's even "ok" to drop .NET Framework support for everyone.

Engage the eco system to find out what the list is (no, this issue is not the place to do it). If it's a Microsoft owned dependency, port it. If it's not, engage with the owner to inform them of the plans and assist with a migration guide (if they don't do anything, not Microsoft's fault). In the time it takes to go through this process, support ASP.net core 1.x. I can't see any other way to achieve your goals without upsetting lots of folks. This is a big thing being proposed that needs a high level of care and attention to do right.

jahmai on 8 May 2017

👍6

Personally, I think there is far more confusion around .NET Framework vs .NET Standard vs .NET Core. When I saw I could target .NET Framework I never said, "but this is ASP.NET Core so why can I use .NET Framework". The distinctions between the above are far more confusing for most of your customer base. I love everything ASP.NET Core is doing. Also love the direction with .NET regarding platform independence. I just think the domain of confusion is incorrectly stated. I'd say the majority of your user base is going to have some amount of code that isn't portable due to the nature of what it is doing and the APIs it is targeting within the Framework.

My preference would be to work toward API parity within .NET Core and .NET Standard and .NET Framework. Also, figure out which is the one people should strive to target. As I believe was stated earlier, perhaps in a slightly different way, .NET Standard feels like a bandaid. Eventually, I'd expect .NET Core to be the only "framework" option and when that happens .NET Framework and .NET Standard go by the wayside. Myself, and I think with most whom have spoken up since the announcement, would like to be able to continue to benefit from the work you are doing on the ASP.NET Core side without having the freedom of what they are executing their code on top of being removed.

I think the cases being considered as exceptional, like mine where I have a dependency on things like WMI are not as exceptional as the team may think. Again, I'll do the research and see what is missing (though the post earlier giving incorrect portability results has me a little concerned over the accuracy) and I will gladly report that to you in a more private medium.

Bottom line, we're passionate about this because we want to use it.

millman82 on 8 May 2017

👍1

Personally, I think there is far more confusion around .NET Framework vs .NET Standard vs .NET Core. When I saw I could target .NET Framework I never said, "but this is ASP.NET Core so why can I use .NET Framework". The distinctions between the above are far more confusing for most of your customer base. I love everything ASP.NET Core is doing. Also love the direction with .NET regarding platform independence. I just think the domain of confusion is incorrectly stated. I'd say the majority of your user base is going to have some amount of code that isn't portable due to the nature of what it is doing and the APIs it is targeting within the Framework.

We have lots of customers and we have new developers that have never seen .NET in their life. We need to cater to everyone because that's what we try to do as Microsoft. People running on .NET Framework know, love and understand it works so sure you understand that ASP.NET Core runs on .NET Framework but as a new developer approaching the platform, I would hope to never mention that as it muddies the story compared to something like go or node (which have pretty much 0 legacy at this point).

My preference would be to work toward API parity within .NET Core and .NET Standard and .NET Framework. Also, figure out which is the one people should strive to target. As I believe was stated earlier, perhaps in a slightly different way, .NET Standard feels like a bandaid. Eventually, I'd expect .NET Core to be the only "framework" option and when that happens .NET Framework and .NET Standard go by the wayside. Myself, and I think with most whom have spoken up since the announcement, would like to be able to continue to benefit from the work you are doing on the ASP.NET Core side without having the freedom of what they are executing their code on top of being removed.

These things all happen in parallel. ASP.NET Core doesn't stop working on features until "everything" is ported over to .NET Core from .NET Framework. ASP.NET will continue to innovate and take advantage of APIs that are available on .NET Core since we ship as part of the same box.

davidfowl on 8 May 2017

👍1

I see a few trending ideas on this thread from:

I want you to support .NET Framework forever.
I want to you support .NET Framework until the dependencies I need for my application are ported.
I just need 1 more year, that will be enough time for me to drop .NET Framework support (ASP.NET Core 3.x).

There's also the fact that we didn't write an announcement (which is our fault) but one is coming (I promise, I blame the weekend).

I also don't know what API parity looks like for most people here, my guess is it's different for different people. .NET Framework is a 15+ year old solid, reliable, enterprise technology tied to Windows.
.NET Core was made to write modern light weight cross-platform micro services and has slowly been evolving to be more compatible so that porting libraries was easier. That said, I don't know what it means to approach .NET Framework in terms of compatibility or if that's even a goal (it wasn't originally). At some point you will not be able to use ASP.NET Core on top of .NET Framework and there will be some dependency that can't be rewritten that isn't compatible with .NET Core. Applications will need to account for that when being designed with ASP.NET Core in mind (in some near future).

davidfowl on 8 May 2017

With respect to the projects I work on, a much-longer period of support for 1.1 would be a decent mitigation. It's unlikely we could drop netfx dependencies in 1 year but far more likely with the +3 years you suggested as a strawman. It'd be really nice to have a release where everything comes together at the 2.0 level first though - that's the point where everything was supposed to become easier to port! I'm only speaking for one organisation but "2.0 will be a LTS release; 3.0 will drop netfx" would basically be business as usual for us instead of a cause for FUD.

I'd also like to echo what @PureKrome said about appreciating this engagement, it has been a very informative discussion.

gulbanana on 8 May 2017

On the topic of parity - I had previously assumed that .net core would not ever approach .net framework levels of compatibility, but that this was fine because asp.net core would continue to support both.

I think that as a community we basically use .net core in order to use asp.net core, not for its own merits. Like you said, they're one product, and I'd thought of the core clr as an optional part of that product with benefits and drawbacks if chosen.

gulbanana on 8 May 2017

👍5

After sleeping over it for a night -

I personally think it is a good idea to leave the old .net framework behind and write the best possible web framework for the modern runtime.

But you know that it is definitely risky and you might lose some of your customers here along the way (I hope not - but I do a lot of consulting - and .NET Core is for many companies out of reach right now - let's hope 2.0 changes that).

..and yea - communication around this was (as usual) something you can improve (most polite version of this sentence for a German) ;)

leastprivilege on 8 May 2017

👍12 ❤5

+1

xiexingen on 8 May 2017

I personally think it is a good idea to leave the old .net framework behind and write the best possible web framework for the modern runtime.

I agree strongly. My hope was that this wold have been a gradual change, e.g. Kestrel dropping support first for perf (http.sys based hosting remaining), then mvc/* following for API and functionality improvements while porting / compatibility testing efforts for netstandard2.0 begin.

dasMulli on 8 May 2017

👍4

Excellent. In that case, as long as Microsoft ensures that 1.x is supported (all kinds of bug fixes and >operational support) until it offers customers a proper 2.x migration path (e.g. SignalR), then I am >comfortable biding my time until we need asp.net core 2.

+1

able to port to .NET Core only (maybe during the development of ASP.NET Core on full framework you took some new dependencies that will never be ported as an example).

Totally agree.
Right now I think that is good decision. I think in ideal scenarios we need more than 1 year support, I dont known maybe 2-3 year, and information about what will be ported, for confidence of the community.
No .net 461 support.

YuriiPovkh on 8 May 2017

@dasMulli

I agree strongly. My hope was that this wold have been a gradual change, e.g. Kestrel dropping support first for perf (http.sys based hosting remaining), then mvc/* following for API and functionality improvements while porting / compatibility testing efforts for netstandard2.0 begin.

We don't even run performance tests on .NET Framework... Porting testing and improvements to .NET Core and .NET Standard will happen anyways, that IMO has no bearing on whether .NET Framework support is dropped or not. If anything, it makes us laser focus on those scenarios because it the only target.

davidfowl on 8 May 2017

@gulbanana

It'd be really nice to have a release where everything comes together at the 2.0 level first though - that's the point where everything was supposed to become easier to port! I'm only speaking for one organisation but "2.0 will be a LTS release; 3.0 will drop netfx" would basically be business as usual for us instead of a cause for FUD.

Why do you need ASP.NET Core 2.0 (forget .NET Standard and .NET Core 2.0)?

davidfowl on 8 May 2017

We don't particularly need the features in asp.net core 2.0. I would very much like to have the simpler build processes and interop that comes with the 2.0 wave.. will asp.net core 1.1, if running on netcoreapp2.0, be able to use netstandard2.0 libraries? Would that be considered a 'standard' and supported scenario rather than something which nobody tests or pays attention to?

gulbanana on 8 May 2017

👍1

Basically if 1.1 became LTS I worry about issues being closed eighteen months from now with 'well, you can do this using the 2.0 apis'..

gulbanana on 8 May 2017

We don't particularly need the features in asp.net core 2.0. I would very much like to have the simpler build processes and interop that comes with the 2.0 wave.. will asp.net core 1.1, if running on netcoreapp2.0, be able to use netstandard2.0 libraries? Would that be considered a 'standard' and supported scenario rather than something which nobody tests or pays attention to?

Of course that would work. As I've been saying all along the 3 things are completely decoupled today. Here's a sample project running ASP.NET Core 1.1 on .NET Core 2.0 using a version of System.Configuration APIs that have been ported to a .NET Standard 2.0 package:

https://github.com/davidfowl/AspNetCore1OnNetCore2

davidfowl on 8 May 2017

👍6

I'd be happier to accept this if there was an automatic interop layer between .NET Core and .NET Framework (not the current one that can throw exceptions at runtime, and not self-made internal WebAPI calls) - some kind of a wrapper ("WowNET"?) that would force us to keep 4.6-dependent code in separate .dlls but allow running legacy at the cost of performance (which in case of LOB apps is not the main concern). Do you think this would be technically possible?

I'm also wondering if this change means that full framework itself is approaching end of life and won't perform any other significant role than being a legacy component once most APIs are moved over to .NET Standard.

rohatsu on 8 May 2017

👍1

Basically if 1.1 became LTS I worry about issues being closed eighteen months from now with 'well, you can do this using the 2.0 apis'..

That's always a concern. The answer is always "it depends". Bug fixes are weighed accordingly and big features are likely to fall into that bucket more often than not.

davidfowl on 8 May 2017

@rohatsu

I'd be happier to accept this if there was an automatic interop layer between .NET Core and .NET Framework (not the current one that can throw exceptions at runtime, and not self-made internal WebAPI calls) - some kind of a wrapper ("WowNET"?) that would force us to keep 4.6-dependent code in separate .dlls but allow to run legacy at the cost of performance (which in case of LOB apps is not the main concern). Do you think this would be technically possible?

Kinda like this https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root but for .NET Core and .NET Framework. We did something very similar when we ASP.NET supported Helios, a .NET Framework shim that was used to boostrap coreclr in IIS. The hacks to make it work were pretty ugly though it was a mix of COM and passing structures to the Main method via string[] args. All technically feasible though. I'm not sure what sort of fidelity you'd expect, as they aren't the same runtime and you can't pass objects back and forth. You'd also be running 2 GCs, 2 Jits tons more dlls in the same process and I'm not sure what you're gaining over doing something out of proc.

I'm also wondering if this change means that full framework itself is approaching end of life and won't perform any other significant role than being a legacy component once most APIs are moved over to .NET Standard.

Far from. .NET Framework evolves and ships at the pace of windows as it is a windows component. We just released .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) as well with a bunch of new features. The fact is that .NET Core can and will ship faster because it isn't tied to anything else, so APIs, runtime features, etc will appear there first. It doesn't mean things won't eventually make their way to .NET Standard and .NET Framework. It'll just take longer to get there. The fact that .NET Framework updates in-place is the reason we're so careful when porting changes. Any change can break any application when an update is auto pushed to a billion machines 😉 . With .NET Core, the framework is side by side so applications need to opt in to the newer version to get newer features or fixes. There's just a lot more freedom there.

davidfowl on 8 May 2017

Just to weigh in with the net4x libraries we currently today in ASP.NET Core 1.x, that wouldn't work in 2.0: EntityFramework 6. EFCore just has to many missing features we use missing (for example interception/lifecycle hooks). So we're stuck on EF6 for a while.

And according to @PinpointTownes 's post, EF6 does not work with the current (in development) version of ASP.NET Core 2.x.

nphmuller on 8 May 2017

@nphmuller then you'd keep using ASP.NET Core 1.x until more dependencies moved (I don't know how many things you require from EF Core and what the status is).

davidfowl on 8 May 2017

@davidfowl Sure, if the support window from ASP.NET Core 1.x does not pass during that time.
The main feature is interception (lifecycle hooks). Other missing features can be worked around more easily for us. Interception is in their backlog, but not tied to a release. And my gut tells me it won't be implemented for a while.

nphmuller on 8 May 2017

@gulbanana: I think that as a community we basically use .net core in order to use asp.net core, not for its own merits.

Speak for yourself. There are a number of us for whom the primary benefit of .NET Core is getting off of Windows on the server.

bradwilson on 8 May 2017

👍11 ❤1

And, I suppose, all you dirty Mac-owning hippies. 😝

bradwilson on 8 May 2017

😄4

@bradwilson And, I suppose, all you dirty Mac-owning hippies.

Speak for yourself, some of us aren't hippies ;P

But yes, escaping Windows (or really, IIS and http.sys) is what I want .NET Core for along side xcopy deployment, perf, etc.

Isolating old code in separate services or porting to ASP.NET Core does pay off for reasons other than new and shiny.

adamhathcock on 8 May 2017

@PinpointTownes is a reference error, what happens if you reference System.Configuration as per https://github.com/aspnet/Home/issues/2022#issuecomment-299810945? EF6 says it has no dependencies due to everything being in ye'olde GAC/Full Framework bundle

benaadams on 8 May 2017

@benaadams and @PinpointTownes the reason its failing is because System.Configuration.ConfigurationManager isn't the DLL name that .NET Framework expects. I'm not sure if the port of System.Configuration is valid.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

davidfowl on 8 May 2017

Yes, being able to run non-windows servers is great and a big draw.. but without asp.net core what would you run on them? Even Nancy for .net core relies on asp.net core via kestrel, UseOwin(), etc.

gulbanana on 8 May 2017

I've created several microservices that don't use ASP.NET Core. They're stuff like worker processes that poll a queue to do it's work.

adamhathcock on 8 May 2017

👍3

This is not fair, we follow roadmaps, and you didn't say anything about that before !!
If you said that before, we will not use ASP.NET Core in our project because we need .NET 4.x Libs.
Our planning includes updating our projects to ASP.NET Core 2 because of needed new functionalities.
We need ASP.NET Core 2 to target .NET 4.x too. if not possible, what about the support of ASP.NET Core 1.x, are you planning to add all new functionalities to it too or just fixing bugs.

ikourfaln on 8 May 2017

Our planning includes updating our projects to ASP.NET Core 2 because of needed new functionalities.

Which ones?

davidfowl on 8 May 2017

@PinpointTownes is a reference error, what happens if you reference System.Configuration as per #2022 (comment)?

Adding <Reference Include="System.Configuration" /> has no effect (i.e the same exception is thrown), as it seems it can't be resolved from the GAC (not sure it's really surprising, tho'):

I'm not sure if the port of System.Configuration is valid.

So the official conclusion is... you can't use a library written for .NET Framework 4.x on .NET Core if it uses System.Configuration?

kevinchalet on 8 May 2017

@PinpointTownes I'm not even sure that version of System.Configuration is shipping (the one in the package). Maybe it is, maybe it isn't (that's a discussion to start on corefx). I'm just telling you why your sample broke the way it did.

Adding has no effect (i.e the same exception is thrown), as it seems it can't be resolved from the GAC (not sure it's really surprising, tho'):

AFAIK, there's no default support for the GAC references in SDK projects. See https://github.com/dotnet/sdk/issues/987#issuecomment-286307697 to see how to enable it.

So the official conclusion is... you can't use a library written for .NET Framework 4.x on .NET Core if it uses System.Configuration?

My conclusion is that you should open an issue on CoreFX with the sample your provided above.

davidfowl on 8 May 2017

👍4

@davidfowl thank you for reply
Some needed features and helpers on EF Core are planned in 2.0 especially for mapping data (Self-contained type mappings)...
Anyway, I need just to have a clear idea about the roadmap of ASP.NET Core 1.x, our team is confused and worried.

ikourfaln on 8 May 2017

👍1

One thing I'm personally struggling with is the "stable platform" vs "new features" thing. On one hand, we want the platform to be stable and reliable and compatible, on the other hand nobody wants to stay on 1.x because it's doesn't have 2.x features. Are there super compelling features in ASP.NET Core 2.x that are pulling people in that direction or is it just the fact that we have more features than we had in 1.x (because it's new and shiny)?

@davidfowl I do think signlarR is one such feature, it would have been in my previous project atleast. However I also think a lot of the concern is due to the relatively short support windows for 1.1 (2018?) if people were assured they could run on asp.net 1.1 until they are ready to switch to core, meaning potentially, years, and also be covered for patches that would calm people down a bit.

I also think asp.net core 1.1 support on .net core 2.0 is worth highliting even more, it gives people (what I think) a good migration path: asp.net 5 on 46 >asp.net core 1.x on 46 > asp.net core 1.x on .net core 2.0 > asp.net core 2 on .net core 2. That would be a path that would reduce the risk a lot of people worry about.

aL3891 on 8 May 2017

I've been following this since the first day and even after all of these discussion and clarifications ( thanks @davidfowl ) I feel a lot of us are being thrown under the bus.

I understand the reasoning for cutting loose from Full/desktop .NET framework. Hell, I even agree that's the way to empower ASP.NET, BUT I fail to see how this is being decided now instead of from the beginning.

Of course we customers would seriously complain in both scenarios, but I'd rather be in the "I can't use the new shiny thing" than bet on "I can use it, invest in slowly migrate and replace when possible" and just find out that's false.

PabloAlarcon on 8 May 2017

I fail to see how this is being decided now instead of from the beginning.

At a guess:

On .NET Core 1.x you couldn't run Full framework libraries, so it would have been a complete break.

On .NET Core 2.x you can mostly run Full framework and can run .NET Standard 1.x - 2.0 libraries, so it isn't a major break.

Any issues with running Full framework libraries on .NET Core 2.0, should probably be filed in dotnet/corefx

benaadams on 8 May 2017

It's clear that the main scenario is "modern web apps on the cloud", which often don't have many third party dependencies ( or are "just code" ones ).

Most of the discussion so far has been focused on BCL availability, but many of us depend on third party components( low level integration with complex Video, Audio subsystems for example... ) that are often lagging on the .NET landscape and almost always rely on lower level technologies that probably don't end up being supported.

With ASP.NET Core 1, we are developing our modern services, targeting .NET standard for Libs and choosing to deploy on Full .NET or .NET Core per services dependencies.

I could bet on this because in the case of finding unsupported features/components, we could easily target Full .NET. And the bet was on the long term platform, as staying on Full .NET looks like a decision to avoid in a few years.

PabloAlarcon on 8 May 2017

👍2

_On .NET Core 2.x you can mostly run Full framework and can run .NET Standard 1.x - 2.0 libraries, so it isn't a major break._

@benaadams There is a big difference between being able to use most of the BCL and being able to use libraries that have been built for Full .NET ( and internally could use unsupported features in .NET Standard 2.0 / type unification).

PabloAlarcon on 8 May 2017

I guess this decision has no impact on easing the migration to ASP.NET Core 2.0 from ASP.NET 4?
Quite a few applications I manage could really profit from an update to ASP.NET Core 2.0, but since there is no OWIN/Katana Support for ASP.NET Core I guess I need to migrate manually and that is atm too much work. @damianh suggested similar in https://github.com/aspnet/AspNetKatana/issues/27

Tornhoof on 8 May 2017

We are running on the full framework because we need EF6 (for spatial) and directory services and we are waiting on SignalR proper (currently using an unsupported version but it works). I havent checked any other blockers in a while but probably there are more.

As i understand it we'll now be blocked from moving to asp.net core 2.0 and getting signalr when it comes out.

We've been along for the ride since dnx, RC1 to RC2 and project json to csproj and finally it felt like we were out of the woods... now not so much.

I can understand this change coming eventually but is this really the time to do it when asp.net core is trying to gain traction? Also, my gut tells me EF Core isnt mature enough yet (and certainly not for spatial) and anyone betting on support in core is taking on more risk with regards to porting of libs.... waiting out another version for this transition seems like it would give some stability and a chance for EF Core and other ports to catch up not to mention signal r on the full framework.

I bet most of the enterprise is running asp.net core (which is great by the way) on the full framework and could well be in a similar position to us.

douglaswaights on 8 May 2017

👍5

Given this move to the fast train for ASP.NET Core, does that mean you'll introduce an LTS and Current version, and what will the support length be on this instances?

I guess I'm in the lucky instance where I am working on a greenfield solution that has had no requirements to run on netfx, _but_ it was always a nice to have if it could. The only thing that would be a blocker for me would be windows services which I am targeting netfx, but there is a plan for that.

Antaris on 8 May 2017

I feel this change is going in the wrong direction. I understand some features are core exclusive until netstandard catches up. But going this core-only route is a slippery slope into creating a fractured ecosystem.

This change makes a statement that I'm not sure I like: It's OK to only target netcoreapp.

hallatore on 8 May 2017

I also wanted to write my opinion.

I believe that it's too early to drop .net framework. I don't know what's the problem of supporting .net framework + .net core together, but I believe this decision will make to migrate to AspNet Core a little harder. Because some companies think that: "Let's start AspNet Core with .net core.. if we have serious problems (like a must-need library does not support it in the future) we can always turn back to .net framework". But now that will not be possible anymore and companies will hesitate to start with AspNet Core. Also, this decision may make lower the value of .netstandard.

hikalkan on 8 May 2017

@hikalkan

Because some companies think that: "Let's start AspNet Core with .net core.. if we have serious problems (like a must-need library does not support it in the future) we can always turn back to .net framework".

You can always use ASP.NET Core 1.1 though right?

Also, this decision may make lower the value of .netstandard.

I don't see why that would be the case. As I said before, our cross cutting libraries still target .NET Standard as well as APIs that need to work across all of the .NET implementations.

davidfowl on 8 May 2017

Sure, they can use asp.net core 1.1. But it's not nice to say: "ASP.NET Core's latest version is 2.x but you should use ASP.NET Core 1.x if you want to target .net framework". That's not much different than saying "use MVC 5.x" :)

I believe .net core is the future (not future, even it's now!), but it's eary to drop .net framework (this decision will be understood by the community like .net framework is being obsolete).

hikalkan on 8 May 2017

👍1

You can always use ASP.NET Core 1.1 though right?

there is not a clear benefit. First it is not mature yet, so it is a bet.
Second, developers in ASP.Net Core will not want to write in old tools and stay behind.
I am interested about few things.

We work already in greenfield project fully in ASP.Net Core, Dapper, etc.
But in other projects, our business logic is in 4.6 assemblies. As I did read above, we should not have problem to reference them. I hope, I understood well about.
SignalR . DirectoryServices, MS Orleans, Azure.
maybe irrelevant with the conversation above, but I want madly to host locally an ASP.Net Core with Kestrel or other HttpListener as a UWP desktop application or as desktop bridge in UWP.

stefan2410 on 8 May 2017

Gotta say I'm pretty disappointed on the communication on this. I think we can live with the decision but it came out of no-where.

In July my team is starting work on a greenfield 12-18 month project that's going to run on ASP.NET Core 2.0 with all the cool stuff that we've been reading about for years in .NET Core.

However in the mean-time we've got a ASP.NET MVC Core 1.0 app that is the center of our legacy product that essentially serves as a wrapper to call .NET Framework libraries.

I confirmed with the team that their plan was to upgrade the app to ASP.NET MVC Core 2.0 and have it become part of the new app as we swap out the .NET Framework components. Now we're stuck with ASP.NET MVC Core 1.0 which will be EOL'ed before we finish the project.

DamienDennehy on 8 May 2017

Just before I run my opinion, I would just like clarity on one part.
Would I be correct in making the assumption that if we want to continue using ASP.NET Core,
we will not be able to reference dll's that target .Net 4.5 or greater and have them work as they currently do?

louislewis2 on 8 May 2017

@louislewis2 No, that's not correct. You will be able to use net45-net461 libraries, so long as they stay within the supported API space for netstandard2.0. You will not need to recompile those libraries.

bradwilson on 8 May 2017

@bradwilson Thanks for the clarification. That will surely make me sleep better tonight.
Many of the libraries are not in our control, so that would have been a huge issue.

Very relieved now :)

louislewis2 on 8 May 2017

@shanselman @DamianEdwards @davidfowl For your list of items that we use which have not yet been ported, would be items in the system.management dll. We make use of the hardware identifiers specifically , this is used for automatic link generation for Azure Service Bus and our entire licensing server and client package. I imagine that with them not being the api currently, would cause us some serious issues?

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

This is our biggest holdup that keeps us running a few of our apps on the full framework.

louislewis2 on 8 May 2017

This puts us in an awkward situation.

I'm in the middle of porting our microservices from ASP.Net 4.5 self-hosted in-process on top of Kestrel (legacy compat reasons), to full self-hosted ASP.Net Core 1.x. However, we need to run these things on full framework, for now. And there are good reasons for that.

We have a number of hard Windows dependencies that are already part of our infrastructure and aren't subject to change. That includes NTLM auth, Event Log logging, etc. If ASP.Net Core 2.x are bailing out of netstandard support, then I may as well not do it at all. The problem is, there isn't any actively developed full framework alternative. Katana is dead and slow (by comparison).

If somebody could point me to a HTTP server that's as fast as Kestrel for .Net Framework, then sure. But that doesn't exist. So I just have to accept that ASP.Net is leaving actual production customers like me behind with this change.

If the stack needs all the new goodies, like Pipelines and Span, then those should be provided as netstandard libs. What APIs is ASP.Net Core 2.x using that are in netcoreapp2.0 that aren't in netstandard2.0, and why can't those APIs be made netstandard2.0 extension libs in the meantime?

mattnischan on 8 May 2017

👍2

Are we seriously saying that MS spent 2 years working on a (net) standard across all of their frameworks only to turn around and release a flagship product that doesn't use this standard?

DamienDennehy on 9 May 2017

😄10 👍3 👎1

I think that GitHub Team will add Pagination feature for issues section because of this issue.

ikourfaln on 9 May 2017

👍7

@mattnischan

I'm in the middle of porting our microservices from ASP.Net 4.5 self-hosted in-process on top of Kestrel (legacy compat reasons), to full self-hosted ASP.Net Core 1.x. However, we need to run these things on full framework, for now. And there are good reasons for that.

You can keep using ASP.NET Core 1.x right?

If the stack needs all the new goodies, like Pipelines and Span, then those should be provided as netstandard libs. What APIs is ASP.Net Core 2.x using that are in netcoreapp2.0 that aren't in netstandard2.0, and why can't those APIs be made netstandard2.0 extension libs in the meantime?

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

davidfowl on 9 May 2017

@stefan2410

You can use ASP.NET Core 1.x for that right? Which ASP.NET Core 2.0 features do you need? Is it just SignalR?

davidfowl on 9 May 2017

Keep the app as is for the next two years but swap out the .NET Framework libraries with their .NET Core equivalent when done. This would keep our business logic etc shared between the two apps.
We can't do this as July 2018 is the deadline for ASP.NET MVC Core 1.0 support.

Once again, in my hypothetical world, we extend the lifetime of 1.x

Upgrade the app to ASP.NET MVC Core 2.0 and have it become part of the new app as we swap out the .NET Framework components.
We can't do this either, as Core 2.0 doesn't support the .NET Framework so it's all or nothing.

Do you actually need ASP.NET Core 2.0? Or just .NET Core 2.0?

davidfowl on 9 May 2017

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

Our plan was: wait until they are in it. You said earlier that's just a matter of time, right? Lagging the bleeding edge by some fixed amount for the sake of stability would've been fine. Much better than falling permanently behind, at least.

gulbanana on 9 May 2017

@davidfowl
I will move in ASP.Net core 2.0. I don't have other solution. I can't say to the team to stay behind the evolution, we waited long time the ASP.Net Core.
As far as we don't have problems with our business logic 4.6 assemblies references.
I need SignalR, DirectoryServices, not problems with Azure/Amazon libraries, MS Orleans.
Also maybe it is irrelevant with the conversation above, but I want for a desktop app to host locally an ASP.Net Core with Kestrel / HttpListener as a UWP desktop application or as desktop bridge in UWP.
We can't rewrite the code for XAML and I would not like to use Electron.

stefan2410 on 9 May 2017

You can keep using ASP.NET Core 1.x right?

For what timeframe? I can't see something like Event Log making it to netstandard.

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

Is this a thing? netstandard20 appears to still run on net461 according to the docs. Are you saying that the API under netstandard20 is not complete enough to implement the new goodies? Or, is there some plan to move netstandard beyond framework that is not yet divulged?

mattnischan on 9 May 2017

Our plan was: wait until they are in it. You said earlier that's just a matter of time, right? Lagging the bleeding edge by some fixed amount for the sake of stability would've been fine. Much better than falling permanently behind, at least.

Libraries can be written on top of the standard. When things in the standard itself need to change it will take a lot longer to be adopted in all implementations of .NET and that includes .NET Framework. It can mean a couple of things:

.NET Standard will evolve at the rate of the slowest implementation
.NET Standard will evolve at some other pace and .NET Framework will be the last to catch up.

Of course it doesn't mean that libraries can't be written against it, it just means those caveats need to be taken into consideration when picking the version of .NET Standard you want to support.

davidfowl on 9 May 2017

👍1

Also maybe it is irrelevant with the conversation above, but I want for a desktop app to host locally an ASP.Net Core with Kestrel / HttpListener as a UWP desktop application or as desktop bridge in UWP.

ASP.NET Core on UWP isn't currently on any roadmap so I can't really say what's going to happen here. HttpListener is part of .NET Standard 2.0 though so maybe there's a chance that will work.

davidfowl on 9 May 2017

I want to take a moment to thank everybody for their comments and feedback here. We really do appreciate it as well as your patience while we figure out the path forward. Please know that we didn't intend for this change to be so hard, so late, and without warning. Hindsight is 20/20 and if we knew what we knew now we would have communicated things earlier. We'll try harder moving forward.

We have a plan based on the feedback we've received here that I want to share with you before we post it as an announcement later this week with the 2.0.0-preview1 release. When that happens, we'll open a new issue to facilitate discussion around that plan, but for now go ahead and continue to share your thoughts and feedback here:

Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)
The new SignalR will target and be fully supported on ASP.NET Core 1.x (coming later this year)
We’ll continue to update ASP.NET Core 1.x to support new language versions, etc. like we do for System.Web
ASP.NET Core 1.x running on .NET Core 1.x will be supported until July 2018 (no change)
ASP.NET Core 1.x running on .NET Core 2+ will be supported as long as ASP.NET Core 1.x on .NET Framework is supported
- This is to ensure there is always an overlap of a supported ASP.NET Core on a supported .NET Core while we support running on .NET Framework, allowing customers to port over time while staying on supported bits
.NET Core 1.x support (as a runtime) doesn’t change. Ends in July 2018. Customers running ASP.NET Core 1.x need to move to .NET Core 2.0 or be on .NET Framework at that point (or move to ASP.NET Core 2.0 on .NET Core 2.0)
We will port System.DirectoryServices and System.Drawing to .NET Core this year (fully supported, cross-platform, preview for at least Windows in Summer)
The list of things to port to .NET Core after that currently includes ServiceBase (to support .NET Core Windows Services). No timeline yet other than it’s next (timelines obviously get more concrete as we work down the list). We’ll build on this list as we go based on customer feedback.
We have no plan currently to port System.ServiceModel (server-side WCF) to .NET Core. The WCF for .NET Core may continue to be enhanced and have features added based on feedback, e.g. HTTP message encryption.

DamianEdwards on 9 May 2017

👍31 😕3 👎1

@DamianEdwards @davidfowl a large part of the issue is that it can takes months of planning and dev effort whilst sacrificing a huge opportunity cost to commit to moving to ASP.NET Core where a lot of organizations wont to be able to move off from on .NET 4.x as it's the only platform they can be assured will be able to run all of their systems dependencies.

Up to this point MS has been marketing .NET Core aggressively as the future of ASP.NET where it's unclear whether development of ASP.NET 4.x has halted and if all future dev efforts are going to be invested in ASP.NET Core so there are going to be a lot of migrations underway to keep their systems current. A lot of people are going to feel like they've been thrown under a bus if that at the end result of all their efforts they've effectively migrated to an EOL'ed platform. This will hurt both organizations as well as the devs/consultants that were the biggest champions for initiating the move to .NET Core. They may not need anything from ASP.NET Core 2.0 now but they're definitely going to want have some headroom for their systems and be able to access some new features for all their efforts.

I also don't get why existing "legacy" code is considered a liability when IMO it should be considered one of .NET's greatest assets, .NET Core would be nowhere near as appealing if it wasn't able to run existing .NET libraries. Java is still so strong because of JVM's massive and stable ecosystem which is more important than the inherent weakness in the language itself.

I don't think MS has even begun to feel the backlash from dropping .NET 4.x support which wont be broadly known until it's announced, I'd expect most devs here actively following development on GitHub are more interested in seeing new features then they are in interoperability and ensuring there's a smooth migration path for existing code bases. I'd be very surprised, but if you don't get any heat from this decision after it's announced than it might be the right one as maybe there aren't going to be that many people hurt by it.

Would it be too much effort to focus on a ASP.NET Core 2.0 stable/compatible release, then announce the .NET Core-only future for subsequent versions? Just seems like it's the fair thing to do in this situation given it was completely unforeseen.

mythz on 9 May 2017

👍20

@DamianEdwards thanks for the update and a clear plan. I don't agree with it, but I still appreciate you laying it out.

There's still a huge fundamental gap here. The port to 1.x is almost entirely a lateral one, there are few features in it for us. 2.x is where some worthwhile upgrades are and we still have no guarantee we can ever make that move. There's a large chance that we spend a significant amount of time, money, and effort porting to 1.x only to be stranded there because of full framework dependencies. I will not make that gamble with our company. We may well end up with less support than we have on ASP.NET 4.x now.

Unless that changes, our apps will not be making the trip to ASP.NET Core, and all of our libraries will be far worse off for lack of dogfooding on it.

I sincerely hope you reconsider this decision. I hope one day we can make Stack Overflow take advantage of the thousands of personal hours we have devoted to help develop the .NET Core platform.

NickCraver on 9 May 2017

👍32

@NickCraver

There's a large chance that we spend a significant amount of time, money, and effort porting to 1.x only to be stranded there because of full framework dependencies.

Throughout this thread, you called out System.DirectoryServices as one of the core things. I assume you have some dependencies that you think will take a long time to get ported or ones that will never get ported. If 2.0 supported .NET Framework would those dependencies move in a year?

2.x is where some worthwhile upgrades are and we still have no guarantee we can ever make that move.

Which ones? It would be good to know because we were discussing back porting some high importance things back to ASP.NET Core 1.1 to ease the transition.

Unless that changes, our apps will not be making the trip to ASP.NET Core, and all of our libraries will be far worse off for lack of dogfooding on it.

I don't know anything about stackoverflow.com but is it possible to break pieces off (I don't want to say "micro services") so that ASP.NET Core could be used for some parts?

davidfowl on 9 May 2017

@mythz

This will hurt both organizations as well as the devs/consultants that were the biggest champions for initiating the move to .NET Core

Did you mean ASP.NET Core? Or .NET Core?

davidfowl on 9 May 2017

@davidfowl I meant ASP.NET Core, but it also affects devs who were planning on a staged migration from ASP.NET Core/.NET 4.x first then .NET Core later.

mythz on 9 May 2017

Speaking of which, I've noticed that there's no libraries on ASP.NET Core/.NET Core for handling SAML. I have a requirement to handle SSO via a third party IdP, but I don't know if that'll be possible.

snickler on 9 May 2017

@davidfowl I meant ASP.NET Core, but it also affects devs who plan on a staged migration from ASP.NET Core .NET 4.x first then .NET Core later.

I don't see why that would be the case.

davidfowl on 9 May 2017

I think that plan would probably be juuust enough for my org to avoid moving off the platform. The main thing is having a longer period with support (=security patches) during which remaining netfx deps can be rewritten or otherwise eliminated. It's all still kind of dicey and conceptually weird, though. What happens if three years from now we want to build a website which can ingest Excel documents or to embed a webserver in an app? What happens to other frameworks like Orleans building on top of the standard instead of netcoreapp?

I seriously do not understand why so much work was done on netstandard2.0 if it wasn't ever going to be good enough for ASP.NET Core to actually use it.

gulbanana on 9 May 2017

👍2

What happens if three years from now we want to build a website which can ingest Excel documents

Hard to say. I can't speak for the teams that own that but maybe it'll get ported to .NET Core and will work cross platform.

or to embed a webserver in an app?

HttpListener is part of netstandard 2.0.

What happens to other frameworks like Orleans building on top of the standard instead of netcoreapp?

It's up to frameworks to decide if they want to run on .NET Framework, UWP, .NET Core, mono etc. It's a choice. Orleans doesn't ship with .NET Core. ASP.NET Core does. Those products are one and the same.

davidfowl on 9 May 2017

What'll be a tough decision for us (and our clients) isn't about the libraries I have today, but the libraries I don't know if I'll need 6 months from now. There's a long tail of libraries and frameworks that don't support netstandard yet. For example, a month in to a project we realized that we needed a few features in NHibernate that weren't even close to there in EF6, let alone EF Core. So what would be my option there - target ASP.NET Core 1.x on full .NET?

Looks like I have some ApiPort in my future.

jbogard on 9 May 2017

👍7

So what would be my option there - target ASP.NET Core 1.x on full .NET?

Yes.

davidfowl on 9 May 2017

Hard to say. I can't speak for the teams that own that but maybe it'll get ported to .NET Core and will work cross platform.

Right, but surely it's within the purview of the asp.net team to decide whether it's worth providing access to that ecosystem of maybe-not-ported libraries.

gulbanana on 9 May 2017

Right, but surely it's within the purview of the asp.net team to decide whether it's worth providing access to that ecosystem of maybe-not-ported libraries.

.NET is big and old, there's no way you can't expect the ASP.NET team to speak to the breath of libraries that exist in the .NET ecosystem. It's unrealistic. I just learnt what CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) was as part of this thread and I doubt it'll be ported but I couldn't say that for sure.

Extending support for ASP.NET 1.1 on .NET Framework helps mitigate this a bit but I think it also helps because some dependencies will need to be isolated to properly move to ASP.NET Core on .NET Core (which is the intended future).

davidfowl on 9 May 2017

I will leave aside the libraries as that point has been discussed at length already. In our case (amilia.com, e-commerce SaaS) the third party tooling is already a showstopper, we can't even run ASP.NET Core on the full framework at the time being. I acknowledge this doesn't sound like a legitimate reason, but its a constraint we have to deal with.

We could, in theory, replace those tools (i.e. profilers, monitoring, build servers, etc) with alternatives supporting .NET Core but that's a couple months of work I'd rather spend on solving more pressing issues. We'll make the migration eventually to ASP.NET Core/.NET Core, but right now it's quite a moving target.

plmaheu on 9 May 2017

Up until this point the expectation was created that ASP.NET Core would be able to keep running on desktop framework, and thus speak to the breadth of etc etc. I don't know what kind of tea leaves we were supposed to read to know that that was unrealistic :/

Like, to be clear: the idea that ASP.NET Core might only run on .NET Core is not crazy itself, but we never heard a peep of it before. All public information was that it ran fine on .NET Framework and there was no indication that this might have to change.

gulbanana on 9 May 2017

👍3

.NET is big and old, there's no way you can expect the ASP.NET team to speak to the breath of libraries that exist in the .NET ecosystem. It's unrealistic

Isn't that a good reason to keep supporting .NET 4.x? The burden of compatibility/interoperability can be contained to .NET 4.x platform which can be a working solution that could relieve .NET Core from needing to interoperate with older libs and relieve pressure to port existing popular .NET libraries to .NET Core (for MS and external authors).

mythz on 9 May 2017

👍1

@mythz

Isn't that a good reason to keep supporting .NET 4.x? The burden of compatibility/interoperability can be contained to .NET 4.x platform which can be a working solution that could relieve .NET Core from needing to interoperate with older libs and relieve pressure to port existing popular .NET libraries to .NET Core (for MS and external authors).

That's why ASP.NET Core on 1.1 's lifetime has been extended (though not permanently). We're going to make sure that SignalR works because that was stated as one major reason for using ASP.NET Core 2.0. At the same time, it's not where ASP.NET Core wants to be in the long run. The intent was always to ship as part of a unified .NET Core platform.

@gulbanana

Up until this point the expectation was created that ASP.NET Core would be able to keep running on desktop framework, and thus speak to the breadth of etc etc. I don't know what kind of tea leaves we were supposed to read to know that that was unrealistic :/

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

davidfowl on 9 May 2017

That's why ASP.NET Core on 1.1 's lifetime has been extended (though not permanently).

The issue is whether or not that's enough, the current version has basically been EOL'ed before a compatible/stable release has even been delivered.

I don't believe the value of existing investments is being considered, who is going to want to go through all the effort to migrate to an EOL platform? Devs will be working on their existing brownfield systems indefinitely, they're basically being told their current ASP.NET v4.x skills are going to become obsolete and they're not able to migrate to the new ASP.NET Core development model because .NET 4.x support is being dropped and it would be irresponsible for them to consider or recommend migrating to a dead-end platform.

mythz on 9 May 2017

👍1

@davidfowl

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

Mistakes happen, that's fine. The problem now is that many people made this assumption and so are only using ASP.NET Core because of their logical but erroneous conclusion. We'll see just how many, I guess :/

gulbanana on 9 May 2017

I waiting asp.net core 2/ .net core 2 so long, but the result is so depressed.

xyting on 9 May 2017

@mythz

I don't believe the value of existing investments is being considered, who is going to want to go through all the effort to migrate to an EOL platform?

Can't the same argument be made about ASP.NET Core 2.0 being EOL on .NET Framework next year when 3.0 comes out? If you're saying a year isn't enough on ASP.NET Core 1.1 why would you suggest a year is ok on ASP.NET Core 2.0?

Devs will be working on their existing brownfield systems indefinitely, they're basically being told their current ASP.NET v4.x skills are going to become obsolete and they're not able to migrate to the new ASP.NET Core development model because .NET 4.x support is being dropped and it would be irresponsible for them to consider or recommend migrating to a dead-end platform.

Who got told that ASP.NET 4.x skills are going to become obsolete? If anything we're hoping they aren't. MVC in particular touts concept compatibility with a few new features. ASP.NET Core looks a lot like Katana (and that's not by mistake). If you're talking about Web Forms then what about MVC ?

I don't have any experience consulting but I would agree that if the dependencies aren't available then I would agree. Either that or the application needs to be re-designed to take this into account.

davidfowl on 9 May 2017

@xyting can you clarify?

davidfowl on 9 May 2017

@davidfowl

Can't the same argument be made about ASP.NET Core 2.0 being EOL on .NET Framework next year when 3.0 comes out? If you're saying a year isn't enough on ASP.NET Core 1.1 why would you suggest a year is ok on ASP.NET Core 2.0?

I was under the long-time assumption that ASP.NET Core 1.1 was just a stop-gap solution to ASP.NET Core 2.0 and .NET Standard 2.0 which would be the compatibility focused and stable LTS release that will bridge the gap with most of the core functionality missing from .NET 4.x - up until this thread basically destroyed that assumption. Keeping .NET 4.x compatibility up to ASP.NET Core 2.0 isn't ideal, but it's a lot better than terminating it at the current release which no-one expected.

Who got told that ASP.NET 4.x skills are going to become obsolete? If anything we're hoping they aren't.

MS does with all their aggressive marketing on .NET Core with all new announcements and features seemingly being ASP.NET Core focused. Is old ASP.NET WebForms/MVC even being developed in the open? What proportion of dev effort is being invested on old ASP.NET WebForms/MVC vs .NET Core? I've no idea, everything I've seen recently, all weekly standups, video tutorials seems solely focused on ASP.NET Core. I know I definitely wouldn't feel comfortable starting new greenfield projects using old ASP.NET WebForms or MVC technology.

If you're hoping they aren't MS should definitely communicate that better with clear roadmaps. Given how volatile ASP.NET has been in the last few years (this issue being a perfect example), it's impossible to know what the future is without an official commitment and announcement.

mythz on 9 May 2017

👍5

Does anyone else feel that it would have been better if version 1 never ran on full framework? I didn't expect it to because of the naming. Now that it does and I've had a taste I'm disappointed to lose it.

I do get where you're coming from on this, you want to iterate the whole stack as fast as possible. You're competing with a whole bunch of green fields web frameworks that control the whole stack and have no baggage to drag along. Hell dropping the baggage of System.Web is one of the main reasons ASP.NET Core is so exciting.

Having slept on it I can say our usage will be fine, the dependencies we need should all work on 2.0.

jkells on 9 May 2017

👍9

At the same time, it's not where ASP.NET Core wants to be in the long run. The intent was always to ship as part of a unified .NET Core platform.

While it doesn't take a psychic to figure out that .NET Core is the platform of .NET's future... if the intent from the beginning (or as you put it "always") was to couple ASP.NET Core with .NET core, that was definitely not communicated in any medium I've ever seen.

I've literally seen every single minute of every single ASP.NET standup (including Hanselman and Glenn troubleshooting Docker for 3 hours... because I have no life), I read the blogs, I'm always on Twitter, I go to 2+ conferences a year, attend user groups, etc. and I've never once heard that communicated as the intent of ASP.NET Core. Instead, I've heard over and over and over "it runs on both platforms" and, rightfully, people feel like someone pulled the chair out from under them. I've even given talks about ASP.NET Core and said "it runs on both platforms" myself, and now I feel guilty for anyone I've led down this path. I would say the people ITT are likely to be on the bleeding edge and would be the most accepting of this kind of news, and there's a lot of backlash here. This seems like it's only going to get worse as this news trickles down to the developers and their managers who aren't as plugged in, and are likely more conservative than those ITT.

Besides the lack of communication and the lack of support for some scenarios, I think a lot of the backlash is just due to the timing of this announcement. .NET Core 2 isn't even RTM'd yet and it's already been deemed the only long term path forward, and there's essentially been a ticking time bomb put on Full Framework for ASP.NET Core. I think a lot of our fears could be cleared up once we have something tangible to play with besides nightlies.

I really do think there needs to be a better tooling experience than "run it and see if it works" when referencing net461+ libs from .NET Core 2+ in VS, because I can already see that message of "we can likely run most of your 461+ assemblies too!" will be marketed to death. Something that could analyze missing API's of what we referenced, providing compile-time errors, ideally even suggesting compat nupkgs if they exist (like System.Configuration in the EF6 example above... and have it work :smile:). Obviously, not everything can be analyzed at compile time (the distributed transaction scenario mentioned above comes to mind as something tough to anlayze ahead of time), but the more that can the better. Something kind of like what Immo did here for PlatformNotSupportedException and the missing net461 APIs for netstandard2 would be nice.

Just my 2 cents. I hope I'm just overreacting. Ultimately, a lot of us are just disappointed, because we love ASP.NET Core, and we don't want anything standing in our way of using it. ❤️

scottsauber on 9 May 2017

👍48 😄1

Joining my voice to the concerns already listed, we are starting a new ASP.NET MVC project next month and it will be plain .NET Framework with ASP.NET MVC, because the customer doesn't trust Microsoft doing the right thing in regards to long term planning.

The customer organization is still using Windows 7 deployments and this project is an exception, because the majority of their web projects is actually done on UNIX with Java, with .NET being mostly used on desktop applications.

This type of uncertainty just piles up to the broken history that Windows 8 .NET stack and UWP were, increasing the interest of the organization CTO to look for more stable alternatives to .NET future.

If you are forcing these type of organizations to write modules from scratch to work on ASP.NET Core, I can as well advise our customers to adopt something with more stable roadmaps,instead of losing face about issues I cannot control.

pjmlp on 9 May 2017

@davidfowl It might be that this change will work fine for 99% of the projects. But it was sold as "it runs on both platforms" and "you can use it with full framework if you have to". Everyone knew that the full framework version of asp.net core was for the projects that could't migrate, and that was fine. And people planned with that in mind.

This change might not be the worst in terms of code, but it will most likely create a huge shit storm when the more regular developers see the news. And it will not be about the code, it will about what was promised. And the promise was "run net or core, and netstandard to combine them all".

hallatore on 9 May 2017

👍3

@DamianEdwards @davidfowl Thanks for sharing the plan.

SignalR on 1.x is a big relief to replace our unsupported version and also the news that ServiceBase is next on the list next as we are currently using that also!

We are heavily reliant on EF6 and spatial though so we'll be stuck on 1.x until that has the feature set we need....

On a semi-amusing side note however, this may finally force a more microservice deployment for this. I wont be looking forward to explaining why our LOB customers need to have several more api's installed on IIS to just to get our products working though....

I really wish this could be held back as just seems to be too soon and as several people have mentioned this will generate a significant backlash when the blog post drops.

Also i must say i feel a bit sold-down-the-river when from the start the sentiment has been this will run on the full framework and have been preaching the same thing to colleagues. Explains the confusing naming choice of asp.net core though.

douglaswaights on 9 May 2017

@shanselman @davidfowl My biggest pain point is NHibernate. Even after the EF Core release, it's still the only most advanced full featured O/R mapper.

fubar-coder on 9 May 2017

@shanselman @DamianEdwards I am in the process starting to think about upgrading a site from ASP.NET MVC 4 to whatever the latest version is (I'm confused whether it's 5 or one). I still need to run the full .net framework because I am referencing both SyncFusion and Telerik libraries. SyncFusion to display PDF files and Telerik to generate word .docx files. As others have pointed out it's simply not reasonable for Microsoft's strategy for dealing with this to be "try it and see if it works". I can't guarantee that and production everything is going to work because it is such a large code base of third-party code.

While SyncFusion support is generally very good Telerik's support is not and I'd be surprised if they can make it work with .net core. I have no idea what Apis they might be using that are not supported in .net core - and as an end user that's the whole point of the third-party product, I just plug it in and it does what it needs to do.

Frankly for a customer who doesn't deal in the stuff very frequently (I mostly do WPF) this is all extraordinarily confusing. There are too many different versions, with various incompatibilities. As someone has pointed out it's a bit like UWP XAML - simliar but completely incompatible with WPF XAML.

Not good for developers and just another thing that causes developers to lose trust in Microsoft (one of many over the last few years). It would seem to me that ASP.NET should definitely run on the full .net framework, because there is such a big library of tools that people may need to use on their server. In my case I can easily update to a later version of the .net framework if I need to in order to use latest ASP.net stuff if an update was required for the new ASP.net functionality.

Whatever messaging goes to developers needs to be much clearer, before people just jump ship completely.

...Stefan

stefanolson on 9 May 2017

👍5 ❤1

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

I personally don't have a problem with the changes listed in this issue, I understand the reasoning and they make sense, now that I've read through a lot of responses here. However, what you've just said highlights what's ultimately the crux of the issue - poor communication from Microsoft as a whole (Which I appreciate is not your, or any _specific_ individual's fault).

Maybe I'm missing something, but there's more to "developing in the open" than just having the code on github for everyone to poke through and play with. This very issue was created because a change appeared in the code one day that took people by surprise, but obviously yourself and everyone on the .net team knew about it and understood it - so it was a long time coming. The problem is that the rest of us mere mortals were completely blind-sided by it.

Worse still, I suspect the majority of developers don't pay too much attention to github to get their knowledge and information - so this change is going to surprise a lot more people than are already commenting here. I only discovered this issue myself because it appeared on my RSS feed of hackernews - which is not what I'd call my top source for news and information.

Anyone following along from the blog posts on MSDN will know that 2.0 is coming and they'll see it as the holy grail of bridging the gap between asp.net core and everything it was "missing" previously, but they're completely unaware of what is essentially a breaking change for certain workflows. There's been very little details on what's really happening with the design of asp.net core 2.0. I suspect more details will come later this week at Build? One can only hope.

The .net slack is another resource for information, but it's a little bit noisy to be kept up to date with what's really going on. It's great for developer involvement and asking questions, but it's hardly a news source.

Twitter and social media is another source of information, but again a bit like this github issue by the time it appears there, it's usually because someone has raised concerns with a decision that's already been made and caught people by surprise.

This isn't the first time we've had this exact problem, either. Remember the fiasco caused by changing back to csproj? I don't want to get into the debates over that change, but it's another example of a change that happened to people's surprise, that was so poorly communicated that to this day, many people simply don't realise that it's not the same csproj from the "bad old days".

I'm not completely sure what I'm trying to suggest here, but there is definitely something "missing" from the open development of .net. Microsoft does a great job of providing resources and documentation for developers, but only for finished products and things that have shipped. The roadmap, the planning meetings, everything that gets to decide the design and direction of the frameworks seems to be done behind closed doors, with the occasional mention of "select partners" and the like. I'm not saying that every meeting should be streamed and broadcast worldwide, but there could definitely be a better middle-ground whereby decisions that are made and the rationales behind them are communicated as early as possible to the community, in a way that's easy for those of us who really _want_ to follow along to digest and keep on top of. Perhaps a dedicated blog on MSDN (or elsewhere) that's updated regularly when those decisions are made.

neoKushan on 9 May 2017

👍11

One of my biggest issues with this is that on almost every conference the last year that ASP.NET Core has been presented, you have presented it with a slide that shows asp.net core running on both .net framework and .net core, just have a look at this: Explore web development with Microsoft ASP.NET Core 1.0 from Ignite last year. At about 7.50, you will see the slide.

The biggest showstoppers for me are System.DirectoryServices, ServiceBase, EF6 (EF Core is not ready), ClosedXML (for creating excel sheets).

Sjark on 9 May 2017

👍1

Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)

@DamianEdwards Thank you for the announcement.

At the moment our company is developing enterprise applications for several clients using ASP.NET Core 1.1 on .NET Framework 4.6.2. Hearing that the support for that framework combo is supported until at least 2019, and possibly extended 2020 is a huge relief.

We will port System.DirectoryServices and System.Drawing to .NET Core this year (fully supported, cross-platform, preview for at least Windows in Summer)

These are the two only reasons we're targeting .NET Framework right now. If these are fully ported to the .NET Core 2, I'm sure that we can port our applications to ASP.NET Core 2 safely next year.

ryanelian on 9 May 2017

👍1

Seems like alot of ppl have broken the cardinal rule of being a MS developer - dont commit to any product/fork until atleast the V2.

but yeh, talk about alienating your enterprise clients! the whole reason they use MS is for backwards compatibility.

The majority of ppl who run ASP.NET do NOT CARE if it runs on linux. And if they saw a blog post, with a speed comparision with ASPNET Core, they wouldnt even both reading past cross-platform if they saw it didnt support legacy .NET.

lolcats.

captainjono on 9 May 2017

👍4

I think there is value in having ASP.NET Core 2.0 fully run on net46x for the sake of giving lots of folks a smooth migration path to the new world. I think many people were waiting for ASP.NET Core 2.0 and .NET Core 2.0 with the hope that it will close many of today's gaps and allow a migration. If ASP.NET Core 2.0 will require everything to be ported to netcoreapp2.0, then it will be a massive slowdown for teams and perhaps even jeopardise feasibility.

However, that doesn't mean that there cannot be an ASP.NET Core 3.0 shortly after which will only target netcoreapp2.0 for all the people who work on all the new shiny greenfield stuff and want to be on the fast track.

Having two versions of ASP.NET Core (2.0 and 3.0) side by side could really be a good thing (for at least a while). That could allow MSFT to quicker phase out the current MVC 5 stack, because the new version of MVC would essentailly be ASP.NET Core MVC 2.0, which would run on full .NET as well.

dustinmoris on 9 May 2017

👍4

I think there is value in having ASP.NET Core 2.0 fully run on net46x for the sake of giving lots of folks a smooth migration path to the new world

What would make it smoother than porting from ASP.NET Core 1.x?

I think many people were waiting for ASP.NET Core 2.0 and .NET Core 2.0 with the hope that it will close many of today's gaps and allow a migration.

The bulk of the work done to make things compatible was done in .NET Core 2.0 and .NET Standard 2.0. ASP.NET Core 2.0 honestly doesn't have that many new features. We're said we're going to backport SignalR to ASP.NET Core 1.x (which is post 2.0 anyways). Is it just a perception thing?

Having two versions of ASP.NET Core (2.0 and 3.0) side by side could really be a good thing.

This is what we're doing with 1.1 and 2.0 (just flip the numbers).

That could allow MSFT to quicker phase out the current MVC 5 stack, because the new version of MVC would essentailly be ASP.NET Core MVC 2.0, which would run on full .NET as well.

MVC 5 will never go away, we don't deprecate anything. It'll be supported as long as .NET Framework exists. You still can't run ASP.NET Core projects inside of the IIS integrated pipeline (on System.Web) and it doesn't do all of the same things as MVC 5 on System.Web so it's really not a replacement for certain scenarios.

davidfowl on 9 May 2017

@davidfowl Will I be able to create an ASP.NET Core 1.x app, which targets full .NET and netcoreapp2.0 so that I can migrate a current legacy app to ASP.NET Core first with all dependencies being net46x and slowly migrate one dependency after another to target netstandard2.0 until everything is on netstandard2.0 which then would allow me to upgrade the ASP.NET Core 1.x app to 2.x (and drop the target for net46x as part of that)?

If yes, then I think I misunderstood the thread. I think this is really what most people are after here.

dustinmoris on 9 May 2017

👍2

@dustinmoris yes you can do that. The main concern people are having is what happens if they don't get migrated to ASP.NET Core 2.x before support ends on ASP.NET Core 1.x, if it is possible for them to migrate at all.

alexwiese on 9 May 2017

👍1

@alexwiese ah ok well that is great, then really what are we discussing here now? Rather than discussing what framework to target we should be discussing the support period of ASP.NET Core 1.x, which is something that MSFT could easily change if they wanted :)

EDIT:
@DamianEdwards wrote this a bit further up in the thread:

Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)

Sounds good to me. Commit to one more year of support and then periodically re-asses. Makes total sense to me.

dustinmoris on 9 May 2017

I've read every post in this thread. Still one question is unanswered: why is this decision made? I can only conclude it was needed due to a technical issue. If 'confusion' of the naming is the issue, Microsoft should hire a better PR person and stop stirring the shit like the team is doing in this thread.

So what is the technical issue that blocked ASP.NET core 2.0 on netstandard2.0? Nothing is impossible in software land, so it can't be you couldn't come up with a solution that isn't doable on .NET full (and thus can't be included in netstandard20). Yes that takes time and effort, but I have the feeling you all didn't really realize the side effects of this decision for your users, what the amount of time / effort they have to invest because of this.

This decision has another downside: ASP.NET Core isn't a consumer of netstandard and therefore isn't a driver of it. It makes the netstandard a follower and as ASP.NET core doesn't depend on it, a follower with little meaning: .net core 2.0+'s API is the surface to target, as ASP.NET core is targeting that surface, not netstandard2.0.

And, sorry @davidfowl, I know you mean well, but suggesting ASP.NET core 1.x to people over and over shows you really have no clue what the situation is for the people you suggest that to: the people can't migrate to ASP.NET core 1.x because they don't know if there is a smooth path off of it without a firm deadline: it might be they need to stay on that platform for longer than they currently think (dependencies needed to be ported etc.). That alone makes the decision to move to ASP.NET core 1.x a decision based on nothing else than a 'promise' from Microsoft. It's an API meant for internet facing code. They need to know whether they can run an app built today also within 3 years time because Microsoft will fix security flaws in it (to give an example).

Frankly, I don't get the urge to start yet another chaos cluster within the .NET ecosystem: we need stability, dependability, reliability: "my code written today will run in 5 years time as-is". yes, I know that sounds silly to some people, but that's reality: there are already more software packages on this planet than there are developers to maintain them and the gap is only widening. You can't simply assume that an organization will decide to use ASP.NET Core as their webstack and hope code written using it will run within 5 years time, organizations don't do that anymore: they know there are stacks out there which are reliable and give them that: they know they might not be able to rewrite the entire app within that timeframe so they need that assurance.

Microsoft has shown with this thread and, sorry, their terrible PR around this issue, they can't give that assurance. And no matter how much spin you try to give that in the coming days at \build, we on the other side of the fence have learned that Microsoft Marketing != assurance things will work tomorrow.

FransBouma on 9 May 2017

👍15 👎4 ❤2

@FransBouma I don't think it was that there was a technical issue, it sounds like the motivation to only target netcoreapp2.0 is because this is the only track that MSFT can move as quickly as they like, which is good for us after all, because it means that ASP.NET Core 2.x can move much faster than any other web stacks in the .NET world before. If you cannot commit to this fast train, then you can stay on ASP.NET Core 1.x for longer (currently supported till 2019)

dustinmoris on 9 May 2017

👍3

@FransBouma as @davidfowl and @shanselman mentioned there are new APIs being added at a fast rate in .NET Core, and ASP.NET Core 2.x will use some of them, therefore the desire to target netcoreapp20. If they were to add these APIs to netstandard2x then .NET Framework and other platforms would have to play catch up, and they are notoriously slow moving.

alexwiese on 9 May 2017

👍2

I'm going to add my voice on the This is a Good Thing side of the debate. Here's why:

The team are not just doing this for the hell of it. There's a whole slew of new features and optimizations ready (or nearly ready) to roll in .NET Core that are incredibly useful to people building modern web applications, APIs and microservices, and waiting for those features to land in the full Windows .NET Framework would delay release by many months.
Many of the complaints I see in this thread are some variation of "I can't do X in .NET Core 2.0" when what the writer actually means is _"I have to change the way I do X in .NET Core 2.0"_. Yes, you have to change. No, that's not a bad thing. If you have a small piece of discrete functionality in your ASP.NET MVC application that does something with PDFs or DOCX files, and you _really_ can't find a better way to do whatever that is (have you tried?), then break that functionality out into a microservice running on full .NET on Windows Server and call it as an HTTP API from your .NET Core application. Decomposing applications and moving specific functionality into small, self-contained services isn't even a workaround, _it's a general-purpose best practice._
- NB As far as I can tell, the OpenXML packages are now supporting .NET Standard, so working with Word/Excel/whatever shouldn't be impossible.
.NET Core 2.0 isn't even in proper public preview yet, so complaining that it hasn't got support for LDAP or whatever seems premature. If RTM comes around in Q3 and there's still no way of interacting with AD or Kerberos or whatever then complain away (although also think about migrating to modern token-based authentication systems because it's not 2008 anymore).
There _is_ a smooth migration from ASP.NET MVC 4.5 to ASP.NET Core 2.0. It's called ASP.NET Core 1.0 (and I agree that there should be some promise of long-term support for 1.0 under the circumstances). You can build apps using 1.0 and run them on Full .NET in an Integrated Pipeline under IIS 8.5 on Windows Server 2012 R2 until
- Full .NET catches up and you can run ASP.NET Core 2.x on it, or
- Whatever third-party tech you depend on supports .NET Core (or can be replaced by equivalent tech that supports .NET Core).
Remember that—while your team might be hamstrung by external dependencies or internal company policies or politics or just plain inertia—there are hundreds of thousands, if not millions, of developers in the world who are looking to build applications, services and APIs using modern architectural patterns and new technology platforms (cloud/edge/IoT/etc), for whom ASP.NET Core 2.0 is a great fit. They want it to be fast, scalable and cross-platform; those things are important to a lot of people. Asking Microsoft to ignore that rapidly-expanding market, just because your 3rd-party control supplier or an open-source project haven't ported their code yet, is silly.

markrendle on 9 May 2017

👍19 👎2 ❤1

@dustinmoris that suggests netstandard lacks the APIs to create a fast webstack. If so, we all have bigger problems.

@alexwiese like I said, I read the complete thread and thus also the posts you refer to. I know what they say and can see their point, but the decision made shows they have no idea what their users are doing with their stuff. I build a product myself, for many years now, and know that after a while you arrive at a point where you want to cut things out and move faster, without the old cruft that is outdated. But doing that has consequences, and one thing I've learned in the past 14 years is that backwards compatibility is one of the biggest features a software product can have: being able to use it and 'it just works' is a key point for many many people to decide for your platform. You might not think it's that important, and that's fine, but there are many many people out there who can't see it that way as their reality is different.

It's not that the asp.net core team shouldn't move fast, it's that they do it in a way that breaks with many people's assumptions when they moved to asp.net core 1.x.

FransBouma on 9 May 2017

👍3

@FransBouma Why do you think you have a better idea of what Microsoft's users are doing with Microsoft's stuff than Microsoft do?

markrendle on 9 May 2017

👍2

@markrendle

The team are not just doing this for the hell of it. There's a whole slew of new features and optimizations ready (or nearly ready) to roll in .NET Core that are incredibly useful to people building modern web applications, APIs and microservices, and waiting for those features to land in the full Windows .NET Framework would delay release by many months.

So, tell me, why not create these super duper APIs as .net standard 2.0 packages and post them on nuget?

Why do you think you have a better idea of what Microsoft's users are doing with Microsoft's stuff than Microsoft do?

Oh I don't know, by reading the posts in this thread?

FransBouma on 9 May 2017

👍5

@FransBouma

that suggests netstandard lacks the APIs to create a fast webstack. If so, we all have bigger problems.

I don't think that netstandard lacks anything, because netstandard is nothing more than a list of features that need to be implemented by a platform that wants to support that standard. In theory we can move netstandard as fast as we like, just add more to the spec, but realistically it is not feasible for all platforms to catch up with those new specs.

So the question is, does ASP.NET Core 2.x want to commit to netstandard2.0 (the currently highest) and then know that it is stuck with everything that has been defined there, or does ASP.NET Core 2.x only commit to netcoreapp2.x, which can be much more than just netstandard2.0. After a while I am sure there will be a newer netstandard again (3.x?) which will catch up with new shiny things from netcoreapp, but that will take much more time and why should ALL asp.net frameworks be crippled to slow progression. It's kind of nice to have one really fast moving ASP.NET Core stack as long as there is also a second that gives people a more long term support which adheres with netstandard.

dustinmoris on 9 May 2017

@FransBouma Oh, sorry, I didn't realise your sample size was so big. 257 comments with a strong bias towards people who don't like the decision? Hard to argue with that.

DISCLAIMER: I am not an expert on Big Data.

markrendle on 9 May 2017

👎5 😄4

@davidfowl:

Throughout this thread, you called out System.DirectoryServices as one of the core things. I assume you have some dependencies that you think will take a long time to get ported or ones that will never get ported. If 2.0 supported .NET Framework would those dependencies move in a year?

Yes, we have other things. System.Directory services is what I point out because even the top requested namespace isn't ready. All others are worse off. The API portability analyzer isn't even updated for VS 2017 where we can run it. The analyzer to see if you can even port hasn't been invested in and we're dropping support already.

Which ones?

Razor pages is a huge one, I've mentioned it several times.

I don't know anything about stackoverflow.com but is it possible to break pieces off (I don't want to say "micro services") so that ASP.NET Core could be used for some parts?

No, this isn't really possible. We don't render in 18ms by making API calls and adding overhead between things. I'm happy to go over architecture anytime, you'd see that isn't really a reasonable route.

NickCraver on 9 May 2017

👍5

I thought I explained this earlier but here it is again:

Any API that is part of netstandard that needs to evolve will evolve slowly. Things can be built on top of netstandard and can run anywhere, and that's fine. The moment you need a new API on say, http client, or SSL Stream, or Int, or String, or Array, or LINQ or any of the primitives that exists in NET Standard a new .NET Standard version must be created and implementations need to agree that they will implement it. Now that's not the end of the world because we own most of them now, mono, .NET Core, .NET Framework, UWP but there are others though like Unity (and probably others). Each .NET vertical has their own time frame and ship cycle, they are each their own separate products and that can't be ignored.

But now you get the idea, a new netstandard version is created when new APIs come online. If libraries want to use these new APIs then you immediately lose the breath of support for all the platforms. You can cross compile and try to polyfill but that doesn't scale for all changes.

Hopefully that gives you an idea of what the process might look like bringing APIs to netstandard. @terrajobst would have a better idea of what the plan is.

davidfowl on 9 May 2017

👍11

@DamianEdwards and @shanselman What about Service Fabric and Unit Tests?

In our case we have a big micro service project with lots of SF applications which are Core projects but use .Net Framework 4.5 up to 4.6.(something). SF currently doesn't not support netcoreapp therefore we had to use .Net Framework but since we didn't want to fall behind we used the .Net Core project.

(another issue is) Because our services are .Net Framework and MS Fakes are not available for netcoreapp all our unit tests are normal (or should I say legacy) .Net Framework projects. Almost all our libraries are on netstandard 1.0 to 1.6.

Again our client apps are using Xamarin Forms + UWP and we managed to use netstandard so our libs are compatible.

Does this mean we are stuck and won't be able to upgrade to .Net Core 2.0 and netcoreapp2.0 and netstandard 2.0?

aboo on 9 May 2017

@NickCraver

Razor pages is a huge one, I've mentioned it several times.

I understand this one but I can't believe that you're going to convert all of stack overflow to razor pages only. If you're already using MVC today why not just port to regular views and when more dependencies come online, port to razor pages. The way razor pages is designed makes it trivial to go from a controller action to a razor page.

Yes, we have other things. System.Directory services is what I point out because even the top requested namespace isn't ready. All others are worse off. The API portability analyzer isn't even updated for VS 2017 where we can run it. The analyzer to see if you can even port hasn't been invested in and we're dropping support already.

Just make sure to escalate that list of dependencies so we know what's important.

davidfowl on 9 May 2017

@aboo

Does this mean we are stuck and won't be able to upgrade to .Net Core 2.0 and netcoreapp2.0 and netstandard 2.0?

You meant ASP.NET Core 2.0 and? .NET Core 2.0 and .NET Standard 2.0 don't really apply here.

Yes, you'll have to stay on ASP.NET Core 1.x.

davidfowl on 9 May 2017

The bulk of the work done to make things compatible was done in .NET Core 2.0 and .NET Standard 2.0. ASP.NET Core 2.0 honestly doesn't have that many new features. We're said we're going to backport SignalR to ASP.NET Core 1.x (which is post 2.0 anyways). Is it just a perception thing?

@davidfowl I think you're massively underestimating the fear that strikes the heart of a windows developer when you're told you're going to have to migrate things. _Especially_ when the new stack hasn't hit feature parity with the old stack, and it's unknown if and when that will happen. This is basically announcing the EOL-ing of ASP.NET Core on the full .NET Framework. And, while that probably wasn't the long-term plan, it was announced as a feature, and people thought it might stick around for a while. Roadmaps are shifting as we speak. Meetings will be had.

We've got some disgustingly old stuff that we have to support because of nominally maintained database connectors and SDKs. Some of these vendors are far more likely to release a new, butchered API with 30% existing functionality, an HTML5 interface and a fresh train of bugs than they are to maintain their existing products. Or they might just acquihire a competitor, release the product and quickly EOL it. Some of these vendors are big enough to be recognizable. We've got a lot of nice code, but some of that code also lives in the windows slums despite our best efforts because it's not always under our control. Old tech doesn't just gracefully retire. It lurks under your bed, in our closet, and beneath your keyboard.

I'm more concerned about this move signalling the possible sidelining of .NET Standard than I am about the rest of it. .NET Standard initially seemed like something that would bring the different implementations closer and closer to feature parity while allowing consumers to migrate to the evolving, growing platform. Now it's sounding like nothing more than a milestone of .NET Core features. You won't be able to (or want to) target executables towards .NET Standard - only libraries. And it sounds like there will be significantly less planning involved in .NET Standard, and instead it'll just get rubber-stamped with whatever got used in ASP.NET because it's already too late to change. It'll already be in production, after all.

Other developers have to sprinkle the code with compiler directives, split code into platform-specific libraries and compile with multiple targets. The rude part of me wants the ASP.NET Core team to dogfood that so you'll be interested in better runtime and tooling support for multi-targeting and multi-platform scenarios. And if your team wants it, then we might get it. The practical part of me says that at a minimum, you should have periodic releases of ASP.NET Core that target the .NET Standard. You need to make actual _stable_ releases anyway. No one's just going to compile the master branch from git and deploy to production. Why not do smaller iterations of the .NET Standard and match them with a tagged ASP.NET release?

Also, is there going to be a new ASP.NET for the desktop? All the fanfare made it sound like ASP.NET Core was the only ASP.NET. Now it's sounding like you won't get anything new on ASP.NET unless you're on .NET Core. And that's going to change a lot of business strategies. There is a whole lot of confusion going on with roadmaps.

MVC 5 will never go away, we don't deprecate anything. It'll be supported as long as .NET Framework exists.

Yes, we're quite aware that the old stuff will stay there. It usually does, and we appreciate that. But whether new things will get on the "full" framework matters a whole lot. We need to know where things are going. We don't want to ride the train to the end and only then think about how to move forward. We've also got our passengers to worry about. And the disparity between .NET Core and .NET Framework leaves a lot of people uncertain about the future. I asked a question a year and a half ago about when a particular portion of functionality was going to be supported in .NET Core. I even asked if it would be accepted if I were to work on it personally. Communication has been sparse. I still have no idea what's going to happen to it. That type of uncertainty about supported scenarios and timelines makes a huge difference in the code that we write. Even knowing what sections of the desktop framework are low-priority could give people ample time to migrate instead of waiting for status updates.

In short, I support what you're doing and the goals behind it. And I know it's hard when we get on here and complain about decisions that you've made for a very good reason. But a lot of people aren't going to jump on the pioneer train because they can't, and others won't because they don't know where it's going.

ZigMeowNyan on 9 May 2017

👍5

@davidfowl I guess. What do you call a core project (new) with .Net Framework? Whatever that is, my understanding from the post is that the netstandard vNext will not support that.

aboo on 9 May 2017

@markrendle We are real customers. We're telling people things won't work. I know my architecture better than you do, so the arrogant comments aren't helping. To your points:

The team are not just doing this for the hell of it. There's a whole slew of new features and optimizations ready (or nearly ready) to roll in .NET Core that are incredibly useful to people building modern web applications, APIs and microservices, and waiting for those features to land in the full Windows .NET Framework would delay release by many months.

No one is against them also supporting these things. Our complaints are universally about dropping support, not conditionally adding new features.

Many of the complaints I see in this thread are some variation of "I can't do X in .NET Core 2.0" when what the writer actually means is "I have to change the way I do X in .NET Core 2.0". Yes, you have to change. No, that's not a bad thing. If you have a small piece of discrete functionality in your ASP.NET MVC application that does something with PDFs or DOCX files, and you really can't find a better way to do whatever that is (have you tried?), then break that functionality out into a microservice running on full .NET on Windows Server and call it as an HTTP API from your .NET Core application. Decomposing applications and moving specific functionality into small, self-contained services isn't even a workaround, it's a general-purpose best practice.

This is just so far off base I don't know where to start. Our pages would be far slower and more expensive in "micro-services". We'd eat significantly more time in GC than we do in page renders with such a setup. This also makes the assumption that the full framework dependency is not a critical part of every page render. Bad assumption.

.NET Core 2.0 isn't even in proper public preview yet, so complaining that it hasn't got support for LDAP or whatever seems premature. If RTM comes around in Q3 and there's still no way of interacting with AD or Kerberos or whatever then complain away (although also think about migrating to modern token-based authentication systems because it's not 2008 anymore).

We've been told they won't be there. Watch the stand up. Or look at GitHub where it's labelled "Future". We're complaining now because this bad decision will have shipped in Q3.

There is a smooth migration from ASP.NET MVC 4.5 to ASP.NET Core 2.0. It's called ASP.NET Core 1.0 (and I agree that there should be some promise of long-term support for 1.0 under the circumstances).

Long-term support doesn't mean it's not a dead end. We can still easily be stranded on 1.x when it goes end of life. In that case, we'd have had longer support on full framework.

Full .NET catches up and you can run ASP.NET Core 2.x on it

It's targeting netcoreapp, that won't happen.

...or Whatever third-party tech you depend on supports .NET Core (or can be replaced by equivalent tech that supports .NET Core).

Those libraries are often outside of people's control and time budgets. Even libraries from Microsoft aren't being upgraded. I'm fighting the SQL team right now to upgrade their packages to work on the new project system because install.ps1 works. If we can't even get those simple fixes in, we're screwed with netstandard ports.

Remember that—while your team might be hamstrung by external dependencies or internal company policies or politics or just plain inertia—there are hundreds of thousands, if not millions, of developers in the world who are looking to build applications, services and APIs using modern architectural patterns and new technology platforms (cloud/edge/IoT/etc), for whom ASP.NET Core 2.0 is a great fit. They want it to be fast, scalable and cross-platform; those things are important to a lot of people. Asking Microsoft to ignore that rapidly-expanding market, just because your 3rd-party control supplier or an open-source project haven't ported their code yet, is silly.

Calling it silly is belittling, rude, and uncalled for. This is our lives. These are our apps. These are the things we have spent years or decades creating and suddenly before release we find out that the outlook is time capped for us, hard. A lot of uncertainty is introduced to say the least. That's not really something you want in your career.

NickCraver on 9 May 2017

👍61

every point make sense, but remember that in this universe everything will go in the state that requires less energy, then make sure that that state is where you want to go, because we will go there in a way or another.
So if you want to achieve a certain state, make sure that it requires less energy than the one required to stay where we are now.

Duke360 on 9 May 2017

I've just read through this entire thread after someone mentioned this as an aside in IRC - I haven't seen any official announcement of this yet - and I'm thoroughly disappointed.

I've been watching .NET Core, getting involved and converting small projects over from .NET Framework to .NET Standard / .NET Core in order to get some experience with the new SDK and runtime, and to run these projects on macOS and Linux.

My big target is a large enterprise web service that uses a heap of components which are not available [yet] in .NET Core 1.0 or 1.1. This includes, just off the top of my head:

Active Directory (System.DirectoryServices), used for authentication and user management
Entity Framework 6 (EntityFramework), since EF Core doesn't support a lot of the functions yet that we use.
OData (Microsoft.Data.Services/System.Data.Services) v1-3, the client Javascript library we use doesn't support v4 (yet) and WebAPI OData is a lot more complex to set up.
IIS Management (System.Web.Management) and .NET Remoting (System.Runtime.Remoting) for the web service's ability to upgrade itself - though this could be extracted out to a standalone application.
SignalR
Custom IHttpHandlers and IHttpModules, which would have to be adapted to whatever ASP.NET Core's equivalent is, probably some kind of middleware
A whole bunch of custom stuff using ASP.NET WebAPI's extensibility.
I think we might even use Microsoft.TeamFoundationServer.ExtendedClient on the server, which only supports net46, has some native assemblies, and has about a 0% chance of working on .NET Core 2.0.
etc.

Due to the size and complexity of this service, any migration to .NET Core would have to be gradual, and in all likelihood we might have to use some new-in-ASP.NET-Core-2.0 APIs, I don't know yet, we haven't gotten that far.

Removing the ability to run ASP.NET Core on the .NET Framework means that migrations must be done big-bang style if ASP.NET Core 1.x is not a viable stepping stone. We instantly lose the stage of "run new framework on old runtime" before "run new framework on new runtime". This is a horrific change-management strategy for any large system.

I wouldn't mind so much if .NET Framework support was dropped once .NET Core was at or near parity, but it's still quite far behind for any sufficiently advanced application, and I don't think 2.0 is the right place to make such a breaking change.

yaakov-h on 9 May 2017

👍2

@davidfowl

I understand this one but I can't believe that you're going to convert all of stack overflow to razor pages only. If you're already using MVC today why not just port to regular views and when more dependencies come online, port to razor pages. The way razor pages is designed makes it trivial to go from a controller action to a razor page.

Many libraries, etc. shared across apps are in play here. Stack Overflow is many applications (the main website is almost entirely a single app, but as a company: we have many related, communicating things.

Just make sure to escalate that list of dependencies so we know what's important.

Yep, I'm doing that. But that won't be the last dependency, just the biggest blocker since we can't even login to some apps without it. It's a first-screen breaker. I'll try and do the full portability analyzer across our apps this week (after a launch this morning), but I fear it'll just be more depressing. It would help if the analyzer was even updated for current tooling before moves like this were even considered.

Data helps, I'll try and get your more data - unless there's zero chance of this decision changing. If that's the case, please tell us so I don't invest any more of my time in it.

NickCraver on 9 May 2017

Just for the record: OData is another library that doesn't support netcoreapp yet.

Actually it's even still based on System.Web (you have to use it via OWIN middleware in ASP.NET Core) and they promised support (see https://github.com/OData/WebApi/issues/939).

Still worth mentioning. Especially since it's from Microsoft.

EDIT: @yaakov-h was 2 min faster, so +1 for his mentioning of OData

froitag on 9 May 2017

I'm still here replying for a couple of reasons

I care
Sleep is for the weak 😆
I need to call out the FUD because somebody on the internet is wrong

davidfowl on 9 May 2017

❤24 👍6

@NickCraver

Many libraries, etc. shared across apps are in play here. Stack Overflow is many applications (the main website is almost entirely a single app, but as a company: we have many related, communicating things.

It just means you can't use Razor pages tbh, ASP.NET Core 2.0 has lots of small things but there's not big features or fixes that aren't also being back ported to 1.x. The EOL thing is very real and I personally don't think ASP.NET Core 2.0 supporting .NET Framework for another year would help. We're really discussing a direction change here, either we support .NET Framework forever, or not, there's really no inbetween.

davidfowl on 9 May 2017

👍1

@dustinmoris is not just that. is also a expectations problem. Your use case may be not the same of everyone else.

I am developing aspnetcore 1.* apps and using the .NET desktop as runtime (LOB for enterprise).

And i understand what's the difference between .net core runtime, netstandard, etc (just to be sure this is not a comment about a misunderstanding about that)

My migration was to aspnet core first (targeting .net desktop) because the flow/vision/etc, consolidate it, and AFTER move it to .net core (if possibile), was the decisive scenario in the aspnetcore choice.

This issue is just a bit unexpected, because aspnetcore 1.* was always marketed as "run on both framework", with zero warnings afaik about a dropping it next (version or year).
I was expecting an obsolete -> deprecated cycle at least, or just unsupported features (that's ok).

The good part about .net (and aspnet as choice for web stack) is i can leverage existing codebase and libraries.
Some are internal, no real roi to migrate these, when the target (.net core/netstandard) is too fluid.
Some are external, and are difficult to change, if these doesnt work in the netcoreapp2 closure, i cannot use these.

Plus my idea was consolitate to netstandard2 not netcoreapp2.
How can i start to just evaluate the migration of libs to netstandard2, if is not there yet? Is difficult to evaluate migration based on preview bits and promises (and latest years lowered my trust on stability of promises)

I understand is a different scenario than fully greenfield, but also if greenfield i'd like to reuse some libs, because i need to interact with existing system (excel/pdf/etc), not rewrite everything from scracth.
Or add microservices as rpc just because is latest trend, because make things more complicated (that is a conciuous chooice i want to evaluate and do, not be forced to to wrap existing libs). I need to deliver value (aspnetcore dev flow is nice and productive), not just change architecture.

In my personal evaluation of ecosystem, for my use case, the avaiability of .net core and/or netstandard lib is atm too low (not everyone use just free nuget.org oss pkgs). So if i need to migrate hard to a new stack, i need to evaluate also others stacks (cost/benefit/future/trust/etc)

I am not only writing a TODO web app, i use .NET because i got man years of stuff ready, so i can change one thing (in this case aspnetcore, and leave the rest as is for this iteration).
Just change everything is a recipe for disaster in my scenario, and when i need to do that, i need to really start evaluate if make more sense to migrate to another stack (as java/node) where lib exists.

A smooth migration take time, i like the vision for future aspnet core. but if i dont have a clear path (or doubt about it), is difficult to sell internally.

That said, leave behind .net desktop, can be a good gamble of aspnet team to move faster and pick more new users (or dont lose currents to node/java).
But for sure, is going to make harder the life for dev on slower ring, and this is aspnet team call (their product).
My feedback is to not do that, and work hard to support for fw, because as a dev, i need trust and stability, and last years where a bit too fluid in .net ecosystem (not just netcore/project.json, but before also, and marketing/evangelist didnt help lowering the trust)

enricosada on 9 May 2017

@yaakov-h

If you decide to port to ASP.NET Core (either 1.x or 2.x) you'll need another process. ASP.NET Core does not run on System.Web so you can't do a gradual port in the same project.

I wouldn't mind so much if .NET Framework support was dropped once .NET Core was at or near parity, but it's still quite far behind for any sufficiently advanced application, and I don't think 2.0 is the right place to make such a breaking change.

There is no right time to drop it. It was never meant to reach parity with .NET Framework and it's quite possible that there are dependencies you have that will never ported. Given that, my question would be, do you redesign the application or do you realistically need to stay on .NET Framework forever?

davidfowl on 9 May 2017

@davidfowl that depends entirely on our upstream dependencies. At this point in time, we would be staying on .NET Framework forever.

Interestingly enough most of the 3rd-party ones have netstandard releases available already. It's largely the Microsoft dependencies that are keeping us on .NET Framework, and some of those seem to be semi-abandoned (e.g. OData)

yaakov-h on 9 May 2017

👍5 😄3

@NickCraver I don't mean to be belittling or insulting. I appreciate that this is a late-in-the-day change, and that's frustrating for whatever section of the community are affected by it, and if I were affected by it, I would probably be kicking up a fuss too. I'm not (where I work we're still on ASP.NET WebAPI 5.2.3), so my take on the situation is less emotional.

Look at it this way: if you were to start from scratch building the next Stack Exchange (whatever that might be) today, wouldn't the stuff that's in netcoreapp20 that the ASP.NET Core team want to use (like UTF8Strings and Pipelines and low-allocation, asynchronous, _fast_ primitives (I'm guessing a bit there)) make it more attractive to you than full .NET? Wouldn't .NET Core 2.0 generally make more sense than full .NET 4.7.1? If you were picking between web stacks that can evolve and adapt to change quickly, vs web stacks that are irrevocably tied to a slow-moving underlying technology with nearly two decades of legacy code to worry about supporting, which would you choose?

markrendle on 9 May 2017

👍3

@ZigMeowNyan

I'm more concerned about this move signalling the possible sidelining of .NET Standard than I am about the rest of it. .NET Standard initially seemed like something that would bring the different implementations closer and closer to feature parity while allowing consumers to migrate to the evolving, growing platform. Now it's sounding like nothing more than a milestone of .NET Core features. You won't be able to (or want to) target executables towards .NET Standard - only libraries. And it sounds like there will be significantly less planning involved in .NET Standard, and instead it'll just get rubber-stamped with whatever got used in ASP.NET because it's already too late to change. It'll already be in production, after all.

Those are actually really good points and something worth considering. You have to understand that it has nothing to do with .NET Standard being sidelined, it's just physics. If each .NET platform moves at it's own pace then using the latest .NET Standard means the slower moving frameworks get things less often. That's something that should be internalized by everyone. That doesn't make it less useful, it's just the nature of the beast. The only way to remove this burden is to have a single implementation and a single ship schedule which greatly narrows the places .NET would be able to run.

Other developers have to sprinkle the code with compiler directives, split code into platform-specific libraries and compile with multiple targets. The rude part of me wants the ASP.NET Core team to dogfood that so you'll be interested in better runtime and tooling support for multi-targeting and multi-platform scenarios. And if your team wants it, then we might get it. The practical part of me says that at a minimum, you should have periodic releases of ASP.NET Core that target the .NET Standard. You need to make actual stable releases anyway. No one's just going to compile the master branch from git and deploy to production. Why not do smaller iterations of the .NET Standard and match them with a tagged ASP.NET release?

We do the same thing, remember, we still target netstandard for a bunch of our libraries and those do contain ifdefs. Others however, target netstandard in order to set us up for taking advantage of new APIs in the 2.x timeframe.

In short, I support what you're doing and the goals behind it. And I know it's hard when we get on here and complain about decisions that you've made for a very good reason. But a lot of people aren't going to jump on the pioneer train because they can't, and others won't because they don't know where it's going.

Honest question (this is me asking not Microsoft), do you favor compatibility over new features? If yes, why choose ASP.NET Core?

davidfowl on 9 May 2017

👍3

Just another quick thought: for every thread like this one, there exists an equivalent-but-opposite thread where a different—but just as big—group of people got just as upset because a concession to supporting "old" .NET was made.

markrendle on 9 May 2017

👍4

Interestingly enough most of the 3rd-party ones have netstandard releases available already. It's largely the Microsoft dependencies that are keeping us on .NET Framework, and some of those seem to be semi-abandoned (e.g. OData)

😞

davidfowl on 9 May 2017

😄6 ❤3

@markrendle

• Many of the complaints I see in this thread are some variation of "I can't do X in .NET Core 2.0" when what the writer actually means is "I have to change the way I do X in .NET Core 2.0". Yes, you have to change. No, that's not a bad thing. If you have a small piece of discrete functionality in your ASP.NET MVC application that does something with PDFs or DOCX files, and you really can't find a better way to do whatever that is (have you tried?), then break that functionality out into a microservice running on full .NET on Windows Server and call it as an HTTP API from your .NET Core application. Decomposing applications and moving specific functionality into small, self-contained services isn't even a workaround, it's a general-purpose best practice.
NB As far as I can tell, the OpenXML packages are now supporting .NET Standard, so working with Word/Excel/whatever shouldn't be impossible.<<

As others have already stated, changing the architecture of our nice design is not good plan. In our case we share code between our WPF test of application and the server. The more differences we create between those more complicated it is to maintain.

I can assure you I have spent a lot of time investigating the best tools for us to use for PDF, DocX generation and it's nowhere near as simple as doing with open XML. We use a third-party library because there are tens of thousands of lines of code that they have developed and we don't have to develop/maintain/test. That's the whole point.

.net versioning has become very complicated. I'm not clear if at any point in the future ASP.net will be able to be used on the full .net framework? Because I need to share code between the server and my desktop applications does that mean I can never have the latest version of ASP.Net? This is not an issue in the short term but in the longer term with security improvements et cetera I don't want to be too far away from the latest version. I'm sure there are many others in my boat where you need some form of compatibility with the full framework.

To clarify what I do is that I have three of my own libraries that are shared between various WPF apps and my server. I would have absolutely no idea at this point which Apis I'm using may or may not be available in.net core. And then in those libraries I use full desktop versions of both Telerik and SyncFusion's WPF tools for generating docx and pdf. Some or all of the functionality that those tools use may or may not be available in .net core. Trying to develop applications based on may or may not is extremely difficult. Microsoft has a brilliant base framework in .net, and whilst I understand the reasoning behind .net core. Microsoft seems to have forgotten the importance of backward compatibility.

Stefan

stefanolson on 9 May 2017

@markrendle

Oh, sorry, I didn't realise your sample size was so big. 257 comments with a strong bias towards people who don't like the decision? Hard to argue with that. DISCLAIMER: I am not an expert on Big Data.

No idea what I did to you, but there's no need for snark or lowlevel whining like this. You know full well this thread is just an example.

FransBouma on 9 May 2017

👍3

@stefanolson

.net versioning has become very complicated

I think this is one of the few things we can all agree on.

We are looking to port to .Net Core x.
Our biggest issues are around:
NewRelic (no .Net Core plan, so we need to find an alt)
NH (where EF Core doesn't have the features).
ServiceBase (sounds like it's coming to .Net Core 2 in summer)

It certainly sounds like we'd have to target Core 1.0 in the interim and wait for NH, EF upgrades or get creative.

penderi on 9 May 2017

👍3

It just means you can't use Razor pages tbh, ASP.NET Core 2.0 has lots of small things but there's not big features or fixes that aren't also being back ported to 1.x. The EOL thing is very real and I personally don't think ASP.NET Core 2.0 supporting .NET Framework for another year would help. We're really discussing a direction change here, either we support .NET Framework forever, or not, there's really no inbetween.

It's a little bigger than Razor pages, it means there's no reason to move. There just exists no (current) scenario in which both of these exist:

We'll be supported the whole time
There's an actual upgrade on the other side

The fact is that ASP.NET Core isn't really all that useful without the ecosystem. Having a controller that renders text back is great, but not useful for that many scenarios. We need the APIs. We need the libraries. We need the ecosystem, that's why we chose .NET in the first place.

This change comes goes from a framework that fully supports our use cases today to one that's clearly not ready. It's not even close to ready. And a preview to test if it is ready isn't even generally available. A migration to figure out the promises of what will be ready is not available. We're banking on a whole bunch of promises and many will be burned. That's the worst possible way to market these things: over-promising and over-delivering (the overall experience).

I think ASP.NET Core is great. You guys are doing awesome stuff. I was lucky enough to help with some of it. But this switch at this point in time is bad. If all of the things we think will be ported are actually ported in the 2.x time frame, then great. Make the change in 3.x then. Porting before an alternative is ready and setting a deadline for when to kill the EOL life line is bad. Telling people to port to a maintenance -> EOL version is bad.

Please, don't make this change now. .NET is better than this. Show you care about your users as much as everyone here cares about you. We wouldn't be here if we didn't want to help.

NickCraver on 9 May 2017

👍27

@FransBouma You (should) know full well that Microsoft have vast databases of telemetry, feedback and other data on what people are doing with their tech that give a much clearer picture than any number of GitHub Issues threads, and I don't think my pointing that out was any snarkier than

Oh I don't know, by reading the posts in this thread?

markrendle on 9 May 2017

👎1 👍1

.net versioning has become very complicated. I'm not clear if at any point in the future ASP.net will be able to be used on the full .net framework? Because I need to share code between the server and my desktop applications does that mean I can never have the latest version of ASP.Net? This is not an issue in the short term but in the longer term with security improvements et cetera I don't want to be too far away from the latest version. I'm sure there are many others in my boat where you need some form of compatibility with the full framework.

The code sharing story across different .NET runtimes is .NET Standard. Your libraries should try to target that to code shared across .NET Core and .NET Framework.

Microsoft seems to have forgotten the importance of backward compatibility.

The problem is, ASP.NET Core was never meant to be backwards compatible... That why there was such a big paradigm shift from ASP.NET 4.x. Seems like if backwards compatibility is the high order bit for you'd be better of using ASP.NET 4.x on .NET Framework. That is supported for the forseeable future and will be security patched for as long as Windows is alive.

davidfowl on 9 May 2017

Even if it wasn't meant to be, though, 1.0 was very backwards compatible! It supported the whole vast legacy of the ecosystem, and we appreciated it. It seemed at the time like nobody had to give away their cake or refrain from eating it.

gulbanana on 9 May 2017

👍1

@NickCraver

It's a little bigger than Razor pages, it means there's no reason to move. There just exists no (current) scenario in which both of these exist:

Can you elaborate?

The fact is that ASP.NET Core isn't really all that useful without the ecosystem. Having a controller that renders text back is great, but not useful for that many scenarios.

It can do it really fast too 😉

I think ASP.NET Core is great. You guys are doing awesome stuff. I was lucky enough to help with some of it. But this switch at this point in time is bad. If all of the things we think will be ported are actually ported in the 2.x time frame, then great. Make the change in 3.x then. Porting before an alternative is ready and setting a deadline for when to kill the EOL life line is bad. Telling people to port to a maintenance -> EOL version is bad.

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop). Can you please explain that to me? How does that make any difference?

davidfowl on 9 May 2017

A couple of //BUILD 2017 session recommendations for those concerned about long-term support of ASP.NET variations:

T6009 ASP.NET Web Forms updates
- i.e. they're still developing full .NET web platforms
T6072 Support for ASP.NET Core: What is an LTS?
- Which I'd guess is being frantically updated right now :grimacing:

markrendle on 9 May 2017

@davidfowl:

How does that make any difference?

Because you've promised some of the most significant missing APIs to ship after 2.0 does?

yaakov-h on 9 May 2017

@yaakov-h

Because you've promised some of the most significant missing APIs to ship after 2.0 does?

Tell me which ones in ASP.NET Core?

davidfowl on 9 May 2017

@davidfowl System.DirectoryServices, System.Drawing were mentioned above.

yaakov-h on 9 May 2017

Honest question (this is me asking not Microsoft), do you favor stability and compatibility over new features? If yes, why choose ASP.NET Core?

I think this is a very good question. If the full .NET framework gives one everything they need today, why so keen on migrating to a complete different stack? If .NET Core and ASP.NET Core would have been named differently, without .NET int the name, then I think much less people would argue about migration issues. Nobody complains that they can't migrate to a faster moving Go or Node.js web stack.

dustinmoris on 9 May 2017

@davidfowl being backward compatible to ASP.NET MVC 5.x is one thing, being backward compatible to .net framework is another thing. Dropping .net framework is a big thing...

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop).

Because 2.x is coming very soon as we understand.

hikalkan on 9 May 2017

@davidfowl System.DirectoryServices, System.Drawing were mentioned above.

Those have nothing to do with ASP.NET Core 1.x or 2.x and will run on both when they come online.

Like I said, I'm just here to call out the FUD and thats part of it. This thread has gotten so big that nobody can see the facts in some of the replies.

davidfowl on 9 May 2017

👍2

@FransBouma You (should) know full well that Microsoft have vast databases of telemetry, feedback and other data on what people are doing with their tech that give a much clearer picture than any number of GitHub Issues threads, and I don't think my pointing that out was any snarkier than

@markrendle telemetry is not magic. You cannot measure why ppl/dev are not switching, or why they switched over other stack, or the importance of their project and how much they like the stack (and help others, with consulting or oss), or what they are doing.

This thread is exactly that, a feedback.

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop). Can you please explain that to me? How does that make any difference?

@davidfowl time.
time to settle a bit. time to evaluate things. time to change one thing a time. time to use netstandard2 packages with an rtm thing. time to move our libs to netstandard2 (easier) instead of netstandard1 (harder). Time to change one stuff a time, for me, mostly.
You do aspnet, but my product is not only aspnet, is a combination of lots of libs and tradeoffs and the ecosystem.

enricosada on 9 May 2017

Because 2.x is coming very soon as we understand.

What does that have to do with it? What if 2.0 was coming at the end of year or in January? Would it make a difference? What is it in 2.0 that makes 1.x not worthy?

davidfowl on 9 May 2017

@yaakov-h They were mentioned here where @shanselman said (emphasis mine)

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

markrendle on 9 May 2017

@davidfowl it's not about version, it's about date and maturity of .net core and it's ecosystem.

hikalkan on 9 May 2017

@hikalkan

I'm sorry, I understand that from a very high level POV but not from a technical one. Maybe this isn't a technical discussion?

davidfowl on 9 May 2017

👍1

@enricosada

time to settle a bit. time to evaluate things. time to change one thing a time. time to use netstandard2 packages with an rtm thing. time to move our libs to netstandard2 (easier) instead of netstandard1 (harder). Time to change one stuff a time, for me, mostly.
You do aspnet, but my product is not only aspnet, is a combination of lots of libs and tradeoffs and the ecosystem.

Why difference does that make to ASP.NET Core 2.0 specifically? You'll get that benefit from the platform regardless of what ASP.NET Core chooses to do.

davidfowl on 9 May 2017

@markrendle someone get me a calendar, because seasons span an entire quarter (could be 3 months out from something else in the same quarter) and are especially confusing to us southern-hemisphere people.

yaakov-h on 9 May 2017

@enricosada You can get an awful lot of useful information from telemetry and other data sources (web analytics, search data, direct customer feedback). Far more than you can get from angry mobs on GitHub (however justified each individual's anger might be).

markrendle on 9 May 2017

👍1

@yaakov-h Well, the current projected RTM for .NET Core 2.0 (and so ASP.NET Core 2.0) is calendar Q3, which is July/August/September), and Summer in the northern hemisphere is mostly July/August/September, so it's basically the same thing.

markrendle on 9 May 2017

You can get an awful lot of useful information from telemetry and other data sources (web analytics, search data, direct customer feedback).

I wonder how reliable this telemetry - at least the automated part - is for enterprise deployments, though. (Since that's where the majority of the backlash seems to be coming from.)

dahauns on 9 May 2017

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop). Can you please explain that to me? How does that make any difference?

@davidfowl Time. And a proper announcement. If the messaging was clearer, people would't be as surprised.

khellang on 9 May 2017

👍7

@davidfowl Time. And a proper announcement. If the messaging was clearer, people would't be as surprised.

I understand but I don't think it would make a difference in your ability to port anything really. The same EOL policy still exists.

davidfowl on 9 May 2017

Ok, after having a hard time to understand this issue, i wanted to bring some insights for those that struggles like me and also have some questions.

so if understand correctly, we will eventually have netstandard replacing net framework.

So lets asume netcore doesn't exist and aspnet core is based on netstandard. that means that features will come slower.

Example:
2017 asp.net wants Feature A.
2018 netstandard implement Feature A. we get Feature A on ns.

What the team is saying is to have netcore not based on netstandard so:
2017 asp.net wants Feature A
2017 aspnet team implements Feature A. Asp.Net Core get Feature A on netcore.
2018 netstandard implements Feature A. we get Feature A on ns.

So, this decision actually brings more "flexibility and speed" to the equation. Faster release for who can use them, feedback, etc. I think it's a great addition to the slow peace of net framework. Feature will be really mature when it reachs NS.

If having netcore based on netstandard 2 means that features are released 1 year (or any time-frame) later, people will still argue that they want this? This is the scenario we are used to with NET Framework.

This is a heaven for aspnet team, be able to ship stuff without being dependent on someone else, and it's also great news for customers who can get those fast stuff. If you can't go with the fast stuff, sticking to the previous version is a reasonable trade-off (and motivation for you/dependencies to upgrade.)

Library authors should still AIM to target netstandard, and if you can then no worries at all.
If you need something not on netstandard (maybe razor pages(?)) then you must target netcore, on scenario 1, razor pages may well not even exist. I don't see how this can be bad, i would say it's fair.

So the question is, which dependency you have right now that limit yourself from going NET Framework to Net Core ?
I may be the only one here but I never expected aspnet core to work on NET Framework forever, it was obvious to me that this was a "transition" step. All my development that currently need NET Framework is splited. (and no, this isn't microservices, it's much simpler than that).

the 2.x support and 3.x drop is not different than 1.x support and 2.x drop. I'll take a guess here and say that people is not understanding the scenario clearly, so I hope this clarify at least some.

@NickCraver you said you want microsoft to revert this decision. What would be your suggestion, to do not have an isolated netcore and have slower feature releases? (honest question)

@davidfowl I think there may be a subtle hidden issue with the current proposal that worries developers.
If you have feature A for asp.net (with netcore) then you can market and ship (and tick a management/pm checkbox) and be "lazy" to implement on netstandard, if I'm not mistaken this is what "betting" on uncertain is refereed here.
So in my previous example, netstandard implements Feature A may be in 2019, or 2020, or never instead of 2018. <-- this looks like a possible problem (?) am I right ? Can Microsoft commit to something here?

Bartmax on 9 May 2017

👍1

Whilst we can all differ on whether we like the announcement thanks indeed to @davidfowl @DamianEdwards and @shanselman for spending the time to discuss. It's further proof of increased engagement and openness.

I'm sure some will argue on timing etc, but it's progress.

penderi on 9 May 2017

👍1

Example:
2017 asp.net wants Feature A.
2018 netstandard implement Feature A. we get Feature A on ns.

What the team is saying is to have netcore not based on netstandard so:
2017 asp.net wants Feature A
2017 aspnet team implements Feature A. Asp.Net Core get Feature A on netcore.
2018 netstandard implements Feature A. we get Feature A on ns.

what they should have done is:
2017 aspnet team builds feature needed in lib X, which supports netstandard2.0. This way aspnet works on everything .netstandard runs on, and users can then run it on .net full as lib X is usable on .NET full too (it's just a nuget install away).

Instead, they don't do this, they force lib X to be .NET core only (otherwise, why this thread/decision in the first place). If lib X is so superadvanced that it needs CoreCLR features, Microsoft has to ask themselves why these advanced features aren't ported to the .NET full CLR.

All in all it feels like politics where MS needs a fast moving .NET core/aspnet core to provide Azure customers a stack which can be used in containers on azure so it competes with JVM/NodeJS based containers on AWS or Google cloud. From their business perspective I can even understand that. But what it shows is that MS has no priority concerning .NET full to move forward faster, as it doesn't put enough resources on .NET full to keep up with .NET core. Look at the amount of APIs added to .NET full in the past 2 years. Does that tell you a large team is working on that?

No.

Microsoft sells a large database system, SQL Server Enterprise. It comes with fancy encryption features. Not supported on .NET core. Have fun selling .NET core 2.0 to the enterprises who are the potential customers of that expensive database system.

You may want to move 'fast', but unless you fully understand the destination you're moving towards, it helps taking a minute or two to decide that first.

FransBouma on 9 May 2017

👍4

The more I think about it the more I think the issue most people have is that they feel we are cutting the cord between .net and asp.net.
Currently we have asp.net, asp.net core (.net), and asp.net core (core). So you could choose if you wanted to go no, little or full core.

Since the versioning is poorly communicated people feel that it's only the last part that is innovating and moving on, while asp.net and asp.net core (.net) is stuck.
Since we have no way to validate if a lib will work in netstandard2.0 without trying, it gets very risky to go with full core on a new project. So they end up with either asp.net (old) or asp.net core (also old).
And since both are old, it makes sense to just go with system.web and old asp.net. Since they know that and since asp.net core is EOL anyway, why bother.

So we end up with only the brave choosing core, and the rest go with old but stable system.web. And we will forever be stuck with a even more fractured ecosystem.

PS: I'm wording this as with the current feeling. That asp.net core 1.x is "old and outdated" vs 2.x. Not that it's a fact, but that's what people are thinking.

hallatore on 9 May 2017

👍1

@davidfowl

If each .NET platform moves at it's own pace then using the latest .NET Standard means the slower moving frameworks get things less often.

This already happens, and we're okay with it. The Versions document is commonly filled with _vNext_. And that's fine. Rather than waiting until all platforms are at parity before incrementing the standard, I'd rather see the standard defined a few versions ahead and watch the platforms catch up. People can even pitch in for the definition and implementation. And if ASP.NET Core targeted the standard for its releases, the moment a platform and architecture implemented that new standard, the package would be available. New Standard versions could come in through VS updates or packages.

The way it's being presented, though .NET Standard doesn't sound like it's a community planned effort. It's more like a snapshot of the implemented contracts that passed review. And if major projects aren't targeting it, there won't be nearly as much planning towards its releases.

We do the same thing

Oh good. Shared misery is best misery. Csproj and sln files with the platform/config stuff are really annoying, btw, because the build combinations aren't always declared - they're inferred. So VS might think I have more build combinations than actually exist because it assumes that every possible combination is important. And I have to have extra sections in the file that wouldn't be needed if i could just declare the platform/config combinations. Like how you can use functions like Substring in the csproj PropertyGroup elements to simplify custom properties, but those conditions are used in determine build configurations, so you have to have the full string values in there. This kind of stuff shouldn't be as much of a hassle as it is.

Honest question (this is me asking not Microsoft), do you favor compatibility over new features? If yes, why choose ASP.NET Core?

Personally, no. As long as there's a way to do what I need to do, I don't mind rewriting the code as long as it's not a huge endeavor with little benefit or a PITA to test. So I'd pick whatever's got the most momentum and potential. But I have to work with projects across multiple technologies - Win32, COM, CORBA, ADO.NET, several reporting engines, various web APIs, embedded browsers like CEF/Firefox/IE (no edge, of course, since it's not supported) and multiple vendor-specific things I'll avoid shaming. I implement what I can as a plugin, but I'm married to the least common denominator on the host executable, for the most part. Dealing with that many technologies is annoying, but they're static. That's how a lot of desktop/server stuff is. As long as I'm given the tools to interop, I can make do. But the less deprecated frameworks I remember, the better.

ASP.NET, though, is part of the web stack, and the web stack is something that I feel needs to stay up to date. It has a different use case, and there's an unfortunate expectation to use the newer platform for web work unless there's a good reason not to, or a significant incompatible code base. I try to keep that updated because web standards change quickly and significantly. Most of the people keeping pace with the web are sticking with newer technology, and implementing the new stuff on older stacks can be rather painful. Especially in the situation where ASP.NET competes with PHP and Node, I've got to keep a more modern stack to draw talent and interest. I'd love to do less web work, but unfortunately it's the new UI expectation. I was hoping that sticking to the standard would let me have the best of both worlds, but that seems like a limited time offer.

ZigMeowNyan on 9 May 2017

👍1

so if understand correctly, we will eventually have netstandard replacing net framework.

Not thats not correct. I'm not sure how you drew that conclusion. .NET Standard will always be a subset of each of the runtimes that support it.

I want to throw some crazy stuff out here because it's been mentioned a few times. What I'm about to say has no bearing on what will happen, it's all speculation at this point. Several people asked why we want to target .NET Core instead of .NET Standard.

We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).
Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span<T> and are looking at Buffer<T> to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.
This leads to new methods on String that allow splitting that doesn't allocate an array every time.
This leads to overloads to Int, UInt etc (TryParse) that take Span<char> and Span<byte>.
This leads to new encoding routines that take Span<byte>.
Buffer<T> and Span<T> let you represent memory in a uniform way and we want to upgrade the networking stack to allow passing pre-pinned buffers that take Span<T> or Buffer<T>.
Kestrel will implement HTTP2 in the 2.x timeframe (currently aiming at 2.1) and that requires new APIs on SSL stream to do ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http Client on .NET Core supports duplex streaming, it'll make it possible to implement streaming end points over http in signalr over a single, non websocket http request.
We forked the header parser implementations from HttpClient and System.Net.Http and renamed them (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) so that we could improve them and have them support both .NET Framework and .NET Core. .NET Core has a copy of these improvements haven't made it back because there no need to improve them (we couldn't consume them).
There are a bunch new threading primitives that require new API that will light up new scenarios if we're able to consume them (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+author%3Adavidfowl+label%3Aarea-System.Threading), those are just some of the things I've personally filed.

Without the ability to rev the core primitives, we're encouraged to fork them and make things that look like them but aren't them. It's the reason we have our own little BCL within ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

That was just a random dump of things I can see us doing in the near term that affects very fundamental pieces of .NET.

davidfowl on 9 May 2017

👍25 🎉1

@FransBouma

NET full to move forward faster, as it doesn't put enough resources on .NET full to keep up with .NET core. Look at the amount of APIs added to .NET full in the past 2 years. Does that tell you a large team is working on that?

That's just not true. Things are continually ported to .NET Framework but as we all know the risk is considerably higher than making those same changes in .NET Core. Don't you all hate it when an update to .NET Framework breaks your application? We do too so we invent all kinds of processes to mitigate it, you wouldn't believe the strangle hold it puts on engineering to maintain it. We still manage to do features in-spite of all of it. That said, it will just never move as fast as .NET Core, it's a windows component that ships on the windows schedule.

davidfowl on 9 May 2017

I understand but I don't think it would make a difference in your ability to port anything really. The same EOL policy still exists.

@davidfowl Correct. But how you frame it means something. Not to mention when it's communicated, if ever. It won't necessarily give people more time to do the actual work, but it would give them more time to think and make the correct decision (for them).

Currently, if you've started porting to/using ASP.NET Core on .NET Framework, it seems you have three choices:

Port all your code and dependencies to .NET Core and move to ASP.NET Core 2.x.
- This would be the optimal solution, but it could require tons of work, and for some, it might even be out of their control because of 3rd party libs.
Stay on ASP.NET Core 1.x and .NET Framework and hope you'll be able to do 1. before it's unsupported.
- This is pretty risky. Within a year (or two, or three? who knows?), you could risk running on an unsupported platform.
Move back to ASP.NET 4.x
- While this alternative leaves you supported, you'll be "going back" and undoing work you've already started. And also, let's face it; this platform won't be getting much love going forward.

If you'd known in advance and could plan for it, I think both 1. and 2. are decent alternatives. The issue is that both alternatives have quite a few unknowns. What about library A? What about library B? Will library A ever be ported?

Right now, I think a lot of people feel they're being forced into making a choice, without a clear picture of what the choices actually entail.

khellang on 9 May 2017

👍22 ❤2

@khellang (in your hypotheical solution)

Move to ASP.NET Core 2.0 on .NET Framework
- This is pretty risky. Within a year, you could risk running on an unsupported platform.

davidfowl on 9 May 2017

@davidfowl

Honest question (this is me asking not Microsoft), do you favor stability and compatibility over new features? If yes, why choose ASP.NET Core?

Honest answer:
Favor: Stability and compatibility is paramount. New features are nice, but when they land, they simply must not break the existing ecosystem.
Why ASP.NET Core: Simply because it runs on OS X and Linux.

An ecosystem like .NET (old and/or core) or also Java is chosen by businesses. And when they make their decision, they put a lot of effort in developing code for that platform / ecosystem.

Now, one of our customers, for example, already invested a lot in ASP.NET Core. Based on the previous announcements and sold ideas of .NET Core, code was written. This new (ASP.)NET Core code we (painfully) wrote with a team over the course of the initial development of (ASP).NET Core, starting with its inception, is a set of servers and client libraries, with quite a bunch of business logic.
And this code, besides running on Linux server, providing services, is currently also being used in a set of very old applications that talk to these services, and these are a hell of a mix of WPF / Windows Forms / C++/CLI and normal C++ (including DirectX stuff).

And now you're just simply cutting off our clients investment in quite a few man-years of effort into .NET Core code for the existing applications, as it will be impossible to re-use the new .NET Core code in the actual applications (the new servers and business logic libraries were build for).

To get back to the question: A business would chose .NET Core as ".NET, now also for XPlat", while expecting the very same compatibility and stability as .NET gave us in the last 17 years. And, to be frank, this is the single reason for .NET Core. If you wouldn't wanted that, you would use Node.js or even Java. Both are much more mature and XPlat than .NET Core now.

And, just to elaborate a litte bit more: .NET Core was cool and fast-paced at the early stages with project.json and all. And then, out of reasons of "compatibilty with .NET" project.json was taken from us in favour of Msbuild and .csproj again. And now the benefits of exactly this "compatibility with .NET" is also taken away, in favour of.. what exactly?

gingters on 9 May 2017

👍6 ❤1

@gingters

First of all, great reply!

Why ASP.NET Core: Simply because it runs on OS X and Linux.

Based on that, it seems like MVC 5 on mono is what you really wanted right?

To get back to the question: A business would chose .NET Core as ".NET, now also for XPlat", while expecting the very same compatibility and stability as .NET gave us in the last 17 years. And, to be frank, this is the single reason for .NET Core. If you wouldn't wanted that, you would use Node.js or even Java. Both are much more mature and XPlat than .NET Core now.

And, just to elaborate a litte bit more: .NET Core was cool and fast-paced at the early stages with project.json and all. And then, out of reasons of "compatibilty with .NET" project.json was taken from us in favour of Msbuild and .csproj again. And now the benefits of exactly this "compatibility with .NET" is also taken away, in favour of.. what exactly?

This is the basically the crux of the issue. Based on your assessment:

This new (ASP.)NET Core code we (painfully) wrote with a team over the course of the initial development of (ASP).NET Core.

You really just wanted the existing .NET Framework on linux with good old ASP.NET 4.x compatibility. Is that a fair summary?

davidfowl on 9 May 2017

Favor: Stability and compatibility is paramount. New features are nice, but when they land, they simply must not break the existing ecosystem.

.NET Core is actually a more stable platform than Desktop as it allows side-by-side execution where Desktop does not.

If you want to use newer features in the next version of Desktop you need to upgrade the entire machine to that new version and that effects everything on that machine, not just the app that wants to use the newer features. Which is fine if you have a dedicated server for a single purpose; but not if you have many apps running on the same server which upgrade at different rates (or never upgrade at all!)

benaadams on 9 May 2017

👍4

@davidfowl wrote:

It's up to frameworks to decide if they want to run on .NET Framework, UWP, .NET Core, mono etc. It's a choice. Orleans doesn't ship with .NET Core. ASP.NET Core does. Those products are one and the same.

In Orleans' case, we support .NET Standard 1.5 in our "2.0 Technical Preview" builds, but have been waiting for .NET Standard 2.0 so that we can make a stable release. At present I don't see any blockers for us - my concern is only about future divergence. That divergence has to happen at some point, though.

👍 Huge thank you for sticking around to answer everyone's questions, @davidfowl & co! It must be seriously stressful.

ReubenBond on 9 May 2017

👍4

NET full to move forward faster, as it doesn't put enough resources on .NET full to keep up with .NET core. Look at the amount of APIs added to .NET full in the past 2 years. Does that tell you a large team is working on that?

That's just not true. Things are continually ported to .NET Framework but as we all know the risk is considerably higher than making those same changes in .NET Core. Don't you all hate it when an update to .NET Framework breaks your application? We do too so we invent all kinds of processes to mitigate it, you wouldn't believe the strangle hold it puts on engineering to maintain it. We still manage to do features in-spite of all of it. That said, it will just never move as fast as .NET Core, it's a windows component that ships on the windows schedule.

that ignores the fact you can release the libraries _you_ depend on as netstandard2.0 packages so aspnet can run on .net full too. Additionally, making changes to .NET full isn't without risk, but please don't make it sound like it's a terribly organized pile of code where one change can make everything crumble.

We still manage to do features in-spite of all of it.

Yeah so does every other .NET developer ;) Once you release something, you're stuck with that API, we all have this. You however want to take a shortcut (like the ASPNET team has done many times before!) and move without that burden. But that's not going to fly in the end.

That said, it will just never move as fast as .NET Core, it's a windows component that ships on the windows schedule.

I think here we have the crux of the matter, right? The .NET core team can do what they want without communicating with the behemoth 'WinDiv'. Why doesn't Microsoft solve this internal politics crap in-house and make sure .NET full + .NET core are versioned / moving properly without the windows politics?

Btw, still interested in how you would sell SQL Server Enterprise's encryption API to .NET core 2.0 users.

FransBouma on 9 May 2017

Also, I must add; I'm pretty impressed how long this thread has been going, with so many people involved, while still remaining civil ❤️ That's not something you see every day on the internetz 👏 Maybe the .NET OSS ecosystem is growing up after all? 😉

khellang on 9 May 2017

❤35

that ignores the fact you can release the libraries you depend on as netstandard2.0 packages so aspnet can run on .net full too.

Additionally, making changes to .NET full isn't without risk, but please don't make it sound like it's a terribly organized pile of code where one change can make everything crumble.

It's big and has existed for a long time. Like any legacy system some parts are better than others. It doesn't make the code less reliable but it does make some parts practically impossible to change. There are so many fun stories veterans can tell you about how bug fixes in one areas broke obscure scenarios in applications in other parts. It's tangled, that's what happens when the dependency boundaries aren't well defined. You don't even have to believe me just go and browse referencesource.microsoft.com. In place updates are the reason we need to add a config switch for ever single potentially breaking change to .NET Framework. It's physics, it just can't move as fast.

Yeah so does every other .NET developer ;) Once you release something, you're stuck with that API, we all have this. You however want to take a shortcut (like the ASPNET team has done many times before!) and move without that burden. But that's not going to fly in the end.

We love shortcuts! Developers are lazy 😄 . We also want to genuinely improve our .NET Core without disrupting what .NET Framework represents. Maybe we should have renamed it to something else, like Sparkle 😄 .

I think here we have the crux of the matter, right? The .NET core team can do what they want without communicating with the behemoth 'WinDiv'. Why doesn't Microsoft solve this internal politics crap in-house and make sure .NET full + .NET core are versioned / moving properly without the windows politics?

Read my other answer about physics.

Btw, still interested in how you would sell SQL Server Enterprise's encryption API to .NET core 2.0 users.

That's not my area of expertise, I'll let somebody else answer that.

davidfowl on 9 May 2017

👍1

@khellang lol that is because GitHub issues haven't attracted MS hating trolls yet. Currently Twitter is their medium for that where there's no downvote yet :)

dustinmoris on 9 May 2017

@davidfowl

You really just wanted the existing .NET Framework on linux with good old ASP.NET 4.x compatibility. Is that a fair summary?

No, not really. Our client required complete new / shiny (micro) services, to supplement their existing .NET 4.x (they were 3.5 when we started) Windows desktop applications.

We when you went beta with all the shiny Core stuff, we started to write the new server-code for the all-new MVC on top of ASP.NET Core together with accompanying DTO, business logic and client-libraries, which are also being used in parallel in the existing 4.6 desktop applications to talk to the all-new-servers.

Also, some of the all-new ASP.NET Core servers don't run on Linux only, but also as windows services with Topshelf (on top of full 4.6 framework).

So the thing is, a lot of investment was done, and now we're seem to be stuck with .NET Core 1, as moving on to 2 (and losing netstandard) would also mean, we can't reuse the assemblies in the existing Desktop application (the services and accompanying libs were created for) anymore.

So the most important thing for us would be to still be able to use the new (ASP).NET Core libraries we write in .NET 4.6 desktop applications (because thats what they were build for), while being able to stay on a supported .NET Core version as long as the desktop .NET Version is supported, where the code can run on.

So, as long as .NET Core 1. is supported as .NET 4.6 is, and there is a linear upgrade path to a .NET Core x when .NET 5 comes out, and .NET Core x code is capable of running on .NET 5, then we're fine.

gingters on 9 May 2017

@gingters Are you using .net features not in netstandard2.0 on the asp.net services?

If not then the libs should just work. But I'm guessing you're talking about stuff not in netstandard2.0.

hallatore on 9 May 2017

@davidfowl Will c++/cli dlls work on netcoreapp 2.0? We have old 3rd party C++/CLI assemblies which will not be replaced any time sooner.

qrli on 9 May 2017

@davidfowl wrote:

ASP.NET Core 2.0 honestly doesn't have that many new features

In which case, why this highly disruptive change now?

idg10 on 9 May 2017

👍15

@qrli C++/CLI does not work on CoreCLR. Here's some background on why it won't be supported: https://github.com/dotnet/coreclr/issues/659#issuecomment-91341753

gulbanana on 9 May 2017

Give 4 years support to 1x (porting as much possible from 2x) and go ahead and fast with 2x. A city car for slow city traffic and a Ferrari for the highways. We have a lot of competition outside of .net world.
If ASP.Net Core succeed, I am sure MS will give the resources to support the 1x for 4 years. Mostly the culture will change.

stefan2410 on 9 May 2017

👍2

@idg10 It's really not. 2.x is pretty much 1.x with performance stuff that are only available in core. I think only major feature is Razor Pages.

So being on version 1.x doesn't mean you are on an outdated version. But this hasn't been communicated very well.

hallatore on 9 May 2017

👍1

In which case, why this highly disruptive change now?

guess this pretty much summarizes it https://github.com/aspnet/Home/issues/2022#issuecomment-300141134

Bartmax on 9 May 2017

@hallatore
I know it works, as it does _now_. We can stay on 1 for now. The problem is going forward. When we want (or worse: need) to upgrade to (ASP).NET Core 2 libraries (i.e. when 1 goes out of service, and there's a critical security hole fixed) we face the problem that we can't upgrade, as this would make it impossible to use our libs that need the upgraded packages in the .NET desktop apps.

Edit / add: Unless there will be a new full .NET framework that is capable of running the new, fixed .NET Core libs that is on a linear upgrade-path for the existing legacy desktop app.

gingters on 9 May 2017

@gingters Not sure I understand.

If your desktop libs work with netstandard2.0 they should also run on core. (if they invoke wpf stuff etc they won't of course)
If this is the case then you should be able to use asp.net core 2.0.

If your desktop libs crash on core because they use stuff not in netstandard2.0. Then I see why you need to stay on 1.x. And I see why the short EOL is a problem.

Would 1.x be a easier/better choice if you knew 2.x only contain mostly core perf stuff (Meaning 1.x is not outdated vs 2.x). And that 1.x will get patches and be supported for * years?

hallatore on 9 May 2017

@hallatore It's the other way round. Old application: Mix of Windows Forms, WPF, C++/CLI, normal C++, DirectX, millions lines of code etc. pp, running on 4.6 full framework.

On .NET Core: New business logic libraries (using also other libs, i.e. the .NET Core version of Serilog), abstractions libs + services + client libraries for these services. Services need to run on Linux and as windows services (currently Topshelf on full .NET 4.6 framework, as soon as windows service support lands in Core that could be changed, though).

Now the new business logic and abstractions as well as the service client libraries are also consumed from the .NET 4.6 applications. This means we are not capable of upgrading them, as they will need to run on the full .net framework as long as the desktop app does (which we can assume will be pretty much for as long as a desktop can live, unless full framework goes away in general).

gingters on 9 May 2017

@gingters You can still have the shared library projects in your solution targeting netstandard _min(usable)_ and consume those libraries from your ASP.NET Core 2.0 code as well as packaging them up to be used from WPF, Xamarin, UWP, whatever.

markrendle on 9 May 2017

it is really sad that you MS guys still do not get the point. you still think it is only api gap issue. you still think people can just modify their code and it will work on netcoreapp... i thought you understand enterprises much better than google.

qrli on 9 May 2017

👍2

Based on that, it seems like MVC 5 on mono is what you really wanted right?

@davidfowl I mean, come on. That's a dismissive and frankly insulting answer. Can anybody at MS confirm that a single dev is even assigned to Framework ASP anymore? I'm not trying to be a jerk here, but it seems like sometimes the community is talked down to.

There's no reason under the sun that I should consider .Net Core and ASP.Net Core to be the same product. There hasn't been any messaging to support it at all. Especially when you consider that Mono came under the Microsoft wing _after_ the .Net Core announcement. It has always been messaged as the smaller, nimbler, xplat version of .Net. Not only that, but we all remember the days when ASP.Net Core was actually ASP.Net 5 and was going to work everywhere. Heck, that change is just over a year and half ago only.

Is the self-hosted HTTP story in netstandard20 effectively "use Kestrel 1.x"? I'm not sure the Nancy folks are going to care hugely for that, and neither do I. ASP.Net 2.x may be incremental feature-wise, but Kestrel 2 has a serious perf benefit that we could seriously use the day it comes out.

mattnischan on 9 May 2017

👍1

@davidfowl

It's big and has existed for a long time. Like any legacy system some parts are better than others. It doesn't make the code less reliable but it does make some parts practically impossible to change. There are so many fun stories veterans can tell you about how bug fixes in one areas broke obscure scenarios in applications in other parts. It's tangled, that's what happens when the dependency boundaries aren't well defined.

I think this is an interesting comment. I remember watching an older NDC conference session recording with @davidfowl and @DamianEdwards picking apart of the legacy cruft in ASP.NET 4 that you really wanted to leave behind - it was really fascinating to get peek inside that black box of code.

But I think this comment also mirrors the concerns many of the us have with our own codebases. We maintain large legacy systems, often not well designed with poor dependency boundaries. It's practically impossible to rewrite some of these systems for .NET Core. The business simply won't allow the risk of that much change.

I don't know what the right answer is. But I know that for our own applications, we'll be using the full framework and ASP.NET4/MVC5 for the foreseeable future (we still have a chunk of WebForms won't be rewritten for quite some time!). I hope to see MVC5 get some love now that it's _finally_ moved to GitHub - I'm even willing to donate my own time and effort to make it better (e.g. better async support, performance improvements, etc.).

jdaigle on 9 May 2017

👍3

@qrli Enterprises still have full .NET 4.5 to run on their Windows Server 2008 R2 IIS 7.5 Web Farms. Nobody's taking that away from them.

markrendle on 9 May 2017

@mattnischan

Is the self-hosted HTTP story in netstandard20 effectively "use Kestrel 1.x"? I'm not sure the Nancy folks are going to care hugely for that, and neither do I.

HttpListener is part of netstandard20 therefore also netcore20 nothing is being taken away on that front by going netcore20.

benaadams on 9 May 2017

HttpListener is part of netstandard20 therefore also netcore20.

And I suppose I can expect the same requests per second from HttpListener?

mattnischan on 9 May 2017

@markrendle True. For now.

But what would you suggest when one other libraries used by our shared stuff (i.e. serilog, newtonsoft, autofac etc.) drops support for netstandard_min(usable), (maybe just because they feel its too much of an effort to support both worlds) and there is a critical security issue detected in the latest version that still supports full framework?

gingters on 9 May 2017

@mattnischan

HttpListener is part of netstandard20 therefore also netcore20.

And I suppose I can expect the same requests per second from HttpListener?

Ok then, Nancy is .NETStandard 1.6 so you can use it on Core 2.0 and use Kestrel 2.0. Better?

benaadams on 9 May 2017

@gingters I would suggest crossing that bridge when you come to it.

Never let the future disturb you. You will meet it, if you have to, with the same weapons of reason which today arm you against the present.
_~ Marcus Aurelius_

markrendle on 9 May 2017

That is not as useful a mantra when delivering software which has no maintenance budget and must be used largely unchanged for years to come.

gulbanana on 9 May 2017

👍1

If it must be largely unchanged for years to come then why does it matter what happens to the libraries it depends on in those years to come?

markrendle on 9 May 2017

👍1

@markrendle Now just assume you are required, by law (at least in some countries), to provide emergency protocols for exactly these cases, before a version of the application ships, as it might be used in environments where people's lives might be at stake.

gingters on 9 May 2017

👍1

So you want a web server that is as fast as Kestrel, and your only specific requirement is that it is not Kestrel?

Ok then, Nancy is .NETStandard 1.6 so you can use it on Core 2.0 and use Kestrel 2.0. Better?

@markrendle @benaadams No, I think you misunderstand, and again, not trying to be a jerk, just pointing out that there are other customers of pieces of ASP.Net Core that aren't the whole thing. I'd just like to host our production platform on top of Kestrel 2.0 when it comes out, and our production platform might be on Framework for a while. I can't target netcoreapp20.

Nancy may be netstandard16 but it doesn't matter because I can't use Kestrel 2.0 except on Core 2.0. I realize this is specific, and maybe the answer is truly "then write your own webserver that works on framework that's as fast as Kestrel 2. Kestrel is for ASP.Net only." But I'd hate for that to be the message.

mattnischan on 9 May 2017

@gingters @gulbanana I don't understand how a shipped application with a fixed set of dependencies is going to break because an open source project stops supporting an arbitrary version of the underlying framework at some putative future date.

markrendle on 9 May 2017

@mattnischan Yes, I figured out what you meant and deleted that comment :)

markrendle on 9 May 2017

👍1

@stefanolson

Because I need to share code between the server and my desktop applications does that mean I can never have the latest version of ASP.Net?

If you target .NET Standard with your libraries, you can use them in both Desktop and Core. For libraries target .NET Standard, then you have universal platform support: Desktop, Core, Mono, Unity, UWP, Tizen etc

An ASP.NET application is an executable; the end point, it isn't a library. The final output, the ASP.NET application/executable needs to run on a platform. Eventually any of its platform libraries will be consumed by the ASP.NET application so there is no advantage to them not being the same target as the platform.

.NET Core is a good platform as it has a broad cross-platform coverage; can be installed side-by-side with Desktop and can be upgraded independently app by app; rather than whole machine and every app.

Some items do have uses outside; so Wyam uses Razor for static site generation; Razor is currently .NET Standard 1.3 so consuming it outside Core isn't currently a problem.

There are some edge cases mentioned above:

Using libraries which don't support the .NET Standard 2.0 feature set. A lot of them are hopefully gaps that can be filled - and at the start of this issue MS were asking what those gaps were so they could prioritize them.

Running a WebApp embedded in for example a UWP app; however if Desktop was still supported but changed to version 4.7.1 you'd still be in the same situation as UWP doesn't currently support 4.7.1 and by the time it did ASP.NET would require 4.7.2, then 4.7.3 etc. It would be a Sisyphean task as the other platforms would never catch it; so it would just be busy work without much point?

benaadams on 9 May 2017

👍4

Yes, I figured out what you meant and deleted that comment :)

No worries, good sir. 👍

mattnischan on 9 May 2017

@davidfowl

How does ASP.NET Core revving versions affect that? If we dropped .NET Framework support in 3.0 (as people seem to be eluding to in this thread), wouldn't you be in that same dead end regardless? You'd have your ASP.NET Core 2.0 application ported running on framework for a year and when 3.0 comes out, you'd be unable to upgrade. You would be able to do this anyway with ASP.NET Core 1.1.x which runs on .NET Framework and is supported even when ASP.NET Core 2.0 is out.

Just saying (as I understand) that "sometime we needed to break with full .net why not right now" is missing an important point. I'm sure that lots of people was waiting for the release of core 2.0. Because it's publicly promised a lot of improvements in compatibility with full .net. So many libraries authors are also waiting to start migration to core. So I guess that after core 2.0 released we'll much more migrated libs on Core. And so binding asp.net core to core 3.0 would be much less frustrating for ecosystem then it's right now. Because at the moment of 3.0 these should less blocking things from migrating to core.
Right now it's a disaster.

Previously I was assessing starting migration of our framework (very similar story to what @benaadams described) onto core/asp.net core in two steps: migrate web part (which is on mvc/webapi now) onto asp.net core and keep full .net and then migrate all other stuff on core when all dependencies will have corresponding implementations for core. Currently what blocks us is Oracle ADO provider and Postgres ADO provider (there could other incompatibilities in corefx we didn't dig into it yet). Now this plan is dead. So we have to sit and wait for migration of dependencies abandoning all new stuff in Core world. And all this is only because of the fact that someone in MS decided that we need "moving fast" platform.

evil-shrike on 9 May 2017

👍9

@markrendle The application is not going to break just because of that. The issue is a different one:
Because .NET Core 2 dropped support for the full framework (where it ran fine on in version 1, and it's from Microsoft where you don't expect such a basic, elementary feature to be dropped when updating to a new version), also your dependencies might drop support for this scenario rather sooner than later.
Someone finds a critical security issue in one of the libraries used, and no update is issued for the version you are stuck on, as newer versions don't support your runtime anymore. Now, since your application is used in a very regulated environment you need to provide an emergency plan that explains what exactly you will do when an critical security issue is detected and how to roll that fix out to prevent people from getting hurt or worse. A "well, we can't do anything" will result in revocation of your allowance to ship that application.

gingters on 9 May 2017

👍2

@gingters Look, the point is, you have to make your tech choices based on the information that is currently available and the nature of the marketplace in which your company operates. With the best will in the world, you can't account for all eventualities, however much the bureaucrats and regulators of the world would like to pretend that you can. What if Microsoft are acquired in a hostile takeover by Apple and .NET is discontinued entirely in favour of Swift? What if strong encryption is made illegal in one of the countries you sell to, and all software stacks that include SHA256 are banned? What if Nicolas or James or _insert-name-of-Autofac-maintainer-here_ decide to move to Mars and become moisture farmers? What if the magnetic poles reverse and every single bit of digitally-recorded data is wiped?

As an actual answer to the question of what you, as a company, say you will do in the event of a critical security issue being found in JSON.NET (for example), in the absence of an official update being available, the only possible answer is "we will fork-and-patch JSON.NET", which I'm guessing is already the answer to the question of what you would do if James Newton-King were to become indisposed for any reason. In my previous experience working in those kinds of markets, there were escrow arrangements for the source code to proprietary packages for that sort of eventuality; what to do about open source packages is trivial by comparison to that.

markrendle on 9 May 2017

❤1

And all this is only because of the fact that someone in MS decided that we need "moving fast" platform.

"moving fast" might be overstating it; going by the previous release schedule of Full Framework it might be better stated as "without adding an extra 1 - 2 year delay" into shipping. That's a crazy amount of time in the web world.

Things are changing fast and the platform needs to stay relevant.

benaadams on 9 May 2017

👍9 👎2

@davidfowl and @DamianEdwards I think that this whole confusion came from the fact that ASP.NET Core 1.x can run on .NET Framework. This created the assumption that ASP.NET Core was the evolution of ASP.NET 4/MVC5; making people migrate to it thinking that they would get all the benefits (speed and new features) while keeping the backward compatibility.

So maybe the long term / permanent answer to this issue is to re-promote ASP.NET 4/MVC5 as the answer for people seeking backward compatibility with long term support (and maybe offer to make small improvements as well).

Then, ASP.NET Core can focus on being a new platform that breaks away from the past to offer huge benefits, for those who can make the jump.

In that light, (ASP).NET (Framework) and (ASP).NET Core will be two parallel and equally valid roads that customers can choose. And I think this is the way things should have been from the start.

KPixel on 9 May 2017

@markrendle Yes, this is hypthetical, but bureaucracy sadly is a real thing. And yes, you can't (and don't need to) account for all eventualities. Just for the ones you can anticipate.

And now we have the situation that a) dropping of a complete platform (.NET full framework), which was supported in .NET Core 1 just fine, wasn't something you could anticipate. However, since it happened now you can b) anticipate the drop of support for v1 in your other dependencies with a pretty sure "yes, I can totally see that happen rather sooner than later".

And yes, forking and backporting fixes is one of the possible solutions, however this is something you want to avoid as much as you can. If the .NET Core team had said something like "Hey. Look, we don't intend to run on full framework, don't rely on that", or even better never had made that possible in the first place, this whole discussion wouldn't be necessary as the customer just would not have opted to invest in new stuff on top of .NET Core in the first place.

gingters on 9 May 2017

@gingters I thought we were at the point where you were happy running your ASP.NET Core web bits on .NET Core 2.x or later, and using .NET Standard 2.x for sharing libraries between Core and Full/UWP/whatever. Because if these libraries were to drop support for .NET Standard 2.x in favour of just .NET Core 2.x, then they'd be dropping support for full .NET too, and you're hosed either way.

markrendle on 9 May 2017

@markrendle Up to the point where we have a critical issue in one of the ASP.NET Core bits we need to use in the shared stuff after 1x isn't supported anymore.

gingters on 9 May 2017

@gingters luckily it's open source and you can support yourself (or pay a 3rd party) if need be!

adamhathcock on 9 May 2017

@markrendle no. pure legacy projects are dead ones. enterprise projects are usually a big mix codebase which contains code/libs date from decades ago to fresh new. being netcoreapp only means you removed the ability to mix. so we can no longer move to your fancy new version but locked down to the old version. and the anti-ms workmates will happily say to me "i told you..." and then pushing us to migrate to google solutions.

qrli on 9 May 2017

👍6

i'm not arguing for supporting netfx forever. but i strongly feel netfx should be supported by asp.net core for at least 2 years from now. not only 1.x but also 2.x.

qrli on 9 May 2017

👍1

@qrli Those "enterprise projects ... big mix codebase which contains code/libs date from decades ago to fresh new." are everything that is wrong with enterprise projects and needs to stop. Complaining that a new technology stops you from throwing more hunks of mud into a big ball of despair held together with shims, baling wire and denial is like complaining that a new industrial laser cutting machine comes with safety features that stop you leaning in and cutting off important bits of yourself.

markrendle on 9 May 2017

👎4 👍4 ❤2

@benaadams

"moving fast" might be overstating it; going by the previous release schedule of Full Framework it might be better stated as "without adding an extra 1 - 2 year delay" into shipping. That's a crazy amount of time in the web world.

Things are changing fast and the platform needs to stay relevant.

This is a political/organizational limitation, not a technical one. Look at how the JVM / Java is moving. If they're moving at all. Still relevant, much more than .NET is today. So 'moving fast' isn't the reason people choose Java/JVM. On the contrary. They pick Java/JVM because it lacks all the downsides associated with 'moving fast': it's a stable, dependable platform, where your investment isn't wasted in 1-2 years.

I don't know, if MS wants to move .net full fast, it will move fast. They own it, they can decide what to do. But the powers that be don't really give much about that: .net full is 'good enough' for where it is now.

MS has slept at the wheel for many years and now all of a sudden things like performance and memory pressure are important (they are, no doubt about it), while in JVM land investments in those particular aspects of a runtime have been done for many years and that pays off.

I don't know what the solution is, short term, but in the long term, leaving .NET split across two major departments (.net full with windows, .net core with devdiv) with no common ground/goals other than the same employer doesn't bode well for us outsiders.

FransBouma on 9 May 2017

👍10

While there are many points being made here, and everyone is trying to make sure they understand others viewpoints, solutions like "big enterprises shouldn't be like that" aren't going to help. Even if you could convince them of that, it would take them 20 years to stop being like that, because they're big enterprises.

kolektiv on 9 May 2017

👍4

@kolectiv That's true, but accepting that enterprises aren't suddenly going to stop being enterprises doesn't mean you have to actively encourage/enable that sort of behaviour.

It also shouldn't mean that _my_ applications have to run more slowly and cost more to host.

markrendle on 9 May 2017

Running a portability analysis on our heavily used libraries that still target .NET 4.x on ASP.NET Core 1.x (EF6, NHibernate, NServiceBus) and man, these libs aren't even close to being able to target netstandard20.

Lib | Pct
---------- | ---------
EF6 | 62.74
NHibernate | 67.39
NServiceBus | 65.68

And still huge gaps in missing APIs. EF Core still has a large gap with EF6, and we still use NHibernate when there are major features there that don't exist in EF6. NServiceBus we use on any project that does messaging.

Whew.

jbogard on 9 May 2017

👍12

@markrendle

Those "enterprise projects ... big mix codebase which contains code/libs date from decades ago to fresh new." are everything that is wrong with enterprise projects and needs to stop. Complaining that a new technology stops you from throwing more hunks of mud into a big ball of despair held together with shims, baling wire and denial is like complaining that a new industrial laser cutting machine comes with safety features that stop you leaning in and cutting off important bits of yourself.

Yeah man, let's tell those pesky Enterprises and large organizations to do things differently, cut the wire! stop the mud flood! That will make them wake up and listen. Oh wait, that won't help, as they already know that but have to work with a lot of things you don't care about or ignore for your own argument.

Look, no-one says 'new tech: bad!'. It's about pursuing new tech without realizing the consequences that brings with it. We all like to work with the newest bits and not have to worry about old cruft, who wants that? Reality however tells a different story. If you only have to work with the newest bits and don't have to care about old shit, good for you! Sadly we sad work drones in the trenches have to live with a different reality. It would suit you if you at least acknowledge that for a LOT of people reality is just that, they can't change it, they can't make a different future, it's what they have to work with.

FransBouma on 9 May 2017

👍7

@markrendle I'm not quite sure what you're suggesting? Abandoning our 15 million lines of working C# code and write it all afresh? We were looking at transitioning (slowly) to netstandard 2.0 and hopefully getting access to things like Span etc when it came along, but issues like this make me doubt that is wise.

We'd like Linux support but this feels more like a divergence. I'd assumed netstandard was going to move ahead with the most advanced implementation and then things like the framework would catch-up, but at least we'd know it would.

bencyoung on 9 May 2017

👍3

@FransBouma So we should all suffer because Enterprises want to do stupid things? I shouldn't get nice things because multi-million dollar public sector projects aren't ready for them yet? How does that work?

markrendle on 9 May 2017

@markrendle What's stupid about wanting to keep working code?

bencyoung on 9 May 2017

👍7

They pick Java/JVM because it lacks all the downsides associated with 'moving fast': it's a stable, dependable platform, where your investment isn't wasted in 1-2 years.

And you can use System.Web basically forever; its baked into Windows which means its likely never going to go away. You don't get much stable and dependable than that.

ASP.NET Core 1.x -> ASP.NET Core 2.x; all the apis are pretty much the same the main change is dropping support for .NET Framework. It even changes semver for the break 😱

ASP.NET Core 1.x runs on .NET Core 2.x and .NET Framework, supports .NET Standard 2.x (via .NET Core 2.x); and has the same apis as ASP.NET Core 2.x, So that's the stepping stone release.

ASP.NET Core 2.x is the break release. It still supports .NET Standard 2.x (via .NET Core 2.x) and not much api-wise has changed between ASP.NET Core 1.x and ASP.NET Core 2.x; but drops .NET Framework.

benaadams on 9 May 2017

👍8

Could an alternative be:

ASP.NET Core go ahead and work towards something like netstandard3.0 (could be 2.x) and just version netstandard faster. Like once a quarter.
NetFx next release could jump again to support netstandard3.x whenever the next release is. It wouldn't even have to be the newest standard.

This might be a bad idea because everything used might not need to be part of netstandard but at least ASP.NET Core 2.x would target a standard that the other frameworks will use eventually.

Just spit-balling. I'm sure this has been brought up.

adamhathcock on 9 May 2017

👍3

@bencyoung I'm merely suggesting that it's a bit selfish to insist that the entire world should revolve around your 15 million lines of working C# code (which isn't going to stop working, btw). So you can't use ASP.NET Core 2.0. You've still got the full Windows-only framework ASP.NET which has legacy support running through it like Brighton through rock. So there's a new toy you can't play with because it's not economically viable for you to port your code and refactor/rearchitect your application. That sucks, but so do lots of things. But if Microsoft avoid everything that's not going to work for pre-existing two-decade-old legacy codebases that probably still include COM components written in VB 6.0, then in another 20 years they'll be Micro Focus.

markrendle on 9 May 2017

@adamhathcock That's what I'd assumed netstandard was for - a unification approach, rather than a least common denominator. It can move as fast as it wants, but they'd be a commitment that .NET framework would eventually catch up. Eventually there'd be a netstandard that basically was the .NET framework minus the platform specific stuff and then it would be unified

bencyoung on 9 May 2017

NetFx next release could jump again to support netstandard3.x whenever the next release is.

A .NET Framework update is a forced update for every machine on the planet running Windows (mostly).

A .NET Core update is a update you for an individual application choose to take.

They are very different beasts.

benaadams on 9 May 2017

👍3

Well, one easy thing to do would be to stop linking to this page from the very first page of the ASP.NET Core docs.

(Or simply add a line "Don't choose .NET Framework if you want to continue to use ASP.NET Core!".)

dahauns on 9 May 2017

👍7 😄2

they'd be a commitment that .NET framework would eventually catch up.

There is https://github.com/aspnet/Home/issues/2022#issuecomment-299609207

our promise generally is: if the type is shared between .NET Framework and .NET Core, we intend to port newly added members to .NET Framework. In very rare cases this might not be possible, but the stake in the ground is that they are automatically considered.

But by the time it catches up, ASP.NET will have moved on to the next .NET Standard version and it would never be the right version of .NET Framework for ASP.NET; it would always be behind.

benaadams on 9 May 2017

@markrendle no, they are not big mud ball. big mix does not mean they are bad architected. they are modular. it is that many modules are battle-tested code written long long ago by really smart people or bought from 3rd party. some is by c, some is in fortran, some in c++/cli, etc. to migrate or rewrite, we need to understand them, read papers, gather more real test data, retest the new version. it takes effort but such tasks are never budgeted, but up to ourselves. business people do not care we use .net core or not, but they want the features done. and for 3rd party, we have to urge them or seeking for replacement.
so, it can take a few years in practice.

qrli on 9 May 2017

@benaadams

And you can use System.Web basically forever; its baked into Windows which means its likely never going to go away. You don't get much stable and dependable than that.

ASP.NET Core 1.x -> ASP.NET Core 2.x; all the apis are pretty much the same the main change is dropping support for .NET Framework. It even changes semver for the break 😱
ASP.NET Core 1.x runs on .NET Core 2.x and .NET Framework, supports .NET Standard 2.x (via .NET Core 2.x); and has the same apis as ASP.NET Core 2.x, So that's the stepping stone release.
ASP.NET Core 2.x is the break release. It still supports .NET Standard 2.x (via .NET Core 2.x) and not much api-wise has changed between ASP.NET Core 1.x and ASP.NET Core 2.x; but drops .NET Framework.

Yes, and let's see what the options really are :) ASPNET Core 1.x is a dead end: you can port to that but your code can't move to .net core if you depend on libs which are .net full today and might not be ported to .net core /standard when support ends. Choosing ASP.NET core 1.x now is only wise if your dependencies are already on netstandard2.0/.netcore, then you can move to asp.net core 2.x without problems, knowing you are not running into a dead end.

Your suggestion to choose system.web as an alternative to nginx and a JVM stack if you want to have stability is a bit weak, don't you think? :) It's about options for a large org what to pick as platform. Unless they're creating an app that's completely new and doesn't have to work with outside dependencies (rare) they'll likely take the safe bet, and why wouldn't they? If it then comes down to system.web or JVM/nginx the choice is pretty simple.

It's the little things. I hammered on it before: sql server enterprises' encryption features. You're not going to use these on .net core as they're not there. Oracle? nope. So if you want to use asp.net core and these features, you have to use .net full and asp.net core 1.x. But what happens if these features aren't ported/available when support for asp.net core 1.x ends? (and who wants to bet the farm on a platform which is in 'QFE mode' already?) Back to system.web?

FransBouma on 9 May 2017

👍1

It seems to me that part of the issue is that ASP.NET is directly driving the evolution of .NET Core. I guess that's an internal thing in Microsoft, but really the platform and a specific library should not be so tightly coupled.

If something new needs adding to a version of .NET then it should be made available to everyone via a netstandard bump (with vNext) and then ASP.NET updated to use it when it is released. It's the privileged position of ASP.NET that causes this issue I think. This may be unavoidable due to the groups of developers inside Microsoft being the same...

As a writer of HPC software that uses .NET heavily we've also implemented our own zero allocation parsing etc without changes to the underlying platform. Would we benefit from Span etc? Absolutely! Can we switch to .NET Core? Not for a long time. Will we see Span etc added to .NET Framework? Seems hard to say now without it being a netstandard commitment...

bencyoung on 9 May 2017

👍17

@markrendle Sure, but what's our transition plan? I can't see one that doesn't hit unsupported paths. If the changes were in netstandard and then ASP.NET Core used them then at least we'd know there was a path through eventually....

bencyoung on 9 May 2017

@markrendle i'm not sure who are the intended users of asp.net core. but what i saw are mostly .net users who have big investment in .net and big legacy (not bad) codebase. if we are not the intended users, i dont see node.js/python/go guys give .net a sh*t, no matter how good we think .net is.
if it is not for company but for my own projects, i will not use asp but use nancy instead. companies need stable guarantee and support. and they/we pay big money for it.

qrli on 9 May 2017

The easy solution to this problem would be, if Microsoft would make a Windows only distribution of CoreCLR that supports the full range of .NET Framework libraries.

The personal side in me is cool playing with .NET Core on the PI on ubuntu but the business side didn't even consider .NET Core because .NET Framework does everything we need and .NET Core is only trouble in comparison. Most of this trouble was around tooling and getting everyone setup'd so those pains are finally going away, but it still lacks so many features... EF Core isn't even close to being mellow enough to substitute EF6 or NHibernate and they won't run on .NET Core 2 either. The lack of WCF (host) for SOAP Services is quite a burden, since its what we do all day in business communication, but could probably be migitated through clever design and using .NET Core and .NET Framework in multiple apps. AppDomains are also not easily replaced although thats the least of my problems. The leap from ASP.NET MVC 5 to MVC Core was unexpectedly easy for a rewrite but going .NET Core makes VS stop cooperating, displaying all the errors.

Fun things like hosting ASP.NET Core inside WPF will also be impossible.

It wouldn't even matter if the Windows CoreCLR distribution would be closed source since its not much different from .NET Framework today.

Now excuse me while i quietly weep and delete my experimental branches that were migrated to ASP.NET Core.

Suchiman on 9 May 2017

Your suggestion to choose system.web as an alternative to nginx and a JVM stack if you want to have stability is a bit weak, don't you think?

Its the extreme end ;)

If it then comes down to system.web or JVM/nginx the choice is pretty simple.

Yeah, if you can go JVM, you use ASP.NET Core 2 as you don't have blockers and it has nice interop and p/invoking :)

if the apis are "pretty much the same", why don't you keep one version numbering 2x for all, but having option to select for "netstandard" or"netcore"?

Because its the internals that are changing; and making use of changes to the runtime, jit and standard libraries. To a user they appear mostly the same as that's where the compatibility is between ASP.NET 1.x and 2.x; on the exposed api surface, not the internals "here's how its done".

It seems to me that part of the issue is that ASP.NET is directly driving the evolution of .NET Core.

As are other people. You can make an api request over at dotnet/corefx as I did for example for ValueTask; which then evolved into Task-likes and is now part of C#7.

As soon as your api is included in .NET Core you can the start using it (if you go for nightlies and want to make sure the api is right); or at the next release of coreclr/corefx if you want to hang on 6 months.

and then ASP.NET updated to use it when it is released.

Now you have to wait 2 years. That's not really practical; as the apis will need refinement through use; and through use more discovery will happen. That's like adding a 2 year compile step to your development cycle.

As a writer of HPC software that uses .NET heavily we've also implemented our own zero allocation parsing etc without changes to the underlying platform. Would we benefit from Span etc? Absolutely! Can we switch to .NET Core? Not for a long time.

Is your HPC software directly hanging off web requests? At a guess it might have queues driven by webrequests, but it runs in a separate process so should be unaffected by this change?

Will we see Span etc added to .NET Framework?

Yes

benaadams on 9 May 2017

@benaadams

But by the time it catches up, ASP.NET will have moved on to the next .NET Standard version and it would never be the right version of .NET Framework for ASP.NET; it would always be behind.

Which is completely fine and acceptable, if there is at least 1 version overlap (i.e. if you stay on the latest full framework there is still at least one officially supported (ASP).NET Core version around running on that).

gingters on 9 May 2017

👍1

Microsoft would make a Windows only distribution of CoreCLR that supports the full range of .NET Framework libraries.

Or a set of .NET Standard 2.0 libraries; so they can run on .NET Core, that only run on Windows that cover the api gap?

benaadams on 9 May 2017

👍4

@benaadams yeah thats the idea, although that won't work for anything that throws PlatformNotSupportedException

Suchiman on 9 May 2017

@qrli If it's modular, then you can upgrade the modules that can be upgraded now, and leave the rest until later.

Unless by "modular" you mean "it's a massive monolithic System.Web ASP.NET IIS application comprising dozens of different libraries interoperating via PInvoke and COM" in which case, that's a big ball of mud.

markrendle on 9 May 2017

👎8 👍1

Is there a final list of which assemblies are affected and which are not? It has been mentioned that Microsoft.Extensions.* is safe and Microsoft.AspNetCore.Razor.Runtime (assumed) too, thanks to which Microsoft.AspNetCore.Html.Abstractions needs to stay on netstandard also. Is there anything else in the Microsoft.AspNetCore.* that is staying on netstandard?

Kukkimonsuta on 9 May 2017

@bencyoung My recommended transition plan is to migrate various components over time to standalone services targeting .NET Core 2.x (or whatever works best out of the entire universe of development tools for that particular component), consuming those services from your legacy code over a standard API boundary using HTTP or a message bus, until you've got a proper distributed system architecture.

markrendle on 9 May 2017

@markrendle Not everything belongs in a distributed system though. As a concrete example: a large part of why Stack Overflow renders pages so fast is that it's not distributed. Though our network latency is 0.017ms, that would add quite a bit of network, serialization, deserialization, and GC cost to our application. Sharding a system out into many services it not a universal answer. It's a complicated one, a costly one, and a net negative for a many scenarios as well. It may be a good thing, but it can also be an over-complicated bad thing.

NickCraver on 9 May 2017

👍27 ❤6

@markrendle my issue isn't one of migrating to services, it's that some of the fundamental service infrastructure building blocks use APIs that aren't on the roadmap for netstandard20 or even netstandardbanana. .NET Core for us isn't about greenfield applications, it's about entire greenfield systems. System.DirectoryServices is one example but for others, it's WCF, and more others, it's System.Data and the SqlClient stuff, and for us, System.Messaging.

I'm all for using .NET Core when I can. So far that has included zero client projects, greenfield or not, they're all blocked on something.

jbogard on 9 May 2017

👍16 😄1

@NickCraver I don't mean to be facetious or anything, and I know that the real reason that SO pages render so fast is that you and the other people who build it are amazing, but the Google search results that include links to your pages render just as fast as your pages, and you _know_ they're coming from a big, complicated distributed system. Amazon pages render pretty fast, same deal. I'm optimistic that ASP.NET Core is driving towards a future where it can be used to build systems the same way those are built, with the same performance, and I think it's got a better chance of getting there if it frees itself from the turning-a-small-island update cycle of full .NET.

markrendle on 9 May 2017

👍6

@jbogard I see similar, but that'll be very different when .NET Core 2.0 is out.

markrendle on 9 May 2017

Sigh.

chadwackerman on 9 May 2017

👍7

@jbogard

netstandardbanana

quote of the thread

penderi on 9 May 2017

😄13 👍1

The main issue with this, for me and my team, is that there was no indication that this path was the intended future. I get no one knows the future but hearing that we need to break out anything that relies on full .net framework (component vendor dlls, payment services sdks, HSM sdks) into their own services and introduce that new hop STINGS. It just isn't something this site needed and now we have to either introduce more dev ops complexity or re-do the web app portion to MVC 5.

We went with asp.net core for the speed of kestrel and the fancy new API. It would have been nice to be able to more accurately weigh the options against the lack of an easy upgrade path given our dependencies.

jabrown85 on 9 May 2017

👍18

Adding to @jabrown85
ASP.NET Core has been a rollercoaster of emotions thus far.
After csproj landed i finally went "it's ready now" and considered it a no brainer to start anything new in it and checking what can be upgraded. After this announcement, its more like: "does .NET Core definitely support the scenario or should we go safe and just stay with MVC5?"

Casualties are low so far, only one application written in ASP.NET Core that manages the administrative tasks of the primary MVC 5 app, but it will be stuck on 1.x forever because the main app uses NHibernate.

Suchiman on 9 May 2017

@markrendle computer says no

It'd be nice if there were some roadmap for full .NET -> netstandard. Some of the fundamental pieces just say "Not Supported" from ApiPort. I'll be running fuller analysis of the client projects on ASP.NET Core 1.x to see what's missing.

jbogard on 9 May 2017

but it will be stuck on 1.x forever because the main app uses NHibernate.

Shouldn't be, NHibernate isn't dead is it?

benaadams on 9 May 2017

@benaadams surprisingly no. There are a few things that it does that EF6 really doesn't have any equivalent. We default to EF6 but there are cases where we have to go the NH route.

jbogard on 9 May 2017

@benaadams officially no, it has pauses where it seems almost dead but usually theres one commit every few days. ApiPort reports 72.26% coverage for .NET Standard but i'm not really convinced that it will be ported (in the near future at least).

Suchiman on 9 May 2017

Reading the comments, I am concerned about the general direction this project is heading. For a long time ASP.NET was a good choice for a stable and solid technology. However, I don't get the same feeling now. There are many "move fast and break things" technologies, but that's a whole different category.
I hope that Microsoft will be able to address those concerns and align everyone's expectations.

It's not about enterprise vs. non-enterprise software. There are plenty of Python 2.x applications in use today and not all of them are "enterprise". What's more - not all new projects use Python 3 (almost 9 years after the release of Python 3.0!).

jvitkauskas on 9 May 2017

👍10

Can anyone summarize the whole thread in a blog post?

I've read through all 300+ comments while on commute/lunch and ... I still seem to not "get it" completely.

What I get is:

The full .NET Framework won't be supported on .NET Core 2
Every dependency will depend on netcoreapp2.0 instead of netstandard2.0
If I want something like DirectoryServices or Drawing, I need to drop Full Framework and jump to 2.0

I kind of missed the rest... busy schedule and everything.

MaximRouiller on 9 May 2017

@MaximRouiller

If I want something like DirectoryServices or Drawing, I need to drop Full Framework and jump to 2.0

No, if you want to a library that does not support .net core, you will not be able to use AspNet Core 2.0+ at all.

hikalkan on 9 May 2017

@MaximRouiller, what they just did is that Asp.Net core projects won't be able to reference full framework assemblies, making it useless for many if not most, they say asemblies like system.drawing and Directoryservices will be ported to the new netstandar or I dunno, still, old assemblies won't work unleast someone port them, so, it is pretty much useless for many becuase some assemblies are legacy and won't be ported, ever. In conclusion, anyone who was using .net core with the full version of the .NET framework just got screwed and need to go back to MVC 5.

adrianlmm on 9 May 2017

👍2

@davidfowl Thanks for this list by the way. That's the very important "so what are we getting out of this?" piece needed for people to balance the cost/benefit in their minds.

If you haven't already, read the list so you're informed on both sides. I still stand by wanting 2.x to be a transition release (with justifiable benefits to the business to actually warrant the move), and 3.x being where the wins are. Even if it came out 2 days later. I really do appreciate the insight on all sides.

NickCraver on 9 May 2017

👍5

@davidfowl you said:

Libraries can be written on top of the standard. When things in the standard itself need to change it will take a lot longer to be adopted in all implementations of .NET and that includes .NET Framework. It can mean a couple of things:
.NET Standard will evolve at the rate of the slowest implementation
.NET Standard will evolve at some other pace and .NET Framework will be the last to catch up.

But why is that the case? Can't you release .NET Standard vNext and have .NET catch up to it some time later (a few months to a year later)? That means that people who are on the bleeding edge and want the latest ASP.NET Core can host in .NET Core, and people who need .NET for their legacy code can eventually use that version of ASP.NET Core once .NET catches up to the .NET Standard version that it uses. I don't understand why .NET Standard has to be revved as fast as the lowest implementation.
Also here we are talking about official implementations of the standard, but there will be other implementations that will not be updated in tandem with the standard.
That way you don't leave people behind. Sure, they take a little longer to benefit from the latest features if they are in .NET, but they aren't stuck forever.

jdom on 9 May 2017

👍13

@jdom because I know the rate at which .NET Framework changes and why it has to be slow. It's a different distribution and maybe there isn't enough appreciation for that. Any change gets inplace pushed to billions of machines. The layering is also completely different so it's not a trivial thing to even reason about.

I don't understand why .NET Standard has to be revved as fast as the lowest implementation.

If we keep raising the low watermark for .net standard in ASP.NET Core it defeats the purpose and leaves you in the same situation. Sure you don't feel left behind because there's a promise that someday these APIs are coming to .NET Framework but in what timeline? .NET 4.7 still doesn't complete feature parity with .NET Standard 2.0.

davidfowl on 9 May 2017

@davidfowl but this will bring back the same problem as with PCLs, it will become the lowest common denominator and a pain to use, the fact that ASP.NET abandons using it shows that already.

Suchiman on 9 May 2017

@davidfowl but this will bring back the same problem as with PCLs, it will become the lowest common denominator and a pain to use,

@Suchiman how is that an issue? The only problem with PCLs was how they were dynamically calculated and represented in NuGet which made it hard to predict what you were going to get. How else would netstandard work if it wasn't an API set that could be implemented by different implementations?

What made PCLs annoying to use were the super duper small API surface area. .NET Standard 1.3-1.4 is enough to implement most basic libraries API wise.

.NET Standard was always about breadth.

ASP.NET Core and .NET Core were about a competitive cross platform server stack for building light weight micro-services. The breath in this sense was broader platform support (running on linux, osx, tizen, pi etc).

davidfowl on 9 May 2017

👍2

@davidfowl

We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).

Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span and are looking at Buffer to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.

It sounds like this means that if I want to use these new bits in a library, the library will also need to target netcoreapp2.0 instead of netstandard2.0. Is that correct?

danielcrabtree on 9 May 2017

👍1

It's a really bad idea not to support the old 4.x framework any more. People don't upgrade if it causes a lot of work. See the super old classic ASP, which is deprecated since 2002 - about 15 years. And we have old applications that still exist in classic ASP! Does Microsoft like to see something similar once again? Dropping old 4.x support is something that has to be done mandatory - but on the long run! Not now. This can be an option in a few years, when .NET core is the de facto standard and only old applications use the net 4.x.

The idea behind (ASP).NET Core is really great, the best thing Microsoft did since the realease of .NET. But such a chaos dulls this nice concept. Also it's very sad, that Microsoft decide such massive changes on their own, without even discussing it in the community! Seems like this company hasn't completely learned yet how to handle open source projects.

DMW007 on 9 May 2017

👍1

@davidfowl

.NET Standard was always about breadth.

Breadth in APIs or platforms?

Whats the issue with evolving .netstandard at the same pace as .netcoreapp?
Is any of the BCL tunings target specific to .netcoreapp because they'll never be implemented in the other frameworks?

Releasing .netstandard2.1 at the same time as .netcoreapp2.1 doesn't make a difference to releasing .netcoreapp2.1 first and a year later .netstandard2.1 at the same time as .net50, except that packages targeting .netstandard2.1 would start immediately functioning on .net50 but will be blocked if they target .netcoreapp2.1

Suchiman on 9 May 2017

👍6

ASP.NET Core is a high level webapp framework built on top of .NET Core and will in the future target .NET Core, _however_ it can also be a high level webapp framework built on top of .NET Standard instead, so that it targets a reference API interface rather than a specific implementation of it.

The public positioning of .NET Standard is being an easy target to build towards while leaving the implementation details aside - with 2 official frameworks directly from Microsoft to cover most use-cases.

Why change that story now? If the .NET Framework never catches up, that seems to be beside the point. At least the possibility is there that it will, or another 3rd party framework can do so. So what if there will only be a single implementation that realistically keeps pace? This is exactly why we have interfaces in our applications even if there's just a single concrete implementation, so that we have the flexibility and advantages it brings.

Perhaps bring down the scope on ASP.NET Core 2.0 inline with .NET Standard 2.0 and then use .NET Standard 2.1 for newer features? Add in some decent support timelines and wouldn't that solve this entire dilemma? Microsoft owns the .NET Standard and both frameworks so this fear in incrementing versions seems completely unfounded...

manigandham on 9 May 2017

👍5

I guess it should be considered that ASP.NET to ASP.NET Core isn't the migration path for everyone.

ASP.NET on full framework will remain and get features but not like Core.

Migration will get easier over time but never be a 100% match.

People still run classic ASP. That's fine for them too.

adamhathcock on 9 May 2017

👍3

@davidfowl I have huge respect for the whole team and the advancements you're all making. So, please don't take this as being down on what is happening. You guys are pioneers, and we all look to you as examples on how to do things right. But I don't see many of these points as immediate target changing problems, especially when it hasn't been communicated. Maybe I'm wrong.

I want to throw some crazy stuff out here because it's been mentioned a few times. What I'm about to say has no bearing on what will happen, it's all speculation at this point. Several people asked why we want to target .NET Core instead of .NET Standard.

We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).

This point here would definitely be a game changer, but IMO it's the only one that absolutely requires not targeting framework, and it isn't for netcoreapp20 anyway.

Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span and are looking at Buffer to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.

This leads to new methods on String that allow splitting that doesn't allocate an array every time.

This leads to overloads to Int, UInt etc (TryParse) that take Span and Span.

This leads to new encoding routines that take Span.

Buffer and Span let you represent memory in a uniform way and we want to upgrade the networking stack to allow passing pre-pinned buffers that take Span or Buffer.

All of this is still implementable as packages on top of current netstandard. You don't even need netstandard20 for this. I understand not wanting to carry this baggage around, but the rest of us out in the non-MS world have to create custom BCL-esque impl's all the time when the use case or perf doesn't fit. Not to mention that the Span API isn't targeted for 2.0 either (unless that's changed again).

Kestrel will implement HTTP2 in the 2.x timeframe (currently aiming at 2.1) and that requires new APIs on SSL stream to do ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http Client on .NET Core supports duplex streaming, it'll make it possible to implement streaming end points over http in signalr over a single, non websocket http request.

I feel like this one is a little trickier, but not all that different from Kestrel carrying around libuv. The CURL implementation from .Net Core can be easily pulled into a netstandard extension package until everyone catches up.

We forked the header parser implementations from HttpClient and System.Net.Http and renamed them (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) so that we could improve them and have them support both .NET Framework and .NET Core. .NET Core has a copy of these improvements haven't made it back because there no need to improve them (we couldn't consume them).

Right, but this is arguably the right way of doing this in this case. Frustrating to wait and hang on to the implementations, but again, I don't see how this is different than what anyone else does when they write a framework or library.

Without the ability to rev the core primitives, we're encouraged to fork them and make things that look like them but aren't them. It's the reason we have our own little BCL within ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Again, just like the rest of us.

ASP.NET Core and .NET Core were about a competitive cross platform server stack for building light weight micro services.

ASP.Net Core had some messaging like that. .Net Core has been messaged from day one as a wholly functional xplat server-side .Net framework subset. Never have I heard anyone say that .Net Core is just for microservices. I've heard you can use it with ASP.Net Core if you want, but also console apps, data analysis, DB services, etc. Is the direction of .Net Core effectively "whatever the ASP.Net Core team wants most"?

ASP.NET on full framework will remain and get features but not like Core.

Will it? I still haven't seen anyone from MS confirm that it is still being worked on. My gut says that it isn't. I get it. The team needs a "move it or lose it" type of moment to break free. I just don't think this is that moment yet.

mattnischan on 9 May 2017

👍1

Assuming that we have a business logic 4.6 assembly, which uses the Oracle.Net driver, the NHibernate and the RabbitMQ (all of them in 4.6). The interface with ASP.Net is only through our business objects, requests and responses. Can we reference this assembly in our ASP.Net Core 2 , without recompile ?

stefan2410 on 9 May 2017

My quick summary
aspnetcore

arkadiuszwojcik on 9 May 2017

👎25 😄12 👍2

@stefan2410 short answer, no, you cannot reference the full framewrok, you could reference those assemblies only if they are created for the netstandar 2.0.

adrianlmm on 9 May 2017

@mattnischan

All of this is still implementable as packages on top of current netstandard. You don't even need netstandard20 for this. I understand not wanting to carry this baggage around, but the rest of us out in the non-MS world have to create custom BCL-esque impl's all the time when the use case or perf doesn't fit.

I'm sorry but it really isn't. You can't monkey patch types. Unless you are suggesting we add new types and don't change the existing ones.

Not to mention that the Span API isn't targeted for 2.0 either (unless that's changed again).

Span exists in 2.0 as implementation but not a public API. We make breaking changes in new majors so we can do more features in minor versions. If ASP.NET Core 2.1 targeted .NET Standard 2.1 then .NET Framework support is dropped again.

I feel like this one is a little trickier, but not all that different from Kestrel carrying around libuv. The CURL implementation from .Net Core can be easily pulled into a netstandard extension package until everyone catches up.

So what you're saying is we should rename all of the classes in the BCL so we can use them on both .NET Standard.

Never have I heard anyone say that .Net Core is just for microservices. I've heard you can use it with ASP.Net Core if you want, but also console apps, data analysis, DB services, etc. Is the direction of .Net Core effectively "whatever the ASP.Net Core team wants most"?

Nope, .NET Core is a general purpose framework that originally had no verticals at its core. It's possible ASP.NET Core should have just been a vertical instead of libraries on top of .NET Core, it would have possibly avoided some of this confusion.

Will it? I still haven't seen anyone from MS confirm that it is still being worked on. My gut says that it isn't. I get it. The team needs a "move it or lose it" type of moment to break free. I just don't think this is that moment yet.

Yes, HTTP/2 support was added in the last release. There's another team that does work on ASP.NET and IIS and they do make improvements. However, they are not on the same scale as what ASP.NET Core is doing.

davidfowl on 9 May 2017

I don't have very strong feelings about this as I've avoided running my ASP.NET Core services on full framework like the plague. With that being said, I've had to avoid using some nice and mature libraries because they didn't support .NET Standard because they were either waiting for netstandard2.0 or simply because they didn't want to.

My fear is that removing the ability to run ASP.NET Core on full framework will dissuade users from porting their current MVC 5/Web API 2 apps to ASP.NET Core which will just provide another reason for library authors to avoid porting to .NET Standard. Why bother doing the work upgrading if none of your users will benefit? It becomes a chicken and egg problem and I'm just afraid that this will hurt the ecosystem as a whole just as it started to get some traction. First you need ASP.NET Core users and I'm not convinced there's as many of those as we all would like. Hopefully I'm wrong.

ericl85 on 9 May 2017

👍4

If ASP.NET Core 2.1 targeted .NET Standard 2.1 then .NET Framework support is dropped again.

No, it just means that Net Framework will automatically support ASP.NET Core 2.1 as soon as it supports .NET Standard 2.1, whenever that is, even if it takes a year or two.

The same for all other .NET Standard compliant platforms (Xamarin / Unity / ...).

Building on .NET Standard means that other platforms will light up _eventually_, building on .NET Core means they will light up __never__.

I assume that the plan is still that full-fx will catch up to netstandard, even if with a long delay?
(and if no other platform except NET Core is expected to implement .NET Standard 2.1, then why even have a .NET Standard?)

0x53A on 9 May 2017

👍19

I'm sorry but it really isn't. You can't monkey patch types. Unless you are suggesting we add new types and don't change the existing ones.

The latter is what has already been done in most cases in 1.x, right? Is that suddenly no longer tenable?

Span exists in 2.0 as implementation but not a public API. We make breaking changes in new majors so we can do more features in minor versions. If ASP.NET Core 2.1 targeted .NET Standard 2.1 then .NET Framework support is dropped again.

Why would it be dropped? Are you saying Span will _never_ exist on Framework?

So what you're saying is we should rename all of the classes in the BCL so we can use them on both .NET Standard.

Woah, no. I'm saying that if I need a Dictionary with a different API, I have to create something else and also not call it System.Collections.Generic.Dictionary, same as you guys already did with Microsoft.Net.*

Yes, HTTP/2 support was added in the last release. There's another team that does work on ASP.NET and IIS and they do make improvements. However, they are not on the same scale as what ASP.NET Core is doing.

That's fair. I was not aware of that.

mattnischan on 9 May 2017

The latter is what has already been done in most cases in 1.x, right? Is that suddenly no longer tenable?

It creates a mess. They've tried to do that as little as possible. The API design and deployment is so more drastically complicated than most people realize, I think. And it's not the Microsoft guys making it that way, it's the reality of supporting many platforms and timelines. I didn't appreciate this until being in the middle of it several times and talking everything through. I really wish type forwarding was at the method level, though. It'd have solve quite a few cases so far :(

Why would it be dropped? Are you saying Span will never exist on Framework?

It would need to be dropped from ASP.NET Core 2.0, as the timelines wouldn't align anymore, since full framework wouldn't have it yet.

NickCraver on 9 May 2017

It would need to be dropped from ASP.NET Core 2.0, as the timelines wouldn't align anymore, since full framework wouldn't have it yet.

AFAIK, Spans are part of a netstandard1.x package that can be used on .NET Desktop (it's a portable implementation so it doesn't have the same perf' boost as if it was backed into the CLR, but it's likely good enough).

Edit: the System.Memory package has a netstandard1.0 TFM, so it can be used even on .NET 4.5.

kevinchalet on 9 May 2017

The latter is what has already been done in most cases in 1.x, right? Is that suddenly no longer tenable?

We halt feature work in certain directions today because of it. It's intentional and we hold ourselves back and refuse to use new APIs by copying and re-implementing things outside of .NET Standard so that .NET Framework can work. This isn't all things but there are some fundamental pieces that we would like to touch going forward, after all, we (Microsoft) control both sides.

Why would it be dropped? Are you saying Span will never exist on Framework?

Span itself has a portable version that runs anywhere, I'm not sure the fast implementation will ever be on .NET Framework. The APIs that will be added to .NET Framework that take advantage of Span may take a lot longer than Span itself, it's extensive. When's the last time we changed string and array in .NET Framework?

Woah, no. I'm saying that if I need a Dictionary with a different API, I have to create something else and also not call it System.Collections.Generic.Dictionary, same as you guys already did with Microsoft.Net.*

That's exactly what you are suggesting. We don't want to have a Microsoft.Extensions.Collections.Generic. We try out best to avoid that and we live with the old APIs and polyfill where possible (https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs). This isn't sustainable and it means .NET Core doesn't get the benefits because we actively avoid using it.

davidfowl on 9 May 2017

👍1

@PinpointTownes having spans isn't good enough, they need to use them in methods calls to existing types. That's when the class-level type forwarding comes into play and causes many problems.

NickCraver on 9 May 2017

@0x53A

That's fair. Can you tell me why popular libraries on NuGet don't drop support for older .NET Framework versions that are clearly out of support? The most popular libraries target net20, net35, net40 etc. Why would it suddenly be ok to require the highest version of .NET Framework to keep using ASP.NET Core? Do you think that would be reasonable?

davidfowl on 9 May 2017

👍2

This is a show-stopper. I have to consider cancelling migrations from ASP.NET MVC 5/Web Api 2 To Core. Many stable frameworks are not yet available for core. We are still using EF6.x because EF Core is not mature enough Feature Comparison.

schonbachler on 9 May 2017

👍1

@PinpointTownes having spans isn't good enough, they need to use them in methods calls to existing types.

"need" is probably a bit excessive. Spans are mainly used for performance, so nothing prevents them from using the existing not-super-perfy overloads on .NET Desktop using ifdefs until .NET Desktop gets native support for Spans.

kevinchalet on 9 May 2017

👎2

@davidfowl I think the big issue is emotional. If you target netstandard, I know that I will be able to upgrade from 1.x to 2.x eventually (even if with a delay). Most of the time, updating netfx is not that big a deal for an application (different for a lib).

But some apps will never be able to make the jump netfx -> netcore, so if you target netcore, they know they are in a dead end with 1.x.

In that regard, it would have been better if Asp.net core had never run on netfx, as it stands, they expected that to continue, and now feel (rightfully, IMO) betrayed. After all, they may have already invested a lot of time into this.

I'm not personally invested in this, because I'm not a asp.net user, my big question is actually just

I assume that the plan is still that full-fx will catch up to netstandard, even if with a long delay?
(and if no other platform except NET Core is expected to implement .NET Standard 2.1, then why even have a .NET Standard?)

Regarding other libs targeting net20, net35, etc, in my experience most authors try to target the lowest version they can and only cut platforms where they have no other choice.

And __yes, I think it is reasonable to drop support for older versions of .NET Framework__, because there is still a clear migration path available. Just update your version. Most of the time you don't even need to change anything, "just" recompile and test.

I think you guys seriously underestimate the number of apps that will never be able to target netcore - just a single closed-source third-party dependency is enough to block that.

0x53A on 9 May 2017

👍4

Span itself has a portable version that runs anywhere, I'm not sure the fast implementation will ever be on .NET Framework. The APIs that will be added to .NET Framework that take advantage of Span may take a lot longer than Span itself, it's extensive. When's the last time we changed string and array in .NET Framework?

@davidfowl I think this is maybe part of the problem. I've honestly been playing devil's advocate a bit here, because we're stuck in the middle as a greenfield app that started just before .Net Core was a thing, so we're straddling the line.

Our thinking has always been, use the fancy new libs (such as Kestrel) if at all possible, but wait for .Net Core to stabilize (and I'm glad we did, if only for the tooling changes), _or_ wait for the cool Core bits to make it back to Framework. I think most people's assumption has been that most, if not all, of the advancements corefx has been making would make it into Framework vNext or vNext+1. But, it looks like (from our 30k foot view) from this and other changes that Framework is not a platform of the future.

I suppose if that's how it is, that's how it is. Our project is massive, so trust me when I say that I do understand the pain of having a bunch of custom impl's of things that are close to but not quite BCL types or ifdef spaghetti. So, I'm not suggesting things out of ignorance of the complications. There are definitely tradeoffs.

mattnischan on 9 May 2017

Indeed a good question: what's left of the backporting of .net core features to .NET full? As I read here, .NET full is so brittle, moving code to it takes ages (it moves very slowly) and can break at any moment (could be, no idea how intertwined it is) so I then conclude that won't happen very often.

It can't be both: either backporting to .NET full is OK, they just release less often (e.g. every 6 months to a year) or it's very complicated and error prone. If it's the former, just pick up the pace and don't let your users pay the bill and stop using the latter as an excuse. If it's the latter, isn't the right conclusion then that netstandard is a fallacy, as all that matters for the future is .netcore's API anyway?

I'm seriously concerned of the future of .NET's direction. My company builds tooling for .NET full and .NET standard1.6. The last thing we want is that the driving force of the direction of .NET (the new features which are about to be backported to .NET full, as said in the .NET core announcement all those moons ago) splits things and the ecosystem effectively gets split in half, as fragmentation is killing.

Nothing in this thread has reassured me things are OK for the future of _all_ .NET and the ecosystem that's needed to make it stay alive: I only see two groups:

People who are concerned that options are getting complicated and they have a tough problem ahead
Microsoft who sees one road ahead: the .net core road.

These two don't match at the moment. Can someone from Microsoft please get a coherent story out so we all can see what is the real deal, how things really are, i.e. with the backporting of features to .net full, what is done about the missing myriad of stuff in .net core (sqlserver stuff, transaction scope to name a few) and how Microsoft thinks they can sell this new direction as a solid, reliable, dependable platform for the future, so corporations and large teams can choose it without worry.

FransBouma on 9 May 2017

👍23

While I agree that all of this is a good thing in the long run, I also think that dropping support for the full framework with 2.0 is too early.

We'd like to move to .NET Core as soon as possible, but unfortunately, our biggest blockers right now are almost exclusively Microsoft libraries (E.g. Entity Framework Core is not good enough yet, Azure Service Bus only has a very early preview).

While I hope that the Azure libraries will be ready in the next weeks/months, it doesn't seem like EF Core will have enough features anytime soon.

I don't know anything about the internals of EF6 but wouldn't it be possible with reasonable effort to have it target netstandard? This would remove a huge blocker...

"Just staying on 1.x" doesn't seem like a good alternative because there'll surely be lots of libraries that don't care (or don't have the resources/knowledge to support both) and just upgrade their dependency to 2.0

PS: I'm very frustrated with how complex the .NET ecosystem has become over the last few years. I've had to spend A LOT of time to understand all of the new stuff and I don't see how a new developer should understand any of this. There's sooo much outdated information on the internet now due to all of these quite extreme breaking changes.
Also, all the different product versions (.net core, sdk, .net standard, ...) are extremely confusing. I've yet to see someone who understands the .NET standard table without needing a 20 minute explanation. 😞

cwe1ss on 9 May 2017

👍13

anyone who was using .net core with the full version of the .NET framework just got screwed and need to go back to MVC 5

Yep. I understand the reasoning, and I suppose I could say I should have seen this coming, but it's very frustrating to have this dropped on us with no prior warning.

We have an application ecosytem, like many others, with shared libraries dating back a decade and more, multiple MVC 3, 4, 5 apps, console apps, windows services, hundreds of thousands of lines of code. We're not even in that bad of a situation to upgrade compared to some.

We recently stood up a couple new web apps using ASP.Net Core 1.1, necessarily targeting the full 4.6.2 framework. These apps use large swaths of our existing shared libraries. We've burned an embarrassing amount of dev time dealing with project.json, then the new .csproj, trying to mix old and new .csproj's in the same solution, dropping back to VS15 to get things done with old .csproj types, broken System. dependencies, and a litany of assembly binding problems, build & publishing issues.. the list goes on and on.

And now we've been left hanging high and dry in a dead end. Do we throw away a few man-months of development or spend many times that trying to first just ascertain what might and might not work and then figuring out any way to upgrade, and then if that's even possible doing it.

I can't say I disagree with the direction and necessity of it, but earlier communication would've been appreciated.

qstarin on 9 May 2017

👍2

Oh, and of course, the Azure Service Fabric libraries don't run on .NET core either - which is another blocker for us.

I'd say you should support the full .NET framework until you can deliver a proper .NET core story within Microsoft (and especially Azure).

cwe1ss on 9 May 2017

👍13

@cwe1ss This change will reduce some of the complexity of the .NET ecosystem though. Since you will not have two different formats (ASP.NET Core + .NET Full and ASP.NET + .NET Core). I totally agree about the outdated information but I think that can't be avoided when you develop in the open like Microsoft does now.

Rutix on 9 May 2017

@davidfowl

The code sharing story across different .NET runtimes is .NET Standard. Your libraries should try to target that to code shared across .NET Core and .NET Framework.<

But the full framework as I understand it doesn't even support.net standard so it's really not a useful standard.

Microsoft seems to have forgotten the importance of backward compatibility.<<

The problem is, ASP.NET Core was never meant to be backwards compatible... That why there was such a big paradigm shift from ASP.NET 4.x. Seems like if backwards compatibility is the high order bit for you'd be better of using ASP.NET 4.x on .NET Framework. That is supported for the forseeable future and will be security patched for as long as Windows is alive.<

Security patching is only part of the issue. The web standards change so quickly that we need to have something that we can use the latest standards with. So for example I saw somewhere above something about HTTPS v2. I have no idea what that means in practice but the point being is that I want my framework to be able to support these things. If I am forced stay with an older version of the framework whether it is v4 or v1 it's not going to support the things that are required.

ASP .net Core was always marketed as running on both .net core and on the framework. As others have said, it doesn't bother me if we have to wait six months or a year until the framework catches up. I'm normally about six months or more behind anyway. But what seems to be happening is that our existing investment is being completely abandoned, like so many other Microsoft technologies that many of us have invested time in.

Stefan

stefanolson on 9 May 2017

@Rutix for "developing in the open" this major breaking change was done suprisingly silent without any announcement nor survey (after all, this issue was created by a community member watching pull requests).

Doing things silently has bitten microsoft in the past and they don't seem to learn. And don't even try to tell me that they couldn't see that dropping full framework support would perturb the community and hurts the faith and investment in the platform.

Last incident was https://github.com/dotnet/roslyn/issues/17054 but they quickly corrected it, i'm wondering how this will go over.

Suchiman on 9 May 2017

👍5 ❤4

But the full framework as I understand it doesn't even support.net standard so it's really not a useful standard.

@stefanolson That is not correct. Libraries targeting .Net Standard 1.x can run on various full framework versions today. Libraries targeting .Net Standard 2.0 are slated to be able to run on 4.6.1 last I looked.

mattnischan on 9 May 2017

@Suchiman I am totally agreeing with you there. I am a bit disappointed that they don't seem to learn how to communicate and stuff dropping bombs on the community. They could have handled this way better if they announced it first and had a community discussion.

Rutix on 9 May 2017

But the full framework as I understand it doesn't even support.net standard so it's really not a useful standard.

@stefanolson It does. Different (existing) versions of .NET Framework implement different versions of the .NET standard. See https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

khellang on 9 May 2017

I know I'm a bit late to this thread but here are two of our use cases for using ASP.NET Core on NetFX on Windows:

Using ASP.NET to host a REST API for your application

Our application is a ".NET API-turned into-REST API" kind of application. It first shipped as a .NET API, and has dependencies into all kinds of Windows stuff.

When we added a REST API, we choose ASP.NET Web API to host it. When it became clear the Web API was unifying in ASP.NET vNext/5/Core, __and__ we figured out that __ASP.NET Core would run on NetFX__ it made sense to use ASP.NET vNext/5/Core.

While we take advantage of .NET Core to port (part of) our application to Linux and macOS, there still are Windows-dependencies that don't run on .NET Core (to get a list of dependencies that we did port, check the CoreCompat.* NuGet packages).

So long story short, we now find ourselves locked on ASP.NET Core 1.x which will remain support for about a limited period of time. And then what? Back to ASP.NET 4?

I understand all the perf work you're doing and pushing boundaries in other areas of .NET Core, but in my use case, I'm not hosting a high-volume internet-exposed website, I'm hosting a REST API which will get like what, 10-20 RPS max?

Visual Studio support

Really, my Visual Studio 2017 experience on NET 4.x is still much better than .NET Core - a good example there is the amount of time it takes to re-compile a test project and have the new tests show up in the test window. It's a lot faster on NetFX.

We end up with a situation where today we have a NetFX and .NET Core project side-by-side compiling essentially the same codebase. The only reason we keep up with this dual maintenance is because of Visual Studio's performance with .NET Core projects (_especially_ unit tests and the debugger).

As an afterthought, what really strikes me is that this change is made now, a couple of days before the preview release. It just seems to indicate that there is no technical reason to do it yet - so why not make the change in ASP.NET Core v3?

qmfrederik on 9 May 2017

👍1

@mattnischan

@stefanolson That is not correct. Libraries targeting .Net Standard 1.x can run on various full framework versions today. Libraries targeting .Net Standard 2.0 are slated to be able to run on 4.6.1 last I looked.<

It appears to me as though asp.net core is going to run .net core not .net standard? So I'm still not sure of what the point of the .net standard is - if it gets abandoned virtually as soon as it gets created.

It would totally make sense if asp.net core required .net standard 2.1 because there are things that they need that are not in the framework at the moment. So we had to wait till the full .net framework supported those additional functionalities before we could use the latest version of Asp.net core. That would work and make sense.

But instead they are just abandoning the standard making the standard useless (if I'm understanding this confusing situation correctly)

stefanolson on 9 May 2017

👍1

So... its Build 2017 starting tomorrow; I imagine the team are very busy preparing for it. Maybe some announcements, maybe not. Perhaps, give them a bit of breathing room and reconvene in a week?

Maybe catch the show https://build.microsoft.com/ (Wed 8:00 PST, 15:00 GMT and Thurs similar?)

We may know more; may not. Things may be clearer, may not. However, the ASP.NET team will likely be able to respond a bit better and focus on everyone's concerns more. Though @davidfowl has been doing valiantly!

benaadams on 9 May 2017

👍24

@stefanolson But instead they are just abandoning the standard making the standard useless (if I'm understanding this confusing situation correctly)

I think the point of .NET Standard is compatibility. Library authors can target .NET Standard and then anyone can use it, whether they're on .NET Framework, .NET Core, or something else that supports .NET Standard.

I think the point of .NET Core is a re-imagining of .NET Framework. .NET Core is cross-platform, high performance, open source, and rapidly evolving.

Changing the implementation of string to utf8 by default is massive and not something you would ever expect to see on .NET Framework.

After reading this thread, I feel:
.NET Core -> .NET Framework is like ASP.NET MVC -> WebForms.

danielcrabtree on 9 May 2017

I'd like to second the tooling aspect as well. The current restore/build/test etc. performance is very bad and a royal pain. If we had to "stay on 1.0" would we still be able to use newer SDKs with (hopefully) better perf or would we be stuck with a 1.x SDK?

cwe1ss on 9 May 2017

The .NET Core story is a wonderful tour full of ups and downs. We just recently started working on ASP.NET Core because of all the previous "fuck ups" (versioning, naming, project.json - .csproj transition) and I was (and I am) looking forward to .netstandard 2.0, because I think this will be the first "real" release.

I get it that ASP.NET Core 1.1 is still supported and will run the next 10 years, but you guys are super brave to move __that__ fast and cutting one of the earlier selling points of ASP.NET Core.

If you want to know what is a blocker (besides directory services) from our side: We are still using EF6 and still wait for an official Open XML SDK NuGet package that targets netstandardwhatever.
Migrating code might take a very long time...

robertmuehsig on 9 May 2017

❤1 👍1

Would it be possible to formalize some sort of process for pushing forwards netstandardXX based on changes that happen in Core which involves targeting it as part of a maintenance phase of Asp.Net Core library release?

As it stands, I have a WebForms/MVC app that we were about to pull a trigger on exposing a ANC web api to and call from a SPA (and ultimately from the WebForms legacy app), but we cannot dev on the CoreCLR because of a dependency on Sybase (now SAP) Ase ADO.NET driver (if someone reading this could push on a button somewhere at SAP ... I sadly cannot seem to get heard at all on this or on bugs that I have known about for over 9 years now).

Reading this issue, I'm not so sure anymore what my path should be. The only thing I am confident I can plan on is a buggy driver will continue to exist for the desktop framework. Was I supposed to ignore the changes to ASP.NET over the past several years because they were going to be a waste of my time and I should just target WebApi2? Am I supposed to say go ahead with ANC 1.x under the knowledge that I'll likely never migrate and see benefits of 2.x in an application I believe will be supported here for the next 10-15 years (the WebForms app has been migrated and maintained since the 1.1 framework was released)?

bbarry on 9 May 2017

@davidfowl

Span itself has a portable version that runs anywhere, I'm not sure the fast implementation will ever be
on .NET Framework. The APIs that will be added to .NET Framework that take advantage of Span may take a lot longer than Span itself, it's extensive. When's the last time we changed string and array in .NET
Framework?

Wait, what?

Not all of us are web developers. We've been eagerly awaiting better string handling support for years and now all of a sudden you are telling us that we're SOL? That the .NET Framework and the countless non-web applications built on it will never get access to string handling libraries based on Span?

This is no longer just a ASP.NET issue. It goes to the heart of Microsoft's long-term commitment to .NET Framework and its base class library.

Grauenwolf on 10 May 2017

👍10

You know, I really have to give it to people like @davidfowl for continuing to respond to everyone and to everyone for contributing to this discussion. I have a lot to catch up on from earlier today, but I feel as if I'm learning a lot through each comment in terms of what everyone is using/hoping to use .NET for.

I think we'll eventually get some path(s) straightened out with everyone's help and I hope that all sides are taken into consideration.

I'm eagerly awaiting the official announcement

snickler on 10 May 2017

If I understood it right, netcoreapp2.0 will provide a compatibility shim that will allow our ASP.NET Core 2.0 projects to depend on our legacy NetFx class libraries (e.g., net461).
Where can I find more information about the currently planned capabilities/limitations of such compat shim?

dgaspar on 10 May 2017

@dgaspar That's not really accurate, here's how it works: netcoreapp2.0 supports most of the APIs in net461. If your library is built for net461 and only calls the APIs that exist within the subset that netcoreapp2.0 supports, then you can import the library anyway (think of it as overriding, that you know better) and make it run, since all the classes and methods it calls should be there.

Now there's also a downside: if the methods aren't there or aren't fully supported in some way, you get runtime errors for missing methods, etc. So compile-time checks aren't a good assurance there. It's a bit of a double-edge sword to be aware of, but there for some libraries that will never be updated yet are just fine with the set of APIs they call.

NickCraver on 10 May 2017

👍7

@NickCraver anyone remember...

"imports": [ "dnxcore50", "portable-net45+win8" ]

A related comment I made in December. 11 thumbs up carried forward:

Something is off the rails here. I've been shipping C# apps for 15 years. Ironically as higher level abstractions are being shipped by Microsoft I'm spending more and more time digging deep into internals I never previously had to worry about. YOU'RE DOING IT WRONG.

If I wanted to be surprised at runtime by random library and package-management induced errors that the compiler didn't catch, I'd write my apps in Ruby.

chadwackerman on 10 May 2017

😄5 👍5

even node.js allow us to easily call all netfx libraries.

the mvc code is really the easy part. it may take a few weeks to rewrite in node.js or nancy, but it will take much longer to port business and algorithm code, and prove it works as solid as the old one. not to mention the case when we do not have the source.

take the RyuJit example, even after release to production, blocking major bugs were found and it took another year to fully resolve. same for our software, which are not pet shops but industrial tools which help making million dollars a day.

the UI framework changes fast, from winform to web. but core business logic/algorithm are much more stable and long lived. so, to use the new shiny UI framework, we need to rewrite/retest or abandon our business/algorithm code? no, we known the new shiny one will be replaced by something more trendy in 5 years, but our business/algorithm code will continue being used.

qrli on 10 May 2017

@qmfrederik

As an afterthought, what really strikes me is that this change is made now, a couple of days before the preview release. It just seems to indicate that there is no technical reason to do it yet - so why not make the change in ASP.NET Core v3?

We're doing HTTP2 support next and it requires new APIs.

davidfowl on 10 May 2017

👍2

I'd like to second the tooling aspect as well. The current restore/build/test etc. performance is very bad and a royal pain. If we had to "stay on 1.0" would we still be able to use newer SDKs with (hopefully) better perf or would we be stuck with a 1.x SDK?

Yep, that will work.

davidfowl on 10 May 2017

@davidfowl

We're doing HTTP2 support next and it requires new APIs.<

So the kind of HTTP2 support that will be available in asp.net core 2.0 won't be available in 1.x? This is really the kind of problem that I worry about where we won't have access to the latest technology because we are bound to the full .net framework for whatever reason. As I've said above doesn't matter if it takes six months to a year for that filter through to whatever I'm using but ultimately don't want to be too far behind. Due to codesharing and third-party library usage at this stage I need the full .net framework.

stefanolson on 10 May 2017

👍1

at last, i clarify a few things:

when i say legacy modules, they are dlls depending on netfx or c++/cli dlls, which in turn may pinvoke some native dlls. they are for business/algorithm, no COM, no asp.net. they are not bad. they become legacy mainly because .net core does not run them.
it is possible to migrate to net core in the long run, and we really want it. but it is really hard to push that to happen.it will take a few years for us and 3rd parties to be all there.
the domain specific libraries is much slower than mainstream libraries for tech stack changes. we all know the python 3 example. those domain specific libraries are real business.

qrli on 10 May 2017

👍1

@danielcrabtree

I think the point of .NET Core is a re-imagining of .NET Framework. .NET Core is cross-platform, high performance, open source, and rapidly evolving.<

Which is fantastic. The challenge is how deal with the existing code bases and how do we get those usable with .net core. If WPF was available built on .net core then I could use .net core everywhere. But as it isn't and my code is shared between WPF and ASP.net I need a way to share them. But I don't want to be too far behind with the latest web technology and security techniques most (all?) of which sounds like will only be in 2.x and later

stefanolson on 10 May 2017

A few times in this thread and in documentation elsewhere .NET Core is described as cross-platform. This was advertised as one of the major selling points for moving to the platform.

This does not seem to be the case however as clarified in this conversation on Twitter

https://twitter.com/James_M_South/status/861595907782987776

And the comment above; emphasis mine.

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.

I've been working very hard with .NET Core since very early on trying to fill the gap left behind by System.Drawing with ImageSharp and I am now left both very confused and more than a little disgruntled and asking:

What even is .NET Core now?

Here's the description from the MS Docs.

.NET Core is a general purpose development platform maintained by Microsoft and the .NET community on GitHub. It is cross-platform, supporting Windows, macOS and Linux, and can be used in device, cloud, and embedded/IoT scenarios.

There's that cross-platform statement again. Is it or isn't it? I think trying to pin this down leads to much confusion across the development community.

Every description I read seems to be different.

Can we:

Please get a decent, consistent, message written down somewhere so that we can actually have a target to aim for and a better overall understanding.
Get some clarity delivered on the actual roadmap for System.DirectoryServices, and System.Drawing

System.Drawing in particular is both confusing and concerning. I cannot fathom why you would ever want to port that API to .NET Core on any platform. It's difficult to work with, unsupported on the server, and lacks many critical features required for modern development (Multi threading, Pixel Formats, ICC, EXIF, Quantization, Indexed Png and so on).

JimBobSquarePants on 10 May 2017

👍21 ❤1

There are a lot of recognizable names and faces here, and I know I'm just adding some noise here, but:

DirectoryServices
Drawing (not that I need it)
EF

These seem like the three most critical things to have up to speed before making such a large break. Personally, most everything I work on is on net4x solely because of EF6, since EFCore... well... :trollface:

tuespetre on 10 May 2017

👍1

@stefanolson
I think you're expected to separate out the shared code into a .NET Standard library. Then it will be usable from WPF and ASP.NET on .NET Framework and from ASP.NET on .NET Core and other .NET Core applications.

@JimBobSquarePants
I don't think Windows compat pack is part of .NET Core. It's a Windows specific library that sits on top of .NET Core. You could imagine there being a Linux specific library that exposed Linux-only features.

I think the Windows compat pack is about making it simpler to migrate existing .NET Framework code bases. Obviously, once someone has switched to .NET Core, they should then look at migrating to better solutions like ImageSharp.

@stefanolson
It's possible they could even create a Windows-only WPF pack that let you create WPF applications in .NET Core, but which would only run on Windows.

danielcrabtree on 10 May 2017

👍3

This GitHub issue has been mentioned on a German IT news site:
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

MJomaa on 10 May 2017

😄2 👎1

Thanks @danielcrabtree that's the first I've heard of any compatibility packs.

JimBobSquarePants on 10 May 2017

Translation for @MJomaa's link: https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.htm

jnm2 on 10 May 2017

I'm waiting on System.Xaml to be ported over.

alexwiese on 10 May 2017

😄1 👍1

@alexwiese don't hold your breath.

yaakov-h on 10 May 2017

👎3

I'm waiting on System.Xaml to be ported over.

Go on; I'll bite. How are you using Xaml on your website?

benaadams on 10 May 2017

Go on; I'll bite. How are you using Xmal on your website?

Cross platform UI (screen templates shared between a "green screen" console application, Xamarin app, and an Angular SPA), also used for a business rules engine.

alexwiese on 10 May 2017

Wow, ok so you are transforming the XAML's XML in some way to HTML and Javascript? Fair enough 😄

Wasn't sure if you were just trolling.

benaadams on 10 May 2017

I'm doing the same, but realistically I don't see them porting XAML over, considering that at this point it cannot be parsed without also being executed.

yaakov-h on 10 May 2017

Wow, ok so you are transforming the XAML's XML in some way to HTML and Javascript? Fair enough 😄

Of course not; I'm converting to JSON first 😉

alexwiese on 10 May 2017

😄11

Another news article about this topic with many of us being quoted: https://www.infoq.com/news/2017/05/ASPNET-Core-2

cwe1ss on 10 May 2017

@cwe1ss The author is @Grauenwolf

MJomaa on 10 May 2017

@alexwiese @yaakov-h I'd love to read a blog post about that; sounds pretty interesting and must come with a different set of challenges than I'm used to.

benaadams on 10 May 2017

This is really bad. ASP.NET Core was a reasonable sell when you could leverage legacy libraries when needed. In the case where it can be done with the new stuff, tweak a few things and target .NET Core. Otherwise, just target the full framework.

With this change, it's an all or nothing jump. And given that you don't always understand all the dependencies up front, it magnifies the risk.

I understand the desire to move fast, and evolve where things are bound to go anyway, but you're going to leave your users behind. People tend to migrate, not jump. A large number just won't move off the current. And then when they do, they might well move to a different platform entirely. Seriously, you're underestimating that risk.

This is a move that should eventually be made, but more like late 2019, or 2020 at the earliest. Even then, you still want a long term model for supporting those who have chosen to mix things.

And no, ASP.NET Core 1.x is just not an answer there. It's immaturity is fine as a transitional phase with an easy migration path forward, but it's not suitable for living with for the long term. There's a big difference between the mindset of those who develop a platform like this, and those who use it. Please reconsider this direction.

chriswelles on 10 May 2017

👍10

@davidfowl What about something like edge.js for netcore? It makes the API consumer responsible for platform checks and a strongly typed interface between netfx and netcore is sufficient for most scenarios.

mtman on 10 May 2017

Will this template be removed then?

It's baked into VS2017 at the moment.

DamienDennehy on 10 May 2017

😄2

what a totally unacceptable bulshit, again this proves it is a toy technology not ready for prime time and wide adoption.

I really appreciate guys you have a nice ride and coding experience, you can shine in your blog entries and twitter (hoorrray!), improve your linkedin profiles and cvs (hooray^2), all release parties ahead of you, girls, drinks and stuff looks promising, but .. who is going to use it? do you target enterprises and want large adoption and solid user base? or some startup hippies only?!?

xprzemekw on 10 May 2017

👎8 👍7 😕3 😄3

That comment about "full Span" potentially never making it into .NET Framework is seriously concerning to me. If full Span is not in .NET Framework then I assume APIs using it can never make it into a future netstandard, which makes it impossible to write cross-platform libraries that use or expose high performance parsing? Which means we're stuck with our unsafe custom implementations permanently effectively...

You mention that if you want you're library to be cross-platform then you should target netstandard, but what is ASP.NET Core if not a library that is widely used? Would you recommend other libraries start dropping support for netstandard and switch to .NET Core? Should the next major version of JSON.NET or whatever drop netstandard? It could certainly do with fast parsing!

Note Java managed to add fast IO with zero copying etc in a backwards compatible way with Netty (https://netty.io/)

Finally I do want to say thank you to the people who are willing to hang around and answer these. We do appreciate the answers...

bencyoung on 10 May 2017

👍6

@shanselman Moving fast is a noble goal, especially for for teams that put paramount amounts of effort into compatibility and designing things in a compatible fashion, like the ASP.Net Team. I know how much they would like to simplify their problem domain, and I support that, but ...

Moving fast and at the same time "also away" from your customers is not a good thing either. You know, your customers (me included) have a serious set of legacy software and time investment into existing apps and libraries. You can't just leave us behind and go to a place where we won't/can't follow.

You should consider your customers who can't go to .Net core and must use Full Framework for at least some more time from now. If you move away from Full Framework, you leave allot of people stranded on older versions and create big split in the .Net world.

popcatalin81 on 10 May 2017

@JimBobSquarePants I second you on the System.Drawing part. There are some discussions in the other repos about brining System.Drawing back. Based on some of the comments in this thread, I understand there will be a "compat pack" on Windows first and then on all OS-es for System.Drawing.

I wonder what that will look like, and whether it will be based on Mono's libgdiplus or not (which would remove some of the concerns you have with System.Drawing, but that's another story)

qmfrederik on 10 May 2017

Okay, the way I see it, there are a couple of issues at stake:

This was communicated rather poorly.
People weren't involved in the decision. Note that Microsoft is of course free to choose the direction they like, but not discussing this type of large change with the community is not in the spirit of open-source development.
There is no "grand scheme" that the community can use to examine these types of decisions. At first, .NET Core was a trimmed, cross-platform version of the full framework. Then, with .NET Standard 2.0, it appeared to many that .NET Core 2 would be like a drop-in replacement of the full framework, within reasonable limits of course (no UWP, WinForms, etc.).
.NET Core 2 will miss out on several important pieces of functionality that are in the full framework, like System.DirectoryServices. As far as I can tell, this has been acknowledged, but perhaps the road to getting these features added to .NET Core could be made more explicit.
ASP.NET Core 2 will not run on the full framework due to the full framework missing newer features. I'm actually totally okay with this. If adding the missing features to the full framework is excessively hard, then don't. Having ASP.NET Core 2 only run on .NET Core 2 actually makes quite a bit of sense, although mentioning them as being one product was probably not the best way to describe their relation.

What I think people would really like to see is a description of the vision of the .NET platform. Which direction will things go in? Will the full framework just receive bugfixes and such but no new features? What is being done to add missing features to .NET Core and when can we expect them? Having this explained would hopefully go a long way in easing the anxiety people are feeling now.

ErikSchierboom on 10 May 2017

👍5

@davidfowl I guess it's not just about HTTP 2.0; if it's really about HTTP 2.0, couldn't you have ASP.NET Core 2.0 target NetFX with the exception of HTTP 2.0 support? Perhaps even a pluggable model so that the community could do HTTP 2.0 on NetFX if they really wanted?

qmfrederik on 10 May 2017

👍2

@cokkiy @popcatalin81 @xprzemekw If you have nothing constructive to say, please refrain from commenting, these kinds of comments are not helping anyone.

There are legitimate reasons why make the move described by @davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment-300141134

Reasons why postpone it include (say asp.net core 3.0):

EF Core is not yet ready to replace EF 6.0 due to many features missing
no production ready System.Drawing replacement
no System.DirectoryServices
there was mention of office xml sdk, but that seem to be already available on netstandard as of 2017-05-01 https://www.nuget.org/packages/DocumentFormat.OpenXml/
other packages outside of MS scope unavailable on .net core (nhibernate, various db providers, ikvm)

Reasons why not do it ever include:

People ported apps to asp.net core with legacy dependencies with no intention to move to .net core.
Worry about leaving netstandard behind and not caring much about it.
Some 3rd party packages are unlikely to be ever ported to .net core (which arguably makes them obsolete, but that might be just my opinion)

Example of constructive comment would be adding your reason why you'd like to see one of these three scenarios or suggesting alternative solution. If you just want to express agreement/disagreement use the "Reaction" buttons.

Kukkimonsuta on 10 May 2017

👍16

@Kukkimonsuta

People ported apps to asp.net core with legacy dependencies with no intention to move to .net core.

Completely agree. Because Microsoft had announced that ASP.NET Core will work on both .net core and .net frameworks. And now leaving them in AspNet Core 1.x is not fair.

hikalkan on 10 May 2017

👍16

The last summary is quite good. I'd just like to add a thing or two:

1.) It should be possible to write Windows Services with .NET Core (I know that daemons on *NIX platforms work differently). So the ServiceBase would still be needed, and this is high priority together with EF.

2.) It should further still be possible to write standalone services with .NET Core, and additonally host them within your existing, full-framework based .NET application (i.e. complimentary service from your Windows Forms / WPF app) to extend them.

The latter really is required for slow migration scenarios, where its not possible to make a hard cut and start greenfield.

gingters on 10 May 2017

Completely agree. Because Microsoft had announced that ASP.NET Core will work on both .net core and .net frameworks. And now leaving them in AspNet Core 1.x is not fair.

I also like to stress again that the huge change back to .csproj and msbuild was mainly excused with the fact that it would not be possible to reference (ASP).NET Core projects from your existing (full framework) .NET projects.

This change makes the latter impossible (at least for the biggest ASP.NET part). So why was compatibility paramount back then (and caused a lot of pain), but isn't now (and again causes a lot of pain)?

gingters on 10 May 2017

👍8

sorry i have to stress, too. But almost 500 comments, i belive if i am involved as a microsoft guy for this issue i had two options:
1: mute the issue
2: rethink about my decision

nokinger on 10 May 2017

@gingters The csproj change was primarily for _.net_ core though, in order for xamarin, asp.net, uwp and all the other to share code and also reference other project types like native code.

Also, it enables asp.net core 2 projects to reference full framework projects, again, via the compat shim

aL3891 on 10 May 2017

@qmfrederik

Perhaps even a pluggable model so that the community could do HTTP 2.0 on NetFX if they really wanted?

They technically could. But it seems they don't want to. To me it feels they just don't want to think about the real needs of enterprises / large businesses, or about backwards-compatibility or the need to cope around with something else than greenfield stuff.

And to be frank, the expectation management in the past completely targeted businessed that want to slowly extend / migrate their stuff to cross-platform, while also being able to slowly extend / migrate their existing apps over. So this move is completely unaligned with the previous expectation management.

gingters on 10 May 2017

👍2

@aL3891

in order for xamarin, asp.net, uwp and all the other to share code

Yes. Exactly. And that also includes WPF/Windows Forms app to consume .NET Core libraries, which is now impossible when you want to go on to .NET Core 2.

gingters on 10 May 2017

Could someone explain exactly why the hell these libraries can not target netstandard2.0?

Until now, I have considered netcoreapp as a moniker for a cross platform executable (only used in a csproj executable project), but I never considered it as a platform, now, it should be considered as a real platform? Why why why, and how did we come to this absurd option?

xoofx on 10 May 2017

I see the reasoning and rationale behind targeting netcoreapp2.0, but I too think this move is very much premature. The ecosystem is nowhere near ready, quite a few very widely used dependencies (including ones likely wanting to be used in greenfield development) don't target any netstandard and it is unclear whether they ever will. Not to mention the Microsoft Packages and SDKs not targeting netstandard, including stuff for Azure.

Just to throw something out there: would it be feasible to polyfill .NET Core 2.0 with the full framework when running on Windows? There already is P/Invoke, so maybe there could be some sort of NETFX/Invoke, nicely wrapped behind a facade Package to fill the API surface.

In the end, I don't think any one of us _wants_ to use stuff that targets net461 instead of the netstandard2.0, it's just that the dependency either can't (missing API) or won't (abandoned, don't want to etc.) change. And to solve this problem, you need to give package developers time and a very clearly communicated plan when and what change happens, maybe even some guidance on how to target the netstandard.

wagich on 10 May 2017

@xoofx

Could someone explain exactly why the hell these libraries can not target netstandard2.0?

As far as I understand it (someone correct me if I'm wrong), because the full framework (at least 4.6.1) is supposed to comply with netstandard 2.0, and there are features they need that won't be in the full framework for the foreseeable future

javiercampos on 10 May 2017

One thing that I find interesting and that ties into the whole question about "What is the vision?" are the frequent mentions of System.Drawing.

I find that interesting, because classes (unlike e.g., structs like System.Drawing.Color) System.Drawing hasn't been supported on ASP.net for years, at least since the days of .net Framework 3.5. From the documentation:

Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. For a supported alternative, see Windows Imaging Components.

Now, of course, people have been actually using GDI+ anyway because in a lot of cases, it works. And I'm not here to discuss whether it's a good idea to rely on unsupported behavior or not.

But I do wonder what the vision is now for .net Core and ASP.net Core: Is it a re-implementation of the good ideas and the removal of the years old cruft (aka. ".net - The Good Parts")? In that case, why bring in System.Drawing at all?

Or is it basically a rewrite of the full .net Framework to be multi-platform, basically a better Mono?

I'm not arguing either way, I'd just like to know. I feel that the .net and .net Core teams need to do some soul searching, because I feel that it started as the former and is now the latter.

I don't mind staying on .net Framework on Windows (I'm talking about my own projects here, as I'm not driving architecture for my employer). .net Framework works really well, and is supported until at least 2027 on Windows Server 2016.

Being on .net Framework comes with compromises of course. E.g., HTTP/2 support landed much later than other web stacks had it, and required a full OS upgrade - correct me if I'm wrong, but to my knowledge, there's no way to do HTTP/2 with ASP.net on Windows Server 2012 R2. But those compromises are worth it for the strong guarantee of the status quo being supported for another 10 years.

But in order to consider full Framework for new development, I'd love to see the Roadmap for ASP.net on Full Framework - what's planned for ASP.net MVC 6, Web API 3, SignalR 3 etc. I just don't want it to be basically this generation's Visual Basic 6/Classic ASP(.net).

I feel that it is indeed in the best interest of ASP.net Core to focus on .net Core because there's a lot of good stuff that is enabled by the fast pace, and I feel that for the first time in forever, .net Core is production ready, for new development. Move fast, innovate, basically do what Node.js did so successful (and remember that they had their own Stability/Innovation drama, see io.js).

I'd like to thank everyone from the team commenting here - this is a long thread with many different viewpoints, but a civil discussion. I know it must be frustrating for @davidfowl to keep asking "So, what are you actually missing in order to port?" and only getting useful answers way into this thread.

But it's also a really valid fear and frustration for people currently on .net Framework to _feel_ that current ASP.net is basically "finished" and that all new development will happen in ASP.net Core, which will only run on a platform that they might not ever be able to move to - basically what happened to the Visual Basic 6 folks when they were told "move to VB.net, or find yourself stranded a few years from now".

I feel that it's a lot easier to really double down on making ASP.net Core 2.0 on .net Core an amazing Web Stack once people that won't ever be able to use it are reassured that good parts from it will still find their way into their, Classic ASP.net stack.

Anyway, enough of my rambling. It's an extremely hard problem for the team to solve, and I don't envy you. All I (and a lot of other people here) want is some clarity about where the Ecosystem as a whole is going.

mstum on 10 May 2017

👍2 ❤1

As far as I understand it (someone correct me if I'm wrong), because the full framework is supposed to comply with netstandard 2.0, and there are features they need that won't be in the full framework for the foreseeable future

Thanks! I would like to know exactly which features? @davidfowl mentioned above HTTP2 to be - one - of the reasons? How can a protocol that could be implemented into a whatever separated System.Http2 assembly is leading to fork an entire .NET platform? Could someone give more details about the full reasoning?

xoofx on 10 May 2017

@gingters but its not impossible, libraries can still target .netstandard and be used both by 46 and core, its just asp.net core _itself_ that this is not the case for.

aL3891 on 10 May 2017

@xoofx https://github.com/aspnet/Home/issues/2022#issuecomment-300141134

davidfowl on 10 May 2017

Reposting because it's buried and un-linkable:

so if understand correctly, we will eventually have netstandard replacing net framework.

Not thats not correct. I'm not sure how you drew that conclusion. .NET Standard will always be a subset of each of the runtimes that support it.

I want to throw some crazy stuff out here because it's been mentioned a few times. What I'm about to say has no bearing on what will happen, it's all speculation at this point. Several people asked why we want to target .NET Core instead of .NET Standard.

We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).
Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span<T> and are looking at Buffer<T> to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.
This leads to new methods on String that allow splitting that doesn't allocate an array every time.
This leads to overloads to Int, UInt etc (TryParse) that take Span<char> and Span<byte>.
This leads to new encoding routines that take Span<byte>.
Buffer<T> and Span<T> let you represent memory in a uniform way and we want to upgrade the networking stack to allow passing pre-pinned buffers that take Span<T> or Buffer<T>.
Kestrel will implement HTTP2 in the 2.x timeframe (currently aiming at 2.1) and that requires new APIs on SSL stream to do ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http Client on .NET Core supports duplex streaming, it'll make it possible to implement streaming end points over http in signalr over a single, non websocket http request.
We forked the header parser implementations from HttpClient and System.Net.Http and renamed them (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) so that we could improve them and have them support both .NET Framework and .NET Core. .NET Core has a copy of these improvements haven't made it back because there no need to improve them (we couldn't consume them).
There are a bunch new threading primitives that require new API that will light up new scenarios if we're able to consume them (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+author%3Adavidfowl+label%3Aarea-System.Threading), those are just some of the things I've personally filed.

Without the ability to rev the core primitives, we're encouraged to fork them and make things that look like them but aren't them. It's the reason we have our own little BCL within ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

That was just a random dump of things I can see us doing in the near term that affects very fundamental pieces of .NET.

davidfowl on 10 May 2017

👍9 ❤6

Hey all, thanks for a very interesting discussion. This thread has reached critical mass and some of the same questions are being asked and re-answered. I'm going to bow out now 👋 .

davidfowl on 10 May 2017

👍21 ❤9 👎7

@aL3891

its just asp.net core itself that this is not the case for

Which - just for example - kills hosting ASP.NET Core 2 as a windows service (as all api's are missing in .NET Core, and TopShelf is just running on the full framework). Which is actually a pretty strong restriction. And also disallows hosting a .NET Core 2 service extension being hosted within your exsiting WPF / Windows Forms app, which is a common scenario in integration use cases with legacy apps.

gingters on 10 May 2017

The fast version of Span<T> not going to be available on .NET full is really weird: how is Microsoft going to speed up Roslyn then? They have a fast Span<T> and accompanying tech, but won't use it in every Visual Studio installation on the planet, because ... politics? Because there's no manager up in the tree at MS brave enough to say: we have to put more effort in .NET full?

But don't let me ruin the rainbows and colors marketing blabla talks that will be spread later today from //build. I'm sure MS will paint a rosy picture that everything is fine and the rest of the planet is still living in a cave.

FransBouma on 10 May 2017

👍18 👎1

@davidfowl Thanks for your efforts here, your insights and answers have surely helped many people. 👏

louislewis2 on 10 May 2017

@gingters Its absolutely limting the set of scenarios, but i'm just saying that the whole netstandard/csproj effort is not wasted because of it

aL3891 on 10 May 2017

@davidfowl I've just stumbled over this news and it's a bit scary. Until now, I was confident that if I supported comaptiblity with .NETStandard 2.0, I could eventually switch to using ASP.NET Core 2.0 in my application while still running on the full framework. Unless I'm completely missing the point, that's no longer going to be possible.

I've just run the latest version of the API analyzer and there is a number of missing APIs in .NET Standard 2.0 which I depend on. Some of them I can get rid of (e.g. System.Configuration) even if it's a pain.

Others, I don't know yet. For instance, I use runtime code generation and rely on System.Reflection.Emit.ILGenerator, TypeBuilder, etc. And I can't just get rid of those, it's an core part of the product.

I've dug around further with the API Analyzer and it seems that some of that is covered by .NET Core 2.0 + Extensions but there's still the following APIs missing:
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess,System.Collections.Generic.IEnumerable{System.Reflection.Emit.CustomAttributeBuilder})
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess,System.String)
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess,System.String,System.Boolean,System.Collections.Generic.IEnumerable{System.Reflection.Emit.CustomAttributeBuilder})
M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String,System.Boolean)
M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String,System.String,System.Boolean)
M:System.Reflection.Emit.AssemblyBuilder.DefineVersionInfoResource
M:System.Reflection.Emit.AssemblyBuilder.Save(System.String)
M:System.Reflection.Emit.AssemblyBuilder.Save(System.String,System.Reflection.PortableExecutableKinds,System.Reflection.ImageFileMachine)
M:System.Reflection.Emit.ILGenerator.MarkSequencePoint(System.Diagnostics.SymbolStore.ISymbolDocumentWriter,System.Int32,System.Int32,System.Int32,System.Int32)
M:System.Reflection.Emit.LocalBuilder.SetLocalSymInfo(System.String)
M:System.Reflection.Emit.ModuleBuilder.DefineDocument(System.String,System.Guid,System.Guid,System.Guid)
M:System.Reflection.Emit.TypeBuilder.CreateType

I have looked around a bit in https://apisof.net/catalog and it seems that the information there differs from the API analyzer output, i.e. some APIs the analyzer marks as not supported are listed there (TypeBuilder.CreateType). So, I might be okay, but I won't know until I try. Other's, they are defintely missing, e.g. the AssemblyBuilder.Save(...)

So, bottom line: I won't just be able to drop in ASP.NET Core 2.0 into the full framework stack and just keep my old dependencies. I will also not be able to use .NET Standard 2.0. Instead, I will have to port everything Big Bang to ASP.NET Core 2.0, since that's the only API which covers almost everything I need. AND I won't be able to develop the new web application layer on ASP.NET Core 2.0 BEFORE I migrate. So, it's actually a Big Bang followed by a REALLY Big Bang.

MichaelKetting on 10 May 2017

@davidfowl thanks for the details.

I'm completely all for .NET Core and I actually don't care much about .NET Full Framework... But I cared about netstandard2.0 only because it was bringing most of the .NET full framework API, and the version 2.0 as a "junction" version, i.e., to help people migrating their code from .NET Full to .NET Core... but I was not really expecting it to be tied to the slow evolving path of the full framework forever... but it sounds like netstandard2.0 is going to be the new PCL after all...

so fair enough, the .NET full framework really need a retirement plan now (System.Drawing holding you back? Come one, SkiaSharp is wait better and cross platform) and let .NET Core 2.0 evolve has its own full pace!

xoofx on 10 May 2017

👍1

@davidfowl Initially, API wise ,Net Core was supposed to be a subset of Full Framework running on all platforms, and any API changes concerning Core to be brought on both. That was the initial promise at least ... things look very different now with this new (out of nowhere) direction.

The things you've mentioned are all great, I'd love to have them right now, but on Full Framework where they are greatly needed, I currently work on a WPF app where Span and related APIs would be a godsend, we currently have custom TryParse routines , for datetime and timespans and primitive taking indexes that are a support nightmare because they need to be culture aware..

It's totally understandable you want to evolve the framework, what is not understandable is why create this split with existing customers and leave them stranded on a now dying platform? Full framework?

popcatalin81 on 10 May 2017

@popcatalin81 (Before things get too off-topic, but at the risk of being a mansplainer) - Span is about moving memory around without allocations, it has nothing to do with DateTime.

graemechristie on 10 May 2017

@popcatalin81 with netstandard2.0 I'm pretty sure that we could expect even WPF and System.Drawing to run on .NET Core (Windows only, they would obviously not run on non-Windows platform... ), afaik, these libraries are not using any CLR special features... they would just need to be recompiled with netstandard2.0... (only the .NET part, the native part would be the same - wpf composition engine, or direct calls to Win32 functions for System.Drawing...)

xoofx on 10 May 2017

I've not been following the whole "Core" journey as closely as perhaps I should have and as such there are a couple things that really stand out for me.

It seemed that in the beginning the ASP.NET team were charging ahead of everyone else (or at least were being accused of that), were then reigned back in and are now having to break free again for reasons already mentioned. Is that a fair assessment?

If so, it would seem that a lot of the difficulties now being faced were foreseeable and that a new modern ASP.NET / .NET should've been a standalone thing from the get go.

The primary issue that I'm seeing throughout this thread is that people have have made significant investments based on promises and assumptions that no longer hold true.

It feels like a lot of this could've been avoided.

Am I way off base?

letdowncrush on 10 May 2017

@davidfowl @DamianEdwards @shanselman

I've got some a few ASP.NET Core 1.x apps in production that target net462 because they provide the functionality and use the namespaces below. I can't see the namespaces in the netstandard2.0 work in progress API reference.

1. ADFS integration:

• System.IdentityModel.Protocols.WSTrust
• System.IdentityModel.Tokens
• System.ServiceModel
• System.ServiceModel.Security

2. Atom / RSS feed generation:

• System.ServiceModel.Syndication

I'd like to get these existing apps targeting netcoreapp2.0 in the future. What would be my best course of action in each case? For example, have I missed an existing NuGet package or should I wait for a future release?

mattbrooks2010 on 10 May 2017

👍2

There are lots of things that force me into full stack, ironically most of them Microsoft technologies. CRM Dynamics SDK, Azure SDKs, XLST namespace support, headless ADAL login (only available in full stack),etc...

This change will only further segregate an already tiny developer base brave/stupid enough to early adopt .Net Core .

talynone on 10 May 2017

👍15

@davidfowl

We're doing HTTP2 support next and it requires new APIs.

I only partly understand that point. For HTTP/2 the main blocker is ALPN support for TLS, so we can't have it right now. However this will also not happen in time for .NET Core 2.0, according to the comments on the associated request in the CoreFx repo. Only later on (2.2? 3.0?) Which means from a HTTP/2 perspective it wouldn't matter if ASP.NET Core depends on corefx 2.0 or .netstandard 2.0 - it wouldn't work anyway. Only later on, when the version number gets increased again.

Besides that the HTTP/2 issue mainly affects the webserver (Kestrel) and not the whole framework. Besides the "it's ugly to maintain multiple things" reason I see no reason why one couldn't have a webserver without HTTP/2 support for .NET standard and one with it for future .NET Core versions.

Matthias247 on 10 May 2017

❤6 👍2

@davidfowl There is one thing that has not really been covered in this whole discussion. I fully understand the technical background, and I entirely agree with your reasoning. In particular, I agree that staying on 1.x (potentially with an extended support timeframe), especially if currently missing pain points like SignalR will be added with 1.x support in the future, is going to be a solution that is technically feasible for the majority of all cases discussed here.

The problem however is not of technical nature, it's psychological. As some here have pointed out, adoption of ASP.NET Core still is in its early stages. Think about the message you are about to send: you are going to release a 2.x version soon and then most likely immediately start strategic planning on version 3.x, all in the plain open (which normally is a good thing). A consequence of that will be, that even if there is no mandatory requirement for most people to use 2.x, and even though you might provide a reasonable technical solution by supporting 1.x, in people's heads the idea of actively migrating an existing solution to "a version 1" when there's already work on version 3 will be an instant and unacceptable psychological roadblock. There's real danger that this will result in a chicken/egg problem where people don't migrate existing projects to ASP.NET Core and library authors don't port their stuff to .NET Core because there's not enough demand and pressure, which will effectively slow down adoption rate even more, for a potentally long time.

As some have also mentioned: apparently a lot of people, even if they were aware of this move coming at some point, didn't expect this cut to happen so soon. Additionally, over the course of the last months we heard and read a lot of talks, interviews and posts about how 2.x (.NET Core, .NET Standard etc.) is going to stabilize and unify things. Hence, in a lot of minds "2.x" has become the equivalent for "mature", no matter how technically well-founded this claim may or may not be. The way you built up excitement for 2.x, and now take away a core feature of 1.x on short notice, was a most unfortunate move, which most likely has moved the argument away from technical reasoning to an emotional one, even if on the surface it still seems we are just discussing technical details here. It is going to become very hard for you to change this perception back and re-establish broad trust and confidence in 1.x being a solid migration target to ASP.NET Core.

My personal recommendation would be to release 2.0 as the last major release to support the .NET Framework, but instead of taking another year or more to drop that support, move on to 3.x much quicker. Use 3.x for all these technical features that are not possible with backwards compatibility in mind, and start working on 3.x as soon as 2.0 is out of the door. By that you get multiple benefits at once: you can keep your original support plan for 1.x. People get .NET support in 2.x, which in their heads has built up as "the mature" version over the last months. They can migrate to the "latest and greatest" with confidence, now very aware of the fact that 3.x will drop that support, and enough time to plan their migration strategies, if necessary. And you do not need to slow down (or only for a very short time) with adding new features and evolving ASP.NET Core as rapidly as you want.

Again, that proposal is not so much different from what you currently indend to do anyway, just with some different versioning ninjutsu applied. The fact that this change has been applied recently implies that technically this would only be a small step backwards until you are able to again move forward full-throttle, but it would dodge these psychological problems nicely.

/cc @DamianEdwards @shanselman

MisterGoodcat on 10 May 2017

👍38 👎3

and announce Microsoft Shrink at build. (sorry, I couldn't resist)
While I agree with @MisterGoodcat in everything about the WHY, I'm wondering, do we really need Microsoft to manage our emotional flaws/needs?

Bartmax on 10 May 2017

.NET Framework has been stable but slow-moving for years, and as a maintainer of almost every kind of .NET app, I agree that something has to be done about it, and maybe even that "put it out of its misery" is an option in the fullness of time, now that Microsoft has chosen to anoint .NET Core instead of other options. But this issue illustrates how blind Microsoft tends to be that past effort spent does not all automatically port over.

For a company famous for its focus on developers and developer tools, Microsoft asking for blockers only in the form of its own dependencies is incredibly myopic. It doesn't surprise me that DirectoryServices and Drawing are the single most popular blockers, but that does not mean there's not the mother of all long tails of internal components, third party components and COM Interop that are either impossible, impractical or enormously expensive (especially in the form of upgrades) to bring along for the ride.

I understand the argument that Microsoft is asking about its own stuff from the BCL or extended .NET Framework (WCF, etc) in order to make sure they're working on the right stuff themselves, but the same question should not be driving decisions that move the entire platform. If the plan was to drop .NET Framework all along at some stage, why not communicate it? And if the decision was made recently, why not communicate that at that time? Why not talk to us and consult with us? I understand that not every one of us will give qualified analyses, but when I see MVPs in this thread, your most fervent supporters and most active users being blindsided by this, I'm not really confident that Microsoft cares the least bit about its customers.

And I also understand the argument that it's easy for me to say "Microsoft". I know that it's made up of individual people who do not have infinite capacity. But I don't ask for herculean efforts from a steely monolith - I ask for communication, honesty, respect. I ask that when you all that work on this product and want to make changes that will affect your customers, you engage with your community instead of rolling the dice. We write articles for you, we choose your platform, we pump it when you do something right (like letting people know about the whole performance boost, which Ben Adams, an unpaid community member, made indelible contributions to), we watch community standups. But this goes both ways. Use us as more than a megaphone, and we may not react in this way.

JesperTreetop on 10 May 2017

👍5 ❤1

@Bartmax It's either that or give everyone a mandatory 2 hour course in the differences of core, asp.net core, asp.net core non-core, netstandardbanana, .net, system.web. asp.net 5 (I mean 6).
And start communicating roadmaps and intentions more clearly.

It's still not a fix for those who can never let go of full framework. Somewhere down the road we will end up with two communities.

In a perfect world asp.net core would be faster on core, and maybe even have some exclusive features not available for .net. But most of the stuff would be netstandard, and everything else would be cross compile at least for the foresable future. And people can learn core, since if they have to work on a legacy project the only difference would be the bootstrapping part, instead of the whole asp.net part.

hallatore on 10 May 2017

👍2 ❤1

Not seeing how anyone is a normal asp.net developer shop can have confidence in this moving forward.

leriksen71 on 10 May 2017

As someone who is has to use quite a few C++/CLI libraries this potential change leaves me with gruesome options:

1) Stay with the current stable asp.net core version forever without ever having the chance of leveraging new features or security fixes.

2) Invest a boatload of time (and ultimately money) of replacing all those C++/CLI libs, which no customer would ever want to pay a single cent for.

3) Abandon asp.net core altogether

I can understand that this change is necessary in the future and I'm all for it. What i cannot understand and accept is the timeframe. Something of this magnitude is something you would announce as a roadmap goal a year in advanced as an upcoming breaking change in the version 3.x or even 4.x and not dump it in the next version....

leak on 10 May 2017

👍5

@davidfowl What about something like edge.js for netcore? It makes the API consumer responsible for platform checks and a strongly typed interface between netfx and netcore is sufficient for most scenarios.

To me, this looks like an ideal solution:

1) No guesswork whether your netfx code will run under netcore -- it uses netfx runtime, in-process
2) Doesn't hold back Core
3) If new Core APIs would become popular enough that developers would drop support for the lowest possible version of netstandard, which is not what is happening in the netfx space, you could provide a bridge for the opposite direction

mtman on 10 May 2017

For those suggesting a dual-platform ASP.NET Core, one which runs on old .NET without any of the shiny new string and span features, and one on .NET Core 2 with those features... well, I'd suggest taking a look through the code.

At the most basic level, any web framework:

takes blocks of bytes that represent UTF8-encoded strings (_BOBTRUES_), interprets them and passes them into your code as strongly-typed objects
takes the results of your code and turns them back into _BOBTRUES_.

So it makes sense that what you really, really need if you're building a web framework is low-level primitives that understand _BOBTRUES_, doesn't it?

And if most of the code you're writing is dependent on _BOBTRUES_, but you also have to support another runtime that has no idea what _BOBTRUES_ are, then you're writing all that code twice, all littered with compiler directives or complicated build files. And you're going to have to keep writing and editing all that code in duplicate, at the same time as trying to make your web framework _awesome_, for as long as it takes not just for full .NET to get round to understanding _BOBTRUES_, but also Mono, UWP, Xamarin, Unity3D, and anything else that implements whatever NETStandard you add _BOBTRUES_ requirements to, many of which don't really care about _BOBTRUES_ in the first place.

Of course, the only reason you're having to write all this code twice is because there are a bunch of 1st-party and 3rd-party packages out there that are either

System.Drawing, System.DirectoryServices, etc., or
waiting for NETStandard 2.0 because 1.x is missing APIs they need, or
maintained by people who don't have time or incentive to migrate to NETStandard
abandoned, or
dependent on upstream packages that are one of the above

Leaving aside the System.* bits, for a lot of the other packages, maybe knowing that ASP.NET Core users can run on full .NET is making putting off the port to NETStandard a bit easier to justify? _"Yeah, we support ASP.NET Core, but only on full .NET for now..."_ For people who need to run .NET Core apps in Linux containers, or want to develop them on Macs, that's just as frustrating, and there's no "just stay on version X for now" workaround. There's just no NHibernate, no OData, no EF6, no whatever.

So if this is the kick in the pants that is needed for teams inside and outside of Microsoft to get their packages properly migrated to NETStandard 2.0 so they can be used by _all_ ASP.NET developers*, not just those running on Windows servers on full .NET, then that's a _good thing_.

*Remember, ASP.NET Core 2.0 running on .NET Core 2.0 doesn't need to _publish_ NETStandard packages to be able to _consume_ them.

markrendle on 10 May 2017

👍5

The comment directed @JamesNK for writing only a parser is truly classy, especially considering you dropped your own parser for his. Which is he wrote in his own time to move your platform forward.

Yes the full stack moves slower, but that also means you have time to get to know the framework. There is still a lot to be done in the normal framework so I don't really see why we need something like .Net core to be honest. If cross platform is a concern, you just bought Xamarin and they run .Net on almost anything. Including a freaking watch.

Maybe a roadmap?

boeremak on 10 May 2017

❤5

Dedelerimizin kaynak kodlarını okuyamıyoruz ve algoritmalarını anlayamıyoruz bir gece de cahil kaldık! .
Asp.net Core gelse ne olacak abi , kılıçdaroğlunda liderlik vasfı yok bi kere.

heustr on 10 May 2017

😕5 😄2 👎2

So if this is the kick in the pants that is needed for teams inside and outside of Microsoft to get their packages properly migrated to NETStandard 2.0 so they can be used by all ASP.NET developers*, not just those running on Windows servers on full .NET, then that's a good thing.

@markrendle If library authors followed ASP.NET Core logic, wouldn't they just jump to netcoreapp rather than netstandard? After all they can benefit from the new APIs too? Why bother with netstandard at all? ASP.NET is just another library after all (albeit a largeish one)

bencyoung on 10 May 2017

👍8

My case is exactly the same as mentioned by many others in this thread: My company has a large SaaS-application that relies on a large number of internal and third-party libraries that will probably never be made available for .NET Core. The plan forward was always to move to ASP.NET Core on the full .NET framework, and then slowly, over 5+ years, find replacements for these third-party components. This (non-)announcement has thrown these plans in complete disarray.

SebastianToet on 10 May 2017

👍16

I was under the impression that ASP.NET Core did not run on .NET Desktop framework. Edit. The documentation page states that ASP.NET Core runs on the full .NET Framework so it clearly implies support.

There seems to be another option, in case nobody has suggested this already.

After all, ASP.NET Core is open source. This means there could be two different versions of ASP.NET Core:

ASP.NET Core: targets .NET Core (netcoreapp2.0), the existing build
"ASP.NET Core Standard": another build, that targets .NET Standard (netstandard1.* and net4*) and runs on .NET Desktop Framework and other standard platforms as needed.

The Core build would be linked to .NET Core, while the Core Standard build will be constrained by what is available on netstandard1.* and net4*, and later .NET standard 2.0+; more slow moving, but more compatible. .NET Core can be better for greenfield and start-ups, and Standard can be great for brownfield, migrations and enterprises.

The path taken by Microsoft team makes sense as the main line option, Core is the future of the framework. Meanwhile, maintaining an additional target for netstandard should be possible to achieve with a minimum of effort. It can be an open-source project. Maybe that can actually be done by Microsoft too, in the spirit of compatibility.

This means that the "ASP.NET Core Standard" may not get all new features, but as this branch is for compatibility, the users that use this will have the confidence that they can use all supported features in the standard framework, and that the Standard branch will be available indefinitely on Github, and that volunteers can port fixes and updates from the Core branch to the standard branch.

If it was possible to maintain .NET Desktop framework compatibility in ASP.NET core for so long, then maintaining another build should not be such a big hurdle. Many other .NET projects do the same to multi-target, like protobuf-net, with some conditional compilation statements.

Basically, users that need Active Directory and System.Drawing can use ASP.NET Core Standard, but they will be limited to use Windows. However, their code will be ready to easily port to .NET Core once libraries become available, and at their own pace, with no risk of future lack of support.

I guess the question would be if the team would be able to provide such a branch. For fundamental libraries like ASP.NET, this may be necessary. I think the need to provide a path from .NET Framework to .NET Core will necessitate these types of stop-gap solutions anyway at some point. Software is flexible and this kind of solution will allow for the necessary transition to be smooth.

I think the extra effort of doing this should be seen as a small investment when compared with the significantly larger adoption and better migration it will offer to the community as a whole. Having thousands of more users will certainly help spawn more contributions to the project to offset the work of maintaining two targets.

vectorix on 10 May 2017

👎3

@bencyoung

If library authors followed ASP.NET Core logic, wouldn't they just jump to netcoreapp rather than netstandard? After all they can benefit from the new APIs too? Why bother with netstandard at all? ASP.NET is just another library after all (albeit a largeish one)

Well, if a library author were writing something that benefitted enormously from the new primitives and framework-level support for _BOBTRUES_, then I guess that would probably make sense (and I can totally see a good case for JSON or other serializer libraries that supported those, btw). But if the code in the package doesn't really care about _BOBTRUES_ or any of that stuff then you'd have to be particularly bloody-minded to write netcoreapp20 when netstandard20 _would work just as well_.

markrendle on 10 May 2017

@markrendle So you'd be happy for say Newtonsoft.JSON to do that for its next version, dropping support for any existing version with a year's timescale? You're happy for parsing, IO and high perf libraries to start dropping support for netstandard and .NET Framework?

bencyoung on 10 May 2017

👍9

Suggestion on how to fix this:

Make asp.net core 2.x run on .net and move the core-only stuff to version 3.x (backport the user facing features of 2.0 onto 1.x and call it 2.0)
Make it clear from the start that asp.net core 2.x will be the last version that works on .net, but give it a long lifetime.
Focus on making the tools for validating if a lib works on netstandard2.x better. The current guess work is what's freaking people out.
Focus on helping those libs that many use get netstandard2.x/core support. (Even if it's Windows only)
Adjust the communication between Microsoft and the community. Yes we want speed/features/etc, but many also need reliability/legacy. We need to find a better middle ground than this.

hallatore on 10 May 2017

👍12 ❤10

@vectorix: it was. The very first page on the ASP.NET Core docs, Introduction to ASP.NET Core says:

Next steps

...
An ASP.NET Core app can use the .NET Core or .NET Framework runtime. For more information, see Choosing between .NET Core and .NET Framework.
...

It links to a page that quite clearly says you can use .NET Framework (the full one).

For fuck's sake, that comparison page even says this:

.NET Framework will continue to be the natural choice for many existing scenarios and as such, it won’t be replaced by .NET Core for all server applications.

CMircea on 10 May 2017

👍26

Personally all it would take to make me happy is to say BOBTRUES will be in netstandard x where x doesn't even need to be defined. Otherwise you are saying netstandard is kind of already dead if you care about performance...

bencyoung on 10 May 2017

5 days later we are about to start BUILD event.

Let's wait and let Microsoft (hopefully) make an announcement and share their vision and roadmaps with everyone

PabloAlarcon on 10 May 2017

@CMircea: Thanks for pointing it out. That's indeed obvious. It seems that maintaining compatibility with .NET Desktop Framework would be necessary to follow the letter and spirit of the page.

vectorix on 10 May 2017

We have just finished a large job for a client that's ASP.NET Core 1.1 on top of .NET462 hosted on Azure. We've had to go this route as they do data refreshes to the site by uploading an MS Access db and we import the data in to Azure SQL. The only way we could do this (and it was a struggle) was to use the full framework. I don't really want to be in a position that I have to tell our client that this solution is only going to be supported for 1, 2, maybe 3 years if we're lucky. Telling them that they need to change their entire process to remove the Access issue isn't an option, I've been trying for years!

If there's a better option for reading an Access db, or it's in a Roadmap somewhere, then I'll be happy. Otherwise, this is concerning.

dsyrett on 10 May 2017

👍1

@bencyoung I think the big difference is that JSON.NET isn't an application, it's a library. I believe the intention is for library authors to target .NET Standard to ensure as broad compatibility as possible, whereas ASP.NET Core is an application model. The question I would have, is how much of ASP.NET Core's layers will be .NET Standard compatible, and what is targeting netcore? I have new code I've been writing against .NET Standard, but has references for aspects of ASP.NET Core layering, but made available as a library.

That being said, there is nothing stopping library authors from targeting netcore, instead of netstandard, but they risk reducing compatibility across a plethora of potential projects, whereas ASP.NET Core limits the damage to applications running on a (now) specific runtime.

Antaris on 10 May 2017

@Antaris ASP.NET is a library as far as I know. Kestrel is the application. You can OWIN self host ASP.NET Core in any application you want currently?

bencyoung on 10 May 2017

@bencyoung Fair point, poor wording on my part.

What I mean to say (if I can find the _right_ way of saying it), is that you use ASP.NET Core (as a stack) in one specific way - to run a web application. You can use a library like JSON.NET in many ways depending on your application model. Thinking about the moving parts of ASP.NET Core, things like Razor will still be built against .NET Standard, and these things generally could be used in other application models. Does that make sense?

Don't get me wrong, I'm not defending one approach vs. the other, but I benefit from working on a few greenfield projects, instead of integrating/upgrading with legacy codebases contingent on future compatibility with netfx. So I guess in that sense, I can't add much weight around the argument for increased compatibility (ASP.NET Core 2+ on netfx)

Antaris on 10 May 2017

@Antaris Thanks, although I'm not sure about that! We self host REST API's in the same process as WCF services for backwards compatibility, inside windows services....

bencyoung on 10 May 2017

Wow, what a terrible decision by Microsoft. First, .NET Core was going to be the new .NET, then Microsoft decides, we need to bring back as much of the old APIs as possible. Now they're leaving the folks behind who trusted Microsoft by starting ASP.NET Core projects with the full framework. I'm losing faith in .NET more and more everyday. Golang isn't perfect, but it's looking more and more attractive everyday...and if anyone hasn't noticed...it's gaining more and more traction. I thought Microsoft could capitalize on the Java community's inability to get anything done in short order, but .NET Core has been a complete disappointment and we've more or less been treading water for the past 2 years...and all we've gotten in exchange for it is cross-platform (who cares now that you can run .NET in a container on Windows Nano) and a ton of complexity (ridiculously terrible tooling, no F# support (VS), .NET Standard bingo.)

Update: I see a few thumbs downs here, but it's hard to have a meaningful conversation with emojis ;) What don't you agree with?

GiorgioG on 10 May 2017

👎5 😄3 👍2

Cross-plattform support is the main reason I switched to ASP.NET Core, and I think that I'm not alone with it. But that's not the only improvement of ASP.NET Core. There is more, like the modulared structure, which is of course highly needed on a framework, that is grown over the years. Buildin DI is also new.

The possibility to use the old 4.x framework together with ASP.NET core seems a good compromise for me: OS/Linux fans like me are not forced to use windows. But companys who really need Windows (like for AD authentication) can use them. I don't understand why microsoft is breaking this good middle-way. Especially now, when a lot of important namespaces from the old 4.x framework are not ported to ASP.NET Core yet.

DMW007 on 10 May 2017

@DMWOO7 Please don't confuse .NET Core and ASP.NET Core.

MartinJohns on 10 May 2017

Please don't confuse .NET Core and ASP.NET Core.

The irony. 😆

jnm2 on 10 May 2017

😄6 👍4 😕1

@MartinJohns I updated my post to make it more obvious.

DMW007 on 10 May 2017

@bencyoung

So you'd be happy for say Newtonsoft.JSON to do that for its next version, dropping support for any existing version with a year's timescale? You're happy for parsing, IO and high perf libraries to start dropping support for netstandard and .NET Framework?

Personally, I'd be fine with that, because I build web applications and services to run on Linux servers in containers, and I don't give a damn about anybody but myself and my own use case, which is why I'm in this thread.

Seriously, though, I wouldn't expect JSON.NET to drop support for netstandard, but I wouldn't be at all surprised to see somebody release a Core.Json library that works with the more-optimal-for-web-development netcore APIs.

markrendle on 10 May 2017

👍2 👎1

Welcome to the Python 3 of .NET. I had a feeling this will happen every since Core was announced years ago.

Eirenarch on 10 May 2017

👍9

Having ASP.NET Core target netcoreapp2.0 makes the most sense. .NET Core has provided a fresh start and a way to run applications on multiple platforms. Trying to drag all those APIs created for Windows along is just a train wreck waiting to happen. The Python 3 analogy is good and so is Python 3.

glennsills on 10 May 2017

OK, having read the thread I offer a little bit different view, obviously a marginal one:

I do not make web sites for living (still studying), from time to time I spin a smaller or bigger web site either for myself or for small companies/organizations. Sometimes, people come and ask for a technological advice.
I used ASP.NET from the beginning, but I have been mostly ignoring the "web forms stack" and directly processing and composing HTML - think Razor Pages.
Anything web related I ever made was always running on IIS. Cross-platform support is of no interest to me, though I am not offended by it.
I am too small to care about what is officially supported.
I generally don't depend on 3rd party libraries.

I would expect that it must have occurred to anyone who is following Microsoft that .NET Core might be getting more resources than .NET Framework and eventually the .NET Framework could end up in a maintenance-only mode. Also while missing APIs are being added, it is pretty clear that there was never the intention to provide feature parity with full .NET Framework.

The fact that ASP.NET Core runs on .NET Framework allowed me to stay at the front of development, maintain relevancy in the industry and have all the cool new things, while still have access to the full feature set of the framework (and the OS). I have tried couple of simple web pages in ASP.NET Core and was planning to start a bigger one too. Actually, I was planning to do all new development in ASP.NET Core on .NET Framework. Well, I guess no more.

Let me answer some of the questions (in no particular order):

Why ASP.NET Core 2.x and not 1.x
Razor Pages definitely. That's the way I work mostly. Stability and what others seem to call "maturity" would be another, although it has been suggested that fixes get backported. I would consider tooling to be a big impact if it got split.
That means postponing it to 3.x for me would do the trick.
Why ASP.NET Core and not ASP.NET
Well, in the light of this topic that is a fair question. When you have full .NET Framework, ASP.NET Core by definition adds value to it. Modern stack, tag helpers, unified API and MVC, newest features. Without full .NET Framework, not so much. Indeed, looks like going back to ASP.NET is the best solution for me.
New features or compatibility?
100% new features. BUT, switching strings to UTF-8 (and 4-byte chars!) or architectural refactoring are compatible changes to me. Taking features out is not.
What features from .NET Framework I use
The big ones I am worried about:
_System.Windows.Media.Imaging_. Definitely not ~~System.Drawing~. That sounds like counter-everything .NET Core is about. Since this is a long thread, quoting @JimBobSquarePants and @mstum:
> System.Drawing in particular is both confusing and concerning. I cannot fathom why you would ever want to port that API to .NET Core on any platform. It's difficult to work with, unsupported on the server, and lacks many critical features required for modern development (Multi threading, Pixel Formats, ICC, EXIF, Quantization, Indexed Png and so on).

Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. For a supported alternative, see Windows Imaging Components.

All my web imaging stuff uses WIC. Porting technology that was never supported while not porting the one that has been recommended for years would be a little disappointment (albeit understandable if that's what most customers demand).

_System.Windows.Xps_ and _System.Windows.Markup_. I generate all documents (from invoices to shipping labels) in XPS. You get design-time support when creating the documents in XAML and full-featured databinding, XAML layout including text stack, pagination, templates and styling with triggers etc. during generation - pretty cool.
_System.Reflection_ for inspecting assemblies, generating documentation etc. and filling in framework gaps.
Others that have been mentioned:
_WCF_ and _ServiceModel_, communication with government goes over this
_DirectoryServices.Protocols_ and NTLM authentication
Spatial types in SQL
Cryptography
Others I use but I believe are available: e-mailing, ZIP archiving.

At the end this is totally a business decision. For me, ASP.NET Core without full .NET Framework limits what I can create and I don't have convincing reason to use it at the moment. Happy to re-evaluate if situation changed or my living depended on it.
But I don't think it matters whether I am on the platform or not. It matters whether popular names and big enterprise customers are on. It matters whether the applications created end up in Azure and mine don't. So I guess I need to play along with whatever keeps the framework alive.

Whether this change keeps it alive and competitive is another question. To be fair though, I believe it does, as someone said above, targeting people who don't have .NET Framework background. For others, it's either worth switching or it isn't. And then there are people like me who thought could have the best from both worlds. The decision was abrupt and perhaps even unfair, but that's always the risk when working with the latest technologies in development. Happened with .csproj, now with .NET Framework and I am pretty sure it will happen in the future too.

PS. Pity this "never communicated" gap filling role has not been pointed out before. I was supporting the msbuild project system, but had it been clear .NET Framework is out of the plan in few months, I likely wouldn't have such interest in that (or felt I should have a say). I think it's fine to do big decisions, and better late than never, but it would help if the target audience was consistent.

miloush on 10 May 2017

❤2

At the end this is totally a business decision.

The problem is Microsoft is creating uncertainty. Big business hates uncertainty. Microsoft used to be the king of compatibility (good or bad, not my call.) Then .NET Core came about...breaking compatibility...then great news, we're going to add a bunch of the old APIs back...and now we have this ASP.NET Core 2.0 break.

Big business likes boring, reliable tech stacks. Startups care less, and it seems like Microsoft can't decide which group they're trying to please.

GiorgioG on 10 May 2017

👍9

@GiorgioG I am not sure I really understand why big business with existing apps would want to switch to ASP.NET Core then. It looks more like a fashion thing or something.

miloush on 10 May 2017

👍2 👎1

@miloush I think it's more about setting up for the future. If you transition your existing code base slowly to .NET Standard / ASP.NET Core but run it under the full framework you're positioning your code to be compatible with the .NET Core in the future so you don't have to make a huge, all at once, stop everything conversion when support for the old system is dropped.

Now businesses cannot do that because converting them to .NET Standard is not enough, you either have to drink the cool aid completely, or not at all.

Reanmachine on 10 May 2017

👍3

@miloush - say they started a project with ASP.NET Core 1.1 on the full framework. They can never move to ASP.NET Core 2.0 on the full framework. Is that acceptable? Sounds pretty awful for anyone in that boat.

GiorgioG on 10 May 2017

👍6

@miloush Because .Net core is more productive (I don't want to enumerate here all the tech advancements, you know them, merged API/MVC controllers, tag helpers, localization support etc) and because businesse do upgrade. What they don't usually do is big bang upgrades because well they can't afford discontinuity, they usually have to do it in small increments.

Completely different for a startup, who couldn't care less if support for a previous version is dropped. They have no legacy they have no problems of this sort.

popcatalin81 on 10 May 2017

@popcatalin81 - All this points can be reached with the full framewrok too, one is not in conflict with the other, the problem is the pace of development of one and the other, I see MS to much in a hurry to release a micro-service framework that looks good in the benchmark charts, it looks like it has become an obsession.

adrianlmm on 10 May 2017

👍5 ❤1

Would recommend watching:

"Three Runtimes, one standard… .NET Standard: All in Visual Studio 2017"

With the two Scotts in 45mins at Build https://channel9.msdn.com/ Might mention something?

benaadams on 10 May 2017

@adrianlmm Relevant but not strictly related, have we stopped drinking the micro-service koolaid yet? It adds a ton of complexity (build/deployment/operational/troubleshooting/etc) and most companies don't need them (how many companies need horizontal scalability that warrant the added operational complexities?) I'm all for bounded contexts, but we don't need 50 micro-services to do that.

GiorgioG on 10 May 2017

@GiorgioG my question was more why would they move to ASP.NET Core 1.1 in the first place. Well I did, and I do feel - not my best day, that's for sure. But I don't have a big codebase I would have to migrate and would wait how things settle a bit before committing larger investments to it. I mean even without any budget I was postponing a development of new bigger website on ASP.NET Core before it gets usable tooling and the future is a bit clear - turned out to be not such a bad decision. (Disclaimer: Again I never had to do this decision with big business codebase or when living off it, so bare with me.)

I am not blaming people jumping on (I did too with smaller things), and I definitely don't want to be defending the other side - I would be thrilled if ASP.NET Core supported .NET Framework forever!

What I don't understand much is how big companies where change and uncertainty is a problem got into the situation, 6 months after RTM and new toolchain requirements.

miloush on 10 May 2017

@miloush We've been "waiting for .NET Core to settle" for over a year. At some point people actually need to start....and deliver projects ;)

GiorgioG on 10 May 2017

@miloush They wanted to make use of the improvements of ASP.NET Core, but still have to use .NET libraries. And officially it was stated that you could choose between .NET and .NET Core. Now they're suddenly in a very bad situation: They can't upgrade to ASP.NET Core version 2.0, they'll be stuck on version 1.x. And at some point support for 1.x is running out - and new features won't come out for 1.x either.

MartinJohns on 10 May 2017

@GiorgioG , I've used .Net core for a new project so far, and migrated to Asp.Net core on Full Framework another one. Both active projects.

It's not that I don't want to use Net Core everywhere,I DO, but as a matter of fact that I CAN'T use it everywhere yet! That's the issue. We should leave wishful thinking aside and think of the real world first of all ...

popcatalin81 on 10 May 2017

👍5

@MartinJohns I got that, I am in the very same situation.

miloush on 10 May 2017

I'm afraid now, if it doesn't support full framework, we'd be me much trouble for our upcoming projects and pact-net-core is one of these.

garora on 10 May 2017

No choice but to drop ASP.NET Core and MVC. Support Dropped For ASP.NET Core MVC

YetaWF on 10 May 2017

😕6

And so we've arrived at the Vietnam of .NET. Bold move Microsoft, let's see if it pays off.

GiorgioG on 10 May 2017

No choice but to drop ASP.NET Core and MVC. Support Dropped For ASP.NET Core MVC
@shanselman Isn't it too early to decide this? Is there any public announcement/post saying this?

garora on 10 May 2017

I've done a couple new projects in ASP.NET Core 1.1 on the .NET Framework. Not thrilled that it's now a dead end. Wish I'd done them in old ASP.NET.

BowserKingKoopa on 10 May 2017

The Scotts are giving a talk to Build now, likely some news in or just after this talk. You can stream it live here: https://channel9.msdn.com/?wt.mc_id=build_hp

NickCraver on 10 May 2017

👍7

Thanks @NickCraver for sharing

garora on 10 May 2017

Tipical Microsoft.
After nearly 3-4 decades they could not develop decent browser.
nearly 2 decades - no framework with lifespan > 1 year with any future hope.
Thats it!.
thumbs down as much, fact won't change.

dvbava on 10 May 2017

👎18 👍3

Disclaimer: I have read a lot but not _all_ of the 500+ comments above.

What annoys me is that MS keeps acting as if we should just upgrade and asks "what holds you back?"

Damn, stop being delusional! 😡 .NET Core is not ready to replace .NET fx. Not today, not in a year!

Here's what holds me (my ASP.NET Core 1.1 project running on .NET fx) back:

I need money and time to do the migration for zero business improvement. Really hard to get from management.
Lots of testing required... zero business improvement but real regression risks.
We have to integrate with other enterprise services that expose COM api. I hate it but have no choice. @shanselman suggests creating an out of proc service on .NET fx and "being in a world of pain." Sorry, no, won't do that.
EF is a major reason I'm still on fx. MS get your own stuff straight and then you'll talk to us about migration. EF Core is nowhere near ready to replace EF 6.
Oracle DB provider doesn't support Core. Worse: they announced plans to port only their fully managed provider to Core, which has lots of limitations, e.g. no support for Oracle Advanced Queues.
We use many 3rd party libraries, some of which have migrated, some have not (yet or ever?).

@davidfowl
Your comments make me feel like .NET fx is slowly becoming obsolete... So do you plan to never support HTTP/2 in fx?
I'm sorry but you need to port much of your work to .NET fx, that platform is not dead. What if I want to do HTTP/2 from a WPF app?
I don't care if improvements are delivered to .NET Core faster or if some non-critical improvements are Core only. But .NET Core is not replacing .NET fx any time soon.

What is MS guidance for building a web app today on .NET fx (as I clearly can't do it on .NET Core)?

It's not that I'm craving for new features (I don't), but I would like to be on a living platform, not a dead one. Something that is maintained and that gets necessary updates -- even if slowly.

jods4 on 10 May 2017

👍29

Also Microsoft, consider this:

If ASP.NET Core 2.0 runs on .NET fx 5.0, this is an upgrade that I can, in time, organize.
It does not matter when you ship .NET 5.0 -- even if it's much later than ASP.NET Core 2.0 -- and it does not matter how long it takes me to upgrade from .NET 4.6. _I have an upgrade path and a future._

If ASP.NET Core 2.0 runs on .NET Core _only_, then I'm stuck in a dead-end.
As much as I would like to, I can't see a migration from fx to core in the next _years_. See above for why.

jods4 on 10 May 2017

👍5

@Kukkimonsuta has one of the best summaries above. In my case, the determinant for breaking ground on projects with Core-on-netfx was EF Core v EF6, along with other OSS toolsets that have not moved forward with netstandard compat.

One disturbing thing in this discussion has been @davidfowl and his respondents "talking past" each other: his response to the hew and cry is a bloodless "okay, but what APIs do you really need?" This is a commendable attempt to refocus the conversation, but he (more than likely unknowingly) is concealing a key problem. His (and @shanselman 's) other response is that this is required to keep ASP.NET Core "moving forward as fast as possible". Again a commendable goal, but again conceals a key problem. (Both of the problems concealed tend to be the core "concealed problems" with OSS in general.)

This isn't a merely psychological/emotional issue, either, as @MisterGoodcat would contend in his attempt at bridging the divide. @GiorgioG hit closer to the mark, with his contention that the "uncertainty" is something that "big business" doesn't like.

The problem, at root, is cost. Cost that's driven by uncertainty, and the cost of simply keeping up-to-date with an ever changing development landscape. These don't just hit "big business," they hit every single developer. Maybe not in monetary terms (up front), but certainly in time, stress, and therefore the ability to swiftly and confidently execute solutions to (yes) business problems.

Let's consider again the challenge-response of "what missing APIs do you really need?" Tracing that question back through a sizeable project toolchain, and probably back into third-party libraries. Just answering this question is costly, before even considering the cost of fixing it.

How about "moving forward as fast as possible?" Again, that's great, but with every "move forward" there are costs to developers of having to keep up to date with changes. This affects us both in the learn/use differential that comes with the job, but also in the learning curve and expense of finding and training new talent.

Most troubling is the attitude of some that the "edge-case" of dependencies on older, un-portable libraries is not a problem worth consideration. Granted, it's no place that anyone wants to be trapped, but addressing technical debt isn't a cost that should be shouldered on a non-stakeholder's schedule.

Now, while these costs aren't trivial, we all know and expect them in this line of work. In fact, in terms of moving to .NET Core I think that most were expecting that even if we weren't forced into it, going that way would be the right thing to do. The problems:

Pushing this now collapses the "amortization schedules" (sometimes years-long) most of us were working with, both in terms of making the move actively, and in terms of addressing technical debt (un-portable code).
The manner in which it is being pushed ("we're doing this for ~~our~~ your own good.") does not bode well for future stability: how do we know what future decisions will be made for us?

I was at the keynote in Vegas back when @shanselman pushed the button to open-source ASP.NET. Since then, MS has only been moving toward OSS. But this has always come with a question: along with the good of OSS, will the "bad" also creep into the Microsoft ethic? Put another way, what are we losing in trade for what we're getting? I think this is where we're starting to see it.

Another aside: I appreciate the idea from @markrendle, that this move will be a "kick in the pants" for every tool/library maintainer to actually move forward from netfx. Two problems with that, though: first, a timeline would have been enough. If there had been an announcement made of an N-year version cycle in which version M.0 would see the absorption of ASP.NET Core into .NET Core generally, that would have been enough of a "stick". I would be one of the first to wield it against maintainers of tools I consume (so to speak). Second, with this announcement, (and after taking a breath to see what the response to the negativity brings) tools that are focused particularly on ASP.NET (MVC or Core) will now most likely dispense with worrying about netstandard compat and just jump directly to .NET Core as well, further bifurcating the .NET landscape.

marcrocny on 10 May 2017

👍9

FYI .NET Core 2.0 Preview is out:
https://www.microsoft.com/net/core/preview

MJomaa on 10 May 2017

👍1

Reading through the Release Notes of Asp.net core preview I can't find anything on not supporting Full .Net framework.

It's already done in the bits, isn't it?

PabloAlarcon on 10 May 2017

Welp, one of my fears confirmed.

Near direct quote from MS Build talk: "70% of everything in NuGet are .NET Standard 2 API compatible... and the only ones that aren't are stuff like WinForms and WPF, because those don't exist on all the platforms. But everything else is there. No recompile. Just works."

This is incredibly misleading.

scottsauber on 10 May 2017

😕10 👍1

@PabloAlarcon This is the change you're looking for:

https://github.com/aspnet/Mvc/commit/1c5e4176069ea20671e1738ac599e544633f47ce

Dropping support for net46 as a platform target, most project files have this:

-    <TargetFrameworks>net46;netstandard1.6</TargetFrameworks>
+    <TargetFramework>netcoreapp2.0</TargetFramework>

I think what most people wanted this change to be was:

-    <TargetFrameworks>net46;netstandard1.6</TargetFrameworks>
+    <TargetFramework>netstandard2.0</TargetFramework>

Reanmachine on 10 May 2017

👍1

Oh, thanks, but I meant on the release notes of the just published Preview 1 : https://github.com/dotnet/core/blob/master/release-notes/2.0/2.0.0-preview1.md

PabloAlarcon on 10 May 2017

@PabloAlarcon I think that's one of the bigger problems here was the complete lack of communication about this issue ahead of time, to the point that even speakers at Build right now are quoting misleading info/stats about the ecosystem.

They're all claiming most libs are netstandard2.0 compatible, which means they should run everywhere (eventually) but this change actually means if your project even breathes in MVCs direction you can ONLY run it on .NET Core runtime.

Reanmachine on 10 May 2017

👍5

Those are the .NET Core 2 preview release notes, not the ASP.NET Core 2 preview release notes. This change would be here: https://github.com/aspnet/home/releases/2.0.0-preview1

And I guess it should be under known issues there and a list of breaking changes... but clicking the only link available there gives a github list with no results

bbarry on 10 May 2017

My bad, I read both pages but copied the .net core one.

Still the same, no mention in sight.

PabloAlarcon on 10 May 2017

@marcrocny you worded much better why I thought the "What libraries?" question detracts from the real issue at hand than I could, so thanks. I don't need new and shiny pronto, I need new features in a reasonable timeframe and them being stable and, more importantly, be supported for awhile.

10 bucks says HTTP2 is never coming to full .Net.

boeremak on 10 May 2017

Guess it's time for a community fork of ASP.Net Core.

popcatalin81 on 10 May 2017

👎6 🎉3

Switching back to full .NET Framework and NancyFX might be an option for a few depending on their reasons for switching to ASP.NET core in the first place.

dbus0 on 10 May 2017

👎4

@dbus0 The problem is once you leave the sacred, blessed land of Microsoft's frameworks you wind up with a tiny ecosystem of libraries that support it (in comparison to ASP.NET)

If you're going to ditch ASP.NET for the web, you may be better off choosing a non-.NET tech stack IMO.

GiorgioG on 10 May 2017

👍1

Can someone tell a list of features that aspnet core 2.0 make impossible ??

evilz on 10 May 2017

Guys, you are killing the once-beautiful .NET framework. The linuxesque way you are managing the .NET is only make everything look like a giant big hack. Everything in MS-dev is starting to look amateurish, disconnected, with every team/product going alone and on its own. Everything in BETA, everything InProgress, a big giant let's-try-and-see-what-happens, we joked, we promised not to do that yet..., do you really need that ? Why ? and so on. If we wanted things like those, we would have invested in PHP and Linux to have fun discussing how library X doesn't work with kernel Y because of package Z being incompatible so we need to rewrite all of our application just for fun.

Plus, I hate when teams hide behind marketing mantras like "moving faster", "explore the opportunities" and the like that only hide business goals behind fake technical reasons. I even started seeing some "this is open source - fix it yourself" replies here and there in the eco-system. What I understand is that we cannot trust a lot of MS technologies anymore, especially .NET Core that has no idea where it is going and why. I was already very upset but the madness of incompatible versions and breaking changes at ANY level and status of development in .NET Core (ASP.NET Core changing everything at RC? Oh please...) but the fact, as both developer and a business user, is that I cannot recommend nor decide on behalf of my company to invest into Core just to start endless discussions about how Core 1.0 does not support that while Core 1.1 does but we cannot upgrade it because it breaks this or that yet we would like to upgrade to 2.0 because we need that new features that only 2.0 has and... what ? Are you kidding ?

And it doesn't matter if this kind of approach breaks something or to understand what namespaces or features people is actually using in order to introduce a new late-time change to support features people might want. You are short-circuiting things by the worst behaviour I saw, that is no earlier planning because we can just issue a new X.Y.Z release and tell people to upgrade. If they can't, for any reason, bad luck. We will "support" v1.0 even if we are working at v8.0 except that you will have none of v8.0 features so our support will basically consist in patting your back when you will complain and state that life is hard.

I can't believe how many MS technologies we dropped in last two years. I never thought we could do that since we've been a Microsoft shop since 1998. Heck, in our area we're always getting hired when it's "a .NET thing" or "it's a Windows thing" (no questions asked - it's Windows -> call them) but today when I have to choose a technology for a new project I always wonder if it's sane to stay with the .NET framework, generally speaking. And for sure, after reading this, all our investments into .NET Core will halt at least until we understand what's going on with that. We absolutely have no will nor time to explain our customers why we need to rewrite that or this because .NET Core 1.1 is not compatible with 2.0 or that we need to create a small separate project that someone will need to maintain just to host a library that we need but that is compatible with an "old" version of the framework where "OLD" means a version that's been released 3 months ago. And still we would need to upgrade because of the "older" versions that will be maintained (MAYBE) but will receive no new features.

You have to know that such approach is making us reconsider the .NET framework as a WHOLE and reconsidering .NET framework means reconsidering Windows. And reconsidering Windows means reconsidering if we need Microsoft at all. It's not up to us to scavenge GitHub or some obscure forum to understand what features will be supported in vNext and compare them with vCurrent to understand if we can start developing targetting a BETA or Alpha release in order to be compatible with vNext because we need that specific feature so developing using an older version makes no sense at this stage but it's our risk to develop targetting a release that's not final and that might (and will) change only to start this madness again after a couple of months. That is not "agile", that's being kids with lots of free time.

I always knew that I would miss Gates but I never thought that I could miss Ballmer as well. Well done, guys.

tbprince on 11 May 2017

👍6

In my opinion it's somehow too early to switch completly to .NET Core. Lots of 3rd party frameworks and libraries currently do not support .NET Core at the moment. Take NServiceBus as an example. Please support .NET Framework at least until ASP .NET Core 3...

profabe on 11 May 2017

Official (related) announcement
https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

Preview 1 Issues

This preview version of ASP.NET Core 2.0 ships with support for the .NET Core 2.0 SDK only. Our goal is to ship ASP.NET Core 2.0 on .NET Standard 2.0 so applications can run on .NET Core, Mono and .NET Framework.

As the team was working through the last of their issues before Build, it was uncovered that the preview of ASP.NET Core 2.0 utilized API’s that were outside of .NET Standard 2.0, preventing it from running on .NET Framework. Because of this we limited Preview 1 support .NET Core only so it would not break a developer upgrading an ASP.NET Core 1.x application to ASP.NET Core 2 preview on .NET Framework.

benaadams on 11 May 2017

🎉60 👍9

Nice backpedaling there.

So all the feedback and "justification" in this thread for dropping .NET Framework was just for a Preview?

DamienDennehy on 11 May 2017

😄8 👎7 👍7

Notable that the change of heart wasn't announced here either...

willdean on 11 May 2017

👍7

@benaadams

Our goal is to ship ASP.NET Core 2.0 on .NET Standard 2.0 so applications can run on .NET Core, Mono and .NET Framework.

"We've always been at war with Eastasia"

Aaronontheweb on 11 May 2017

😄22 ❤4

That's comforting but some comments above from official ASP.NET Core members delivered a _very_ different message.

I would like an official statement about the mid-term future of ASP.NET Core with respect to .NET framework please.

Is MS committed to maintain ASP.NET Core compatible with netstandard?
Not just the ASP.NET Core 2.0 release (not necessarily on 4.7).

jods4 on 11 May 2017

👍9

Talk about a head-a-splode situation here. Just what is going on? :thinking:

tuespetre on 11 May 2017

👍1

Nice backpedaling there.

So all the feedback and "justification" in this thread for dropping .NET Framework was just for a Preview?

Hey, don't be a dick about this. They had a vision about what ASP.NET Core should be, lots of feedback has been given, and the feedback was listened to.

Thanks ASP.NET team 👍

JamesNK on 11 May 2017

👍58 🎉16

@davidfowl

When's the last time we changed string and array in .NET Framework?

In .Net Framework 4.6, for both. That's one minor version behind the brand new .Net Framework 4.7 and less than two years ago.

I'm not sure string and array are as hard to change in .Net Framework as you make it sound.

svick on 11 May 2017

@JamesNK

lots of feedback has been given, and the feedback was listened to

Was it? At least some of the feedback was complaining about insufficient communication. Now we have people from MS saying one thing in this thread, a slightly more recent blog post saying another thing and no information about the change or what the future is.

I would expect at least someone from MS to show up in this thread and to say that they changed their mind for ASP.NET 2.0 and that dropping .Net Framework is still on table for a future version, but they will inform us as soon as they know more (or whatever the actual situation is).

svick on 11 May 2017

👍7

I would expect at least someone from MS to show up in this thread and to say that they changed their mind for ASP.NET 2.0 and that dropping .Net Framework is still on table for a future version, but they will inform us as soon as they know more (or whatever the actual situation is).

In their defense (and not that I think this was handled well at all), the whole team is pretty much at Build. I'm sure we'll hear something here soon-ish. Nobody's lives are going to change due to this decision in a few days.

mattnischan on 11 May 2017

👍6

Hey, don't be a dick about this.

I spent several hours today and yesterday with my team in pseudo-crisis mode discussing the impact and change in technical strategy that this would cause over the next 12 months for us, only to be told "Oops our bad!".

I welcome the change, and I am grateful that we were listened to. While I'm not trying to be a dick, I am _pissed_ over the communication over this.

DamienDennehy on 11 May 2017

👍9 😕3

We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).
Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span and are looking at Buffer to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.
This leads to new methods on String that allow splitting that doesn't allocate an array every time.
This leads to overloads to Int, UInt etc (TryParse) that take Span and Span.
This leads to new encoding routines that take Span.
Buffer and Span let you represent memory in a uniform way and we want to upgrade the networking stack to allow passing pre-pinned buffers that take Span or Buffer.
Kestrel will implement HTTP2 in the 2.x timeframe (currently aiming at 2.1) and that requires new APIs on SSL stream to do ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http Client on .NET Core supports duplex streaming, it'll make it possible to implement streaming end points over http in signalr over a single, non websocket http request.
We forked the header parser implementations from HttpClient and System.Net.Http and renamed them (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) so that we could improve them and have them support both .NET Framework and .NET Core. .NET Core has a copy of these improvements haven't made it back because there no need to improve them (we couldn't consume them).
There are a bunch new threading primitives that require new API that will light up new scenarios if we're able to consume them (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+author%3Adavidfowl+label%3Aarea-System.Threading), those are just some of the things I've personally filed.

RIP modern platform. If the asp.net core team received a solution from above.

YuriiPovkh on 11 May 2017

I spent several hours today and yesterday with my team in pseudo-crisis mode discussing the impact and change in technical strategy that this would cause over the next 12 months for us, only to be told "Oops our bad!".

I welcome the change, and I am grateful that we were listened to. While I'm not trying to be a dick, I am pissed over the communication over this.

You're upset that they listened to the community and (seemlying) changed course? You spending time on something that was never finalized is not the community nor Microsoft's fault.

johnduhart on 11 May 2017

👍4

Great news!

simonmurdock on 11 May 2017

I hope this doesn't mean we now miss out on utf8 strings by default and the other goodies talked about by @davidfowl (if running on .NET Core)

danielcrabtree on 11 May 2017

👍4

Since the "no .NET Desktop support for ASP.NET Core 2.0" plan was finally cancelled, I think we can now close this thread (but don't hesitate to ping me if you want me to re-open it).

I'd like to thank everyone for taking the time to participate to this thread ; no doubt it helped make the Microsoft heads realize that they couldn't silently adopt such a major breaking change at the last minute without consulting their community or measuring the actual impact of their unilateral decisions on the entire ecosystem.

Even though we all had different opinions, the most important thing was to have a real discussion about this change. It's clearly a huge - and unprecedented - success (150 participants and more than 600 messages, woot!)

It's amazing to see such a great community in action, I'm so proud of being part of it :call_me_hand:

kevinchalet on 11 May 2017

❤56

@davidfowl @DamianEdwards @shanselman Thank you. This makes my life a lot easier, and we can push through our plans to migrate without uncertainty now, as can so many more. I know this isn't ideal for the ASP.NET team, but I sincerely think it's the best move at this point in time for the growth of the platform.

And this thread was handled remarkably well, even with some less than productive comments. Very, very rarely do you see an issue with hundreds of comments contain anything useful after a while (@davidfowl, you're awesome).

I look forward to having this discussion with 3.0, when I hope the platform is to the point dropping support is a much easier option leaving drastically fewer users behind. I look forward to helping get it there.

NickCraver on 11 May 2017

👍50 ❤22 🎉12

This outcome seems fine. I'm sure we can put together a roadmap some time soon, with a plan to move everything to core - just, over a period of time with everyone knowing about it in advance :)

gulbanana on 11 May 2017

Also wanted to leave my thoughts... It's great to see the ASP.NET team was able to swiftly course correct after listening to community feedback which I believe is the best strategy for a prosperous .NET future for both the .NET framework and ultimately adoption of .NET Core itself where I expect most adoption will come from existing .NET developers, many of which will be able to continue to migrate their existing code bases to ASP.NET's new development model.

I also don't fault that mistakes were made, especially when developing in the open, the important part is what we can learn from them. One of the biggest advantages of OSS is being able to get feedback early so you can make informed decisions about the best course for your project's future and its users, which I believe the ASP.NET team was able to do here. I hope it also reiterates just how important messaging is for both the direction, vision and roadmap for your project, how they form the basis for strategic decisions of early adopters and your most loyal stakeholders and how important it is to engage your community when proposing fundamental changes that can impact their existing and future investments in your platform.

Lastly of the 9 years I've been actively developing on Github this is the most active thread I've ever participated in with most comments able to remain thoughtful and courteous which bodes well for .NET's future showing just how many devs still care about .NET and are eager to adopt ASP .NET Core and follow MS into an exciting new multi-faceted future that .NET Standard and .NET Core will enable. Exciting times ahead!

mythz on 11 May 2017

👍20

Thanks for listening Microsoft!

GiorgioG on 11 May 2017

👍3 👎1

@davidfowl @DamianEdwards @shanselman Thank you.
Thanks Microsoft

ikourfaln on 11 May 2017

👍1

Holly cow! What hot mess did I miss? Well whatever the outcome winds up being in the end, I just hope it strengthens and not weakens the dotnet ecosystem. I'm okay with trying to innovate and needing to cut off the past at some point, but those references to become the next Python 2 vs 3 are all too real. Even though I'm not personally affected with my own projects, I'm glad to see all the developer support here. All these people taking a strong interest in the product with detailed examples of how it affects them confirms just how strong this community is. Thanks everyone for caring and keeping this community alive!

wizarrc on 11 May 2017

👍1

Well done to all!
Great news for OSS on .NET!!

schotime on 11 May 2017

👍3 👎1

@davidfowl @DamianEdwards @shanselman Thank you for listening the the feedback. Also, thank you personally for starting the discussion within our organization about how we can work to target .NET Standard for improved platform portability. My hope is that we can find a way to target all of our libs shared between our WinForms application and ASP.NET Core application to .NET Standard 2.0 so that we can, in fact, run our ASP.NET Core products on .NET Core in the future.

millman82 on 11 May 2017

👍4 👎1

See you again at version 3.0?

boeremak on 11 May 2017

On a positive note: I am glad you decided to change this. Makes my life as a developer a lot easier and my justification for investing time and energy in learning and developing in .Net a good one.

So thanks.

boeremak on 11 May 2017

Well, I don't think dropping support for full netFx is a mistake. On the contrary, the only mistake is that the ASP.NET Core supported the full netFx at the very beginning.

In other words, ASP.Net Core should NEVER be able to support the full netFx. It should be a web framework which is specifically built for .Net Core.

ASP.Net Core is supposed to be on top of .Net Core which implements a certain version of .Net Standard, and it should have nothing to do with the full netFx.

ASP.Net Core apps are able to run on whatever platforms/OSs as long as .Net Core can run on them. But it is just about the ability to run, not to support all the platform-specific features. If one really needs windows-specific features, he should use multiple-target nuget packages that support windows, or he should use ASP.Net instead.

So I think what the team's trying to do would've corrected the mistake. But unfortunately, you guys stop them successfully.

BTW, maybe changing "ASP.Net Core" to "ASP for .Net Core", and changing "ASP.Net" to "ASP for .Net Framework" would make sense of everything. And what you guys require is actually sort of "ASP.Net Standard" or "ASP for .Net Standard".

jarenduan on 11 May 2017

👎15 😕4 👍2

@davidfowl @DamianEdwards @shanselman Also joining my voice to thanking you for the decision.

.NET Framework is very important to us and we will never move beyond it unless the libraries we depend on are there as well.

Thanks for listing to the community.

pjmlp on 11 May 2017

👎1 👍1

Welcome to true Open Source

tinonetic on 11 May 2017

Great news! :) I hope Microsoft now knows that trust in a reliable, dependable future is key for many of us and they won't make this mistake again soon.

FransBouma on 11 May 2017

I'm honestly not sure why you all already celebrate. The blog post contradicts the statements of Fowler and Edward in this issue, and they have not yet retracted their statements or corrected them. The blog post was written by Jeffrey, yet another person. In this issue it was mentioned that the drop of .NET support was a deliberate decision that was made. In the blog post they mention that the lack of support was "uncovered". There was no mention in the blog post that they changed their plans after the backslash from the community.

So there's still a lack of clarity for me. Contradicting statements by different members of the team.

@DamianEdwards @davidfowl: Could you please provide clarity regarding this issue?

@PinpointTownes: Perhaps you should re-open this issue, as it's not as clear as you think it is.

MartinJohns on 11 May 2017

👍16

I'm with @MartinJohns. Does this mean ASP.NET Core does not profit from the fast-paced development of .NET Core @davidfowl talked about?

henkmollema on 11 May 2017

I'm also on the sceptical side. The vehicle has lurched back to be travelling in the right direction for the moment, but the evidence that the drivers are not properly on top of matters is stronger than ever.

The inconsistency between what's going on here, what's going on in the press releases / blogs and what we must all infer is going on internally is horrible. Out here in customer land, we're trying to make a decision about trusting MS with our business for the next X years, and this is a shocking way to go about trying to earn trust.

Look at the history:

Bad decision made in secret (bad)
Somewhat obnoxious attempt to justify it (somewhat good, somewhat bad)
Reversal of bad decision (good)
Attempt to gloss over the first three steps (appalling)

It's a pity that Build is such an overly-glossy wankfest, because the sensible thing to have done in the two Scotts' show yesterday would have been to throw away the powerpoint, put the half dozen senior .NET people on plastic chairs in the middle of the stage and take the shit manfully while explaining their position reasonably.

Instead they completely ignored the elephant raging around the room and are now apparently trying to pretend nothing ever happened in the first place.

The bad decisions and the reversals are a natural part of the development process and with OSS you get to see them - that's fine. The corporate cover-up is not.

.NET is a tool for MS to sell Azure, which is a proposition that requires even greater long-term trust than just choosing a dev framework. How's that trust-building going this week?

willdean on 11 May 2017

👎4 👍1

I second @MartinJohns here: they couldn't target netstandard2.0 as the sky would fall otherwise, and now they can. (Of course they can, there's no technical reason for not being able to, but according to @davidfowl and @DamianEdwards it was needed). How are they now going to do this, what has been decided now? I know it's //build and all, but they aren't that understaffed that no-one can come to this thread and explain things a bit. Or do we all have to message our favorite Microsoft employee and ask via backchannels? I truly hope not.

FransBouma on 11 May 2017

the sensible thing to have done in the two Scotts' show yesterday would have been to throw away the powerpoint, put the half dozen senior .NET people on plastic chairs in the middle of the stage and take the shit manfully while explaining their position reasonably.

@willdean The vast majority of the people watching the Build keynote or Scott²'s session had no clue about this going on in the first place. It's perfectly understandable that they didn't want to drag this mishap into the light, leaving hundreds of thousands of devs just as confused as this thread if it was just a mistake and they'd decided to do go back on the decision anyway.

Let's give the team some slack and hope for a good explanation/postmortem after Build :smile:

khellang on 11 May 2017

👍15

The vast majority of the people watching the Build keynote or Scott²'s session had no clue about this going on in the first place.

That's a fair point.

willdean on 11 May 2017

@FransBouma They can support netstandard2.0, but it will be painful in terms of polyfills, cross compiles and extra code. Some features might also be practically impossible to implement until certain new features are in place, like http2.

But it's not impossible. It's just a lot of extra work that everyone would rather not do.

The whole core ecosystem is a balancing act between innovation and legacy support. We need enough legacy support to eventually have most stuff on core, but enough innovation to make core an attractive platform.

I hope for a good postmortem, but it's enough to address it here. Posting a blog post would just confuse the 99% that didn't know this was ever an issue.

hallatore on 11 May 2017

👍1

@hallatore "It's just a lot of extra work that everyone would rather not do."
I feel you. I personally would rather start green tomorrow but nobody is giving "me" that option ... because you know, reality ...

Let's not forget that ASP.Net is an "ecosystem" with CMSes, 3rd party libraries, components, software built over a 17 years lifespan. You can't just drop the ball on your ecosystem and community and say we really want to use fancy strings even if it means leaving you all behind ... you "just can't" ... it's the worst you could do to a supporting community.

Want to take advantage of advancements, then by all means, build platform specific code paths and take advantage. This way over time the user base will switch to take advantage of platform differences. But in under no circumstances is ignoring the "needs" of large part of your ecosystem a wise option.

popcatalin81 on 11 May 2017

@hallatore

They can support netstandard2.0, but it will be painful in terms of polyfills, cross compiles and extra code. Some features might also be practically impossible to implement until certain new features are in place, like http2.

Nah. It's just code, C#, written and then run. I seriously had to laugh when I read the list of things they apparently can't do on .net full and had to do the break with .net full because of it. It's just politics. We outsiders have to write very fast code on .NET full, have to deal with these api's and have to make the best of it. We do that. We solve the same problems they have to work with too. So can they. They just don't want to do that. But frankly I'm too old and have dealt with Microsoft soaps too many times to take that seriously anymore. Let them keep the internal politics in Redmond and don't let the users (us!) suffer because of it. As we already have done that many times before, mind you.

I hope fore a good postmortem, but it's enough to address it here. Posting a blog post would just confuse the 99% that didn't know this was ever an issue.

Yeah a blog post is not the right place. This thread is the perfect place for how they're going to solve it now.

FransBouma on 11 May 2017

👍5

@FransBouma

Core contains a lot of new features that was made because of the research put into asp.net core and kestrel. It's not the C#, it's that the code uses stuff which doesn't exist in full framework.

As @davidfowl said. They have polyfills for most of the current stuff. But they are starting to see stuff they cannot even polyfill. Which means they most likely need to either drop stuff or make changes to the full framework. And the work required getting new features into full framework vs core are huge, and have a much longer time frame.

And then we are back to the balancing act. Should we limit core because of full framework, or should core be able to innovate at a higher pace than what asp.net ever could?

I understand very well why they wanted to only support core. And from a purely tech perspective supporting full framework adds a ton of stuff they now need to account for. But the ecosystem and community is not ready for core only (as we clearly see), and the price for that is a more complex asp.net core development.

hallatore on 11 May 2017

@hallatore If you want to break compatibility you announce it ahead of time and announce a migration path. One way or another you invest giving your users a migration path.

This is more or less the price of having users, and having users it is not an annoyance, it's a responsibility.

I don't think we are debating whether or not it's more work to support more platforms. It is. The cost is higher the code paths are more complicated, etc, etc. Can you get rid of this cost and chose single platform ? Well most of the answers here, meaning the voice of community, say that not at this time, the ecosystem is not ready. Which means the responsible thing to do find a middle ground solution of a sort.

popcatalin81 on 11 May 2017

👍3

@hallatore

Core contains a lot of new features that was made because of the research put into asp.net core and kestrel. It's not the C#, it's that the code uses stuff which doesn't exist in full framework.

Well, then port it over. They own both, I don't see why there is any problem. Mind you: they can port the code over by simply creating a netstandard2.0 library, or even better: create shim that targets the faster implementation in .net core and a slower implementation in .net full (with e.g. a lib from nuget).

I generate IL at runtime to get superfast projections from datareaders in my ORM. I don't throw my hands in the air 'can't be done!', as no-one will solve it for me. I bet you have had similar issues where you simply had to dig in and make it work as no-one else would pick up the tab. They now have to do that too.

They have polyfills for most of the current stuff. But they are starting to see stuff they cannot even polyfill. Which means they most likely need to either drop stuff or make changes to the full framework. And the work required getting new features into full framework vs core are huge, and have a much longer time frame.

Sorry, but what things can't they 'polyfill'? Yes, they have made a terrible mess on .NET full and performance is terrible at places and to make things perform like the competition they have to make tough choices. Well, solve it. And not in some corner, but solve the core problem: On java they could solve it too, their performance is amazing, and they did that by not breaking any core API nor by creating a second platform. It's just software: keep the interface the same, solve the back end. Yes it's a lot of work, but do you think making e.g. an ORM fast is done overnight? :) Or making a webservice perform well so it can run the critical business logic for a large corp? No, it takes effort. And that's OK.

The real elephant in the room here is .NET full and how it's managed. Or better: the lack of management there. I know they can't introduce breaking changes. Well, then introduce changes which don't break. If you look at Win32, they've never introduced any breaking change. Stuff simply works. Yes, things grow and the group of people who would rather cut everything out will grow by the day but that's irrelevant: we all deal with software which has parts which were once important and now not so much but we can't leave them behind/cut them out nor change them, as it will break people's code.

And then we are back to the balancing act. Should we limit core because of full framework, or should core be able to innovate at a higher pace than what asp.net ever could?

It has been mentioned a couple of times, but I don't see why you can't innovate on the full framework with the same speed. We all have to innovate our own software on .net full. I get that there are bottlenecks in e.g. string support, but if you need a no-copying string, then create one and move on. Yes you can bikeshed for the next ten years how ugly it is, or you can introduce that class, build your fast stuff on it and make progress. I've been doing fair share of C++/x64 assembler on win32 lately and if you see how many times they redefined strings there and apparently no-one bets an eye, we on .net will be totally fine. I mean, we already have two string types (array of char and string).

I understand very well why they wanted to only support core. And from a purely tech perspective supporting full framework adds a ton of stuff they now need to account for. But the ecosystem and community is not ready for core only (as we clearly see), and the price for that is a more complex asp.net core development.

Believe it or not, I too fully see their point why they want to break away from .NET full. I mean, my own runtime/API is 14 years old at places, I too want to break way from some parts of it yesterday. However I've also learned that I can't, for the simple fact my customers will be hurt by that and that's bad for them and for me. When you create a platform / runtime / API, you have to take into account that after the first release you do, you are on a path you can't get off of: your API is from that moment on set in stone. You can deprecate the crap out of it, but you can't remove things so users of it will break. Angular 1.x->2.x, python 2.x->3.x, Examples enough.

FransBouma on 11 May 2017

👍7 ❤3

You can't package changes to BCL primitives in a netstandard package. If you want to change System.String and System.Int32, you need a different BCL.

And you can't innovate on the full framework with the same speed because every update to full framework is an in-place update over the version before, with billions of lines of code in the wild depending on every possible combination of features (including undocumented features). The reason you can innovate faster on .NET Core is that you can have applications targeting all the different versions of .NET Core all running isolated on the same server, each with their own copy of the runtime. That's the whole point of it. They built it so they could iterate faster. Now they want to take advantage of being able to iterate faster.

Personally I think the mistake was supporting full .NET from ASP.NET Core in the first place. It should have been a clean break right from the start.

markrendle on 11 May 2017

👍12 👎2

Personally I think the mistake was supporting full .NET from ASP.NET Core in the first place.

Honestly, they needed to 2.0 tooling and the compat shim to even make this remotely feasible, so IMO, this is the earliest they could've done it. Delaying just lets people delay conversions, and delay yelling at Microsoft about how they hate their users. You know whenever they do this -- with whatever kind of warning -- people will lose their fucking minds over it.

Frankly, the majority of this thread makes me very sad for the .NET community.

bradwilson on 11 May 2017

👍6 👎5

You can't package changes to BCL primitives in a netstandard package. If you want to change System.String and System.Int32, you need a different BCL.

Yes, I know and that's not what I implied to say. I see some people misinterpreted my post in that light, but that's not what I intended. If I may, I'd like to give an example which is on topic here: inside my ORM I use string concatenation too, for creating query strings. This is a huge overhead, for every ORM. Using the default string class for that is helpful to a point but it gets ugly with all the copying. So I introduced specific classes which mitigate that copying to a great deal or avoid it at all. This has downsides, as you can't use them where a string type would suffice nor can you use them with all the APIs that take a string instance. However you _can_ use them where you yourself need them the most: on the hotpath through your own code.

This isn't ideal _by far_, and if one can avoid this, obviously one should. However life's messy and the things we release stay there forever. You can't change things that are already out, so you have to deal _with that situation_, and one of the solutions for that is by introducing new types and new code working with these types. This approach is used in all major OS APIs for many years and while it sucks as it's butt ugly, it's a proven method to move forward instead of staying in a deadlocked past.

FransBouma on 11 May 2017

Another proven method to move forward instead of staying in a deadlocked past is just to accept that haters gonna hate and break things anyway (cf. Angular 2+ and Python 3, both of which are doing just fine).

markrendle on 11 May 2017

@NickCraver I bet you $100 that whenever they finally make this break, whether it's 3.0, 2.2, or 23.5, there'll be just as much wailing and rending of garments from the peanut gallery as there is today.

markrendle on 11 May 2017

Another proven method to move forward instead of staying in a deadlocked past is just to accept that haters gonna hate and break things anyway (cf. Angular 2+ and Python 3, both of which are doing just fine).

Sure. Both have consequences though: the 'OS API' method is ugly and leads to a large API with many dead ends over the years. The 'angular/python' method breaks people's upgrade path and splits communities (dunno how fragmented the angular world is). In the light of ASP.NET core I don't know what route is better. From a technical point of view, the Python route is preferable of course. From a stability point of view, it's killing iMHO.

FransBouma on 11 May 2017

Pretty much everyone in the Angular world went "oh, yeah, that's _much_ better" and starting migrating over. Python is one of the fastest-growing languages right now, and it's Python 3 that's driving that.

markrendle on 11 May 2017

Personally I think the mistake was supporting full .NET from ASP.NET Core in the first place. It should have been a clean break right from the start.

Clearly there's some cost saving to that idea, but it's the complete opposite to the way MS built its totally dominant position:

Windows ran DOS applications
32 bit Windows ran 16 bit Windows applications and DOS applications
64 bit Windows runs 32 bit and 64 bit applications
.NET applications ran on all the relevant operating systems when it was released

These have been hugely difficult technical challenges and hugely expensive compromises, but they have reassured an entire generation of people who need to get stuff done using computers that MS is, roughly, on their side for the long haul.

It's hard not to look back at what was involved, technically, in things like the Win32/Win16 interop story or running DOS applications on Win3 -> Win95 -> WinNT and wonder if the grown-ups left the building some time ago.

willdean on 11 May 2017

👍10

@markrendle

Pretty much everyone in the Angular world went "oh, yeah, that's much better" and starting migrating over.

You honestly want to compare Angular with the .NET runtime? Most people would love to immediately migrate over to .NET Core. But realistically they just can't. Either plenty of dependencies are not available, or there's a too high risk or simply too much cost.

MartinJohns on 11 May 2017

👍2

@markrendle

Pretty much everyone in the Angular world went "oh, yeah, that's much better" and starting migrating over. Python is one of the fastest-growing languages right now, and it's Python 3 that's driving that.

I think you're papering over the fact that Python 3 has been out for 9 years and finally it's becoming the default Python to use for new projects. However, my Mac running the latest OSX...comes with Python 2.7.12. My NAS, same.

Same goes for Angular - it's great if you're writing a dinky little demo app that you can port over to Angular2 in a matter of hours. Out here in the real world, we're still using Angular 1 because migrating a 2-3 year old large application is a non-trivial effort. It costs time and money to port and the business wants justification.

GiorgioG on 11 May 2017

👍8 😕1

Is it possible to create a software driver somehow like the IA-32 Execution Layer?

stefan2410 on 11 May 2017

😄1

@bradwilson

Frankly, the majority of this thread makes me very sad for the .NET community.

Will you lay no blame at Microsoft's feet here for their mis-steps that got us here in the first place? .NET Core was supposed to be a clean break. Then it wasn't. The fact that they named it ".NET Core" implies you know...the Core of .NET is there right? And what is .NET? Well for the past 15 years it's been .NET Full Framework. If Microsoft wanted a clean break, it should have chosen a new name for this thing, stuck to its guns rather than go back and reintroduce all the old APIs, and let people choose between the old world and the new. The decision they're backpedaling on now would have left projects in one of 3 situations:

You're using ASP.NET MVC on the full framework and you can port to ASP.NET Core 1.X on full framework, but after that, you're SOL until you move to .NET Core.
You're using ASP.NET Core 1.X on the full framework and you must to port to .NET Core to move to ASP.NET Core 2.0
You're working on ASP.NET Core on .NET Core.

Assuming Microsoft had gone forward and not supported ASP.NET Core 2.0 on the full framework, folks in situations 1 & 2 had no clear/realistic path to moving existing applications to ASP.NET Core 2.0. Folks in situation 1 might understand, but those in 2 would be justifiably angry. Situation 2 might be a small group, but this is Microsoft we're talking about, not some tiny open-source project maintained by one guy. Businesses / people's livelihoods depend on these systems. If they can't rely on Microsoft, next time you can bet your ass they won't use the platform. Trust matters. In shops that are considering using a Microsoft stack - opponents would use this as a cautionary tale.

I lay the blame for this problem on Microsoft's terrible messaging / marketing / naming of .NET Core. You can't please everyone all the time, but half the battle is setting the right expectations from the start.

GiorgioG on 11 May 2017

👍16

@MartinJohns I was responding to the previous comment.

markrendle on 11 May 2017

@markrendle why laugh? explain please. if the "API is pretty much the same" , the fundamental changes like the strings maybe can be handled by this way. and If there are changes in the API, could be a separate package only if somebody wanted to use it, in .Net Core ?

stefan2410 on 11 May 2017

OK guys - think Internet Explorer. Microsoft is _finally_ killing it off. Of course, they waited so long to do so that their replacement browser, Edge, is probably still born in the marketplace. Everybody just uses Chrome. And still there are lots of places where people use IE because there is no business value to upgrading their apps to use a modern browser and there are still people who complain about Microsoft ever so slowly pulling the plug.

ASP.NET Core is Microsoft's shot at replacing .NET with something based on what we have all learned in the last 15 years or so. Making it easy for developers to continue using the .NET Windows frameworks while providing the new ASP.NET Core features smells a lot like IE 9. Better to tie support for .Net 4.x to the support lifetime of the OS they were shipped on and move on.

glennsills on 11 May 2017

👍1

@glennsills I'm missing the parallel between IE & Edge. IE still ships with Windows because some things won't work in Edge. I'm not mad that Edge doesn't support my work's VPN - it's fine...it's a different browser. It even has a totally different name so I don't have any preconceived notions that it should support ActiveX ;)

GiorgioG on 11 May 2017

👎1 👍1

@glennsills what mistakes do you refer to?

popcatalin81 on 11 May 2017

@markrendle "Pretty much everyone in the Angular world went "oh, yeah, that's much better" and starting migrating over. "

You really are doing your arguments a disservice by picking bad examples like this. If anything, the way they handled the transition cost them their lead (which they had by a wide margin at the time).
Same with python 3 - the fragmentation killed any momentum they had for years.

dahauns on 11 May 2017

👍9

So, I'm just trying to understand something here.
I was planning on converting an old Asp web forms application which uses .Net Remoting over to an Asp .Net core MVC application. My plan was to continue using .Net Remoting until we get a chance to remove that crap from our system. By the sounds of it, if I targeted Asp .Net Core 2.0 I will not be able to do this? But if I targeted Net Core 1.1 I would?

wbuck on 11 May 2017

@wbuck As of yesterday, the story is that it's only in a single preview version of the ASP.NET Core 2.0 that you won't be able to build against the full framework. Presumably in 2.0-preview-2 they'll bring this capability back. So for the moment you could target 1.1 but not 2.0-preview-1.

Who knows what the longer-term future is - clearly the full framework will eventually be dropped - the timescale is anyone's guess.

willdean on 11 May 2017

@popcatalin81 Well, if you want to run on multiple platforms, access COM objects is definitely a mistake. There are lots of things like this that might not be 'mistakes' if you are only going to run on Windows but are if you want to be cross-platform. Think about the coupling of AspNET to IIS. At the time it was OK but over time it made the stack hyper-complicated (even on Windows) and it makes running applications on other web servers a pain. The lack of dependency injection by default in ASP.NET makes unit testing things like controllers a real drag. This is less of a 'mistake' that an example of time marching on and people understanding a better way to do things.

@GiorgioG - yeah that's sort of my point. You get to choose between IE and Edge on Windows 10, but you have to _choose_. You don't get IE features in Edge and that's on purpose - making IE and Edge features work simultaneously in one process would be a white hot mess. Also, future support for IE is limited to bug fixes. If Microsoft had done this 10 years ago, Edge would be much more competitive to Chrome than it is now. So I think Microsoft should continue to support .NET Classic for quite some time but in more of a bug fix mode. Asp.Net Core should focus on cross platform ease of development and performance.

glennsills on 11 May 2017

Is there any official announcement for the cancellation?

pantonis on 11 May 2017

@pantonis

Is there any official announcement for this?

No, there is not. There are contradicting statements by different team members. @DamianEdwards and @davidfowl said in this issue that it was a deliberate decision to drop support. Jeffrey wrote on the ASP.NET Blog post that support for .NET will continue. But they did not refer to each other.

MartinJohns on 11 May 2017

Hi guys,

I didn't jump on the issue thread this time around but I'm very satisfied with the time it took to rectify the message and the direction.

I understand that the initial decision was taken at the last minute to make everything works prior to BUILD. Stating your intentions to have it run .NET Standard 2.0 is also very reassuring.

Thank again to the .NET Team for the fast feedback and trying to get our needs despite all the unproductive comments.

Very appreciated.

MaximRouiller on 11 May 2017

👍2

@MartinJohns Oh boy.. So who is correct?

pantonis on 11 May 2017

@wbuck

Your future use of .NET Remoting is emblematic of the problems created by promising people backward compatibility. Remoting just didn't work out for a variety of reasons but because people used it in the past (to be fair because somebody at Microsoft told them this was a good idea) they still want to use it. Accessing information in an ASP.NET Core application via WEB API is quite easy and you can call it from very old .NET @@frameworks.

As a snarky co-worker of mine once said 'we need to stop building new legacy applications'. Building a ASP.NET server application that supports .NET Remoting is doing just that.

glennsills on 11 May 2017

@pantonis Frankly, no idea. Many people in this issue jump ship and immediately take the blog post as a revert of the decision stated in this issue, because it came later. But I believe the statements in this issue and the blog post were made independently, and we still have no clear statement.

MartinJohns on 11 May 2017

👍1

@pantonis the most recent is the official announcement in the blog post

https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

Preview 1 Issues

This preview version of ASP.NET Core 2.0 ships with support for the .NET Core 2.0 SDK only. Our goal is to ship ASP.NET Core 2.0 on .NET Standard 2.0 so applications can run on .NET Core, Mono and .NET Framework.

As the team was working through the last of their issues before Build, it was uncovered that the preview of ASP.NET Core 2.0 utilized API’s that were outside of .NET Standard 2.0, preventing it from running on .NET Framework.

Because of this we limited Preview 1 support .NET Core only so it would not break a developer upgrading an ASP.NET Core 1.x application to ASP.NET Core 2 preview on .NET Framework.

benaadams on 11 May 2017

👍2

@benaadams But the statement in that blog post makes no sense in correlation with the statements made here. In the blog post they just mention that it was "uncovered" and that they limited "Preview 1 support". In this issue they mentioned the whole time something else. And they made no reference to the discussion here in the blog post.

It would be great if we could get an official acknowledgement of the statements in the blog post here in this issue. Or make the blog post acknowledge the discussion made here. Something so we know these different persons are aware of each others statements.

MartinJohns on 11 May 2017

The blog post is an official communication which clearly supersedes the unofficial community discussion we had here. And if it doesn't entirely match up, well, I'm sure we all understand the exigencies of corporate communication and that telling the right story to the right audience can be more important than being technically correct.

There's no need to try and make specific people eat their words or something - what's important is that the direction chosen seems to be a good one which, we can safely infer, was responsive to our feedback.

gulbanana on 11 May 2017

👍10

I hope Microsoft will issue a statement which clears the confusion. Come on MS you can do it!!!

pantonis on 11 May 2017

@pantonis @MartinJohns

I can only confirm this unofficially since I'm not with MS.
The blog post from yesterday is the plan forward, and those working on asp.net core are very much in line with it.

tl;dr: This is the plan forward: https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

hallatore on 11 May 2017

@pantonis The official announcement is the official statement.

MaximRouiller on 11 May 2017

statement?

pantonis on 11 May 2017

@PinpointTownes: Perhaps you should re-open this issue, as it's not as clear as you think it is.

Done 😄

kevinchalet on 11 May 2017

@pantonis just a few comments above.

https://github.com/aspnet/Home/issues/2022#issuecomment-300774201

MaximRouiller on 11 May 2017

I hope Microsoft will issue a statement which clears the confusion. Come on MS you can do it!!!

To be fair to them, they're all too busy prancing around in a state of forced super-excitedness this week to be wasting time here. And given that every explanation of .NET Core ever given has only served to reduce the level of understanding in the world, perhaps it's better just to let things lie.

willdean on 11 May 2017

👎9 😄1

Just to make things clearer to anyone reading this far...

If a more recent official announcement contradicts anything in this thread, we should consider the public official announcement as overriding what was said before in this thread.

Official Blog Post > GitHub comment

It's not written anywhere but, for me, this rule has held true for a long time.

MaximRouiller on 11 May 2017

👍2

@MaximRouiller

If it wasn't the case then @benaadams would probably know.
And I also talked to @davidfowl a few hours ago. The announcement is correct.

Edit: This announcement: https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

hallatore on 11 May 2017

@hallatore Which announcement? On the ASP.NET blog post from Jeffrey or the other one?

pantonis on 11 May 2017

Let it go.

The statement is that .NET Framework isn't supported in ASP.NET 2.0 preview 1; however they are planning on supporting it after that. The sky is no longer falling in.

To continue complaining about it after the fact; will likely justify them engaging less, sharing ideas less, involving people at early stages less, so informing people at much later stages; with more clinically analysed responses; when its also harder to change direction.

If you jump on someone for making, in your view, a wrong decision; then they change their mind based on your feedback; then you rub their nose in it for changing their decision - how do you think that will play out for future relations? Its going to get dysfunctional really fast.

The newer more open MS; which directly engages with developers and customers is exciting. Please don't though your actions shut it down and make everything have to go via public relations approval first. That's not good for anyone.

Be a little more professional and consider how we all move forward, together, for a better ecosystem.

benaadams on 11 May 2017

👍34 ❤12 🎉2

@benaadams You're confusing the wish for clear communication with complaint. This is by far no attempt to drive anyone away, but the wish for them to further engage and clear confusion. You say they changed their mind based on our feedback - which is great. But the blog post makes no mention of this, so it's purely your assumption that this is the case.

This breaking change was poorly announced. The apparently reverted decision was poorly announced. I don't wish for less engagement, but for more engagement.

MartinJohns on 11 May 2017

👍7

@MartinJohns In public announcement, you talk about the NOW and what IS.

Not how you got to that point. The fact is exactly what @benaadams said.

^Insert Let it go GIF here^

MaximRouiller on 11 May 2017

👎1

@benaadams agreed. It might be a good thing though that within time (i.e. after //build) some more technical info is provided what the consequences are for the list of items @davidfowl put forward which were difficult/hard to do on .net full and why they needed the clean break. I see no reason why that should be done elsewhere than in this thread though and informal, developers to developers. IMHO it would both give more insight in future plans what to expect now from aspnetcore 2.0 and what now can't be done in this timeframe and thus has to be postponed. It also would help regain the trust of people here who lurked/only read the thread (and drew their conclusions...) and people here who have doubts still.

FransBouma on 11 May 2017

👍1

As we've had a very long, good discussion going on for a few days, I would also expect an 'official' announcement here in this thread rather than sudden silence and being pointed at an announcement on a blog with no mention of this discussion.

That doesn't change the fact that if the announcement is correct, this is good news of course.

razzemans on 11 May 2017

👍1

Sorry about this but i just want to clear my understanding of this up

using the above diagram as an example are we actually saying one way or another the future of ASP.NET Core is not actually to sit on the .NET Standard layer due to slowness but to have ASP.NET Core sit on .NET Core instead? whatever future version of this it will be in 2.0 or 3.0 etc.

so for example:-
.NET Core -> ASP.NET
or will it still be .NET Standard -> .NET Core -> ASP.NET Core

lilpug on 11 May 2017

@lilpug That's the kind of diagram which illustrates my (unpopular ;-) point about the explanations only making things worse. ".NET standard" isn't a library, and ASP.NET Core shouldn't be inside a box that is a peer of .NET Framework.

The diagram is basically wrong and you should disregard it.

willdean on 11 May 2017

👍8

Hi @willdean would you be able to supply a better example which is more appropriate?

but to be honest i used it as an example not to point .NET Standard out as library but more of an inherited position, putting the terminology aside i would still like to know if my view of this is somewhat correct in what i am thinking?

lilpug on 11 May 2017

would you be able to supply a better example which is more appropriate?

No, I think it defies representation in a diagram, or at least it defies the abilities of the authors of every diagram I've seen. Even when @shanselman (a consummate communicator) writes an article trying to explain it all, it ends up with a bunch of "terminological exactitudes" to put it politely.

All attempts to put ".net standard" on a diagram which has a bunch of code libraries on it are doomed, because it's an API spec, not a library, and so its existence is orthogonal to the libraries.

willdean on 11 May 2017

👍2

The ASP.NET team should accept the burden of maintaining ASP.NET which, with all due respect, is not Angular at all. They should also consider the burden of speaking on behalf of Microsoft, while this might not be formally true, for sure it is unformally right and that also means that what the ASP.NET team does (or doesn't do) send shockwaves across the entire eco-system and directly or indirectly reflects priorities from Microsoft.

A quick example is support for AD: I don't know how on Earth this could be considered optional. Or better, I know since AD is for sure a relic from the pre-Internet era and that's something that will be phased out sooner or later but the fact is that if Microsoft/DNF doesn't even consider the effort of porting AD to its official ASP.NET Core framework (except for a vague promise that it will be added maybe before Summer...), the message is that technology is sidelined by Microsoft itself. Except that most Microsoft products require AD to work so how confident am I building a new virtualization cluster using AD while Microsoft thinks AD support is not so important ? That for sure is the wrong message to send unless you also add: from now on, stop adding AD to your infrastructure. That's what I meant when I said development in Microsoft is happening in a disconnected way.

The ASP.NET team learned in this thread that when they come up and state something, people hold emergency pre-crisis meetings, frantically look for information and think they made the wrong choice. That's what happens in real world because ASP.NET is a core technology (pun intended), not a simple library you could ignore if everything is working fine. So you want stability AND you also want improvements because that's how you work with core technologies.

Another silly example: popular IdentityServer4 stated that they will only support ASP.NET Core 1.1 so if anyone has a Core 1.0 application that they cannot convert what are they supposed to do ? Do you think it's fair to tell them that they should convert to avoid staying with old frameworks when their version is... what... 4 months old ? it's up to them ? Never. It's up to you to provide breaking changes only when actually unavoidable because the risk is to fragment the developers and, on a medium term, simply force people to switch.

Honestly, this backtracking doesn't fix anything. I knew that open sourcing .NET was the worst choice and mostly implied a disengagement by Microsoft. As someone before me said in this thread, .NET is basically a tool to support Azure now.

It's not that developers don't want to accept that change (or haters, like someone said like if we were schoolkids discussing about your hair color): they did but honestly Microsoft is not putting its weight behind this choice and using the change to pursue its business goals. We knew that supporting full .NET framework was possible and that was politics. And business remarks and comments here are way more important that technical ones because we can fix every technical problem. If this thread didn't teach you that the problem is not if we have UTF8 strings but people depending on these technologies for a living, honestly...

Is that too much responsibility for the ASP.NET team? Maybe. If so, let those decisions to a "super-team" that will take the responsibility for the whole eco-system and platform.

I don't even know how that could be discussed on GitHub.

tbprince on 11 May 2017

👍11 ❤6

@willdean ok lets put it in a different way "not in a diagram" :),

For example, if i build a library in .NET Standard 2.0 will this be supported in ASP.NET Core (.NET Core) (future wise) if so then it means "NET Standard -> .NET Core -> ASP.NET Core" if not then it means .NET Core is breaking away and will not utilise the base of NET Standard.

lilpug on 11 May 2017

@lilpug if a library is .NET Standard it can be used by anything in the layer above.

So a .NET Standard library can be used by .NET Framework, .NET Core, Xamarin, Mono, Unity etc as shown in the diagram.

.NET Standard is what libraries should ideally adhere to to allow maximum possible reach (and the lower the version the greater reach).

The layer above are app models; its what the exes/executables are. They are the final endpoints.

So you have a .NET Framework exe and it will only run on Windows.

A Xamarin executable; will run on iOS, Android, OSX (though you will need 3 different executables on for each).

A .NET Core exe can be fully portable and run with the dotnet launcher donet my.dll or create specically targeted executables for a specific platform Windows, Linux, MacOS, Tizen and only run on those; and you can output a targeted executable (self contained) for all of the specific platform from the same code; if you want to do that.

For example, if i build a library in .NET Standard 2.0 will this be supported in ASP.NET Core (.NET Core)

Yes; and that was always the case. Even if the ASP.NET Core libraries did specifically target .NET Core so they could only be used on .NET Core; you could still use .NET Standard libraries in ASP.NET Core. That was never effected by anything raised in this issue.

benaadams on 11 May 2017

👍10

@benaadams thank you so much for this that makes a lot more sense.

With the future end result being dropping support for the .NET full framework in ASP.NET Core whether it be in the next release or future releases i wanted to know for future libraries if we start building them "if possible" on the .NET Standard rather than .NET Framework 4.6+ and if this would help future proof us more for using ASP.NET Core as well as making it more compatible for other layers.

lilpug on 11 May 2017

The talk is tomorrow, so we have to wait and see.

https://channel9.msdn.com/Events/Build/2017/C9L18

adrianlmm on 11 May 2017

@lilpug

ok lets put it in a different way "not in a diagram" :),

For example, if i build a library in .NET Standard 2.0 will this be supported in ASP.NET Core (.NET Core) if so then it means "NET Standard -> .NET Core -> ASP.NET Core" if not then it means .NET Core is breaking away and will not utilise the base of NET Standard.

See .NET standard as an interface, which is implemented by 2 classes, one in .NET core and one in .NET full. Other implementations exist too, e.g. in xamarin and UWP. It's not a physical interface, it's a metaphor here, mind you. Now, if you write code which targets that _interface_ you can, at runtime, work with the implementation of that interface, be it a class in .net core or in .net full.

So with netstandard2.0 an API interface has been defined which has implementations in various platforms, e.g. .net core, .net full, xamarin, uwp. So you can then write a library which is compatible with netstandard2.0, which means it only uses APIs which are in that standard API definition and this thus means the library will run on all platforms which have an implementation of that interface.

ASP.NET core 2.0 being compatible with netstandard2.0 means that they will utilize only APIs in the netstandard2.0 so that means ASP.NET core 2.0 will run on all platforms which have an implementation of netstandard2.0.

(edit) drats, @benaadams beat me to it.

FransBouma on 11 May 2017

👍4

@lilpug if you make .NET Standard libraries and only use .NET Standard libraries all is well and you are future proofed.

The concern being raised was by people who are using libraries which, at this time, are not .NET Standard compatible; so these libraries cannot run on .NET Core 2.0

With ASP.NET Core libraries being made .NET Core 2.0 libraries it meant they couldn't run on Full Framework (though they could still use .NET Standard libraries).

benaadams on 11 May 2017

👍1

i appreciate the feedback everyone, my main concern was that the first thread of this started with:-

Earlier today, most of the ASP.NET Core 2.0 packages were updated to target netcoreapp2.0 instead of netstandard1.* and net4*

which made me worry that we were not only talking about dropping .NET Full Framework but also the base layer of .NET Standard as well.

thanks for clearing this up for me i appreciate it 👍

lilpug on 11 May 2017

For a post-mortem, there's something I'm seriously interested in clarifying:

As the team was working through the last of their issues before Build, it was uncovered that the preview of ASP.NET Core 2.0 utilized API's that were outside of .NET Standard 2.0, preventing it from running on .NET Framework.

When you're targeting netstandard1.3 and net46, like Kestrel (other packages have similar targets). How do you end up "utilizing APIs that are outside of .NET Standard 2.0"?

AFAIK, netstandard2.0 is a superset of both netstandard1.3 _and_ net46, so I'm struggling to see how you could end up in a situation where you use APIs preventing you from running on .NET Framework. How would that project even compile? OK, maybe you use a separate package with some additional APIs, but in order to even reference such a package, it needs to support all target frameworks.

Surely there must be something about bait-n-switching and reference assemblies etc. I'm not getting here, or is the comment in the blog post just a way of pretending this was never a thing? 😕

Also, why was there even a need to rush this change just before the preview? Is .NET Framework not a part of the test matrix?

khellang on 11 May 2017

👍6

@adrianlmm Thanks buddy.

This should end comments for whether will support it or not which cause more confusion. As you said lets wait for the event

And please let it be the last comment here so anybody who sees this thread for first time dont have to read all this long thread, but instead view the link to the event.

pantonis on 11 May 2017

@pantonis

https://www.youtube.com/watch?v=xz6OGVCdov8

jbogard on 11 May 2017

😄3

@khellang

Maybe @benaadams knows.
I'm pretty sure he had some pull requests (possibly already merged?) containing stuff that does not work outside core.

hallatore on 11 May 2017

@khellang The PRs that prompted this issue and the statement in the blog post are just plain inconsistent.

If the facts actually were as described in the blog post (last minute realisation, temporary change), then why would a load of #if NET46 code have been removed as part of this change?

willdean on 11 May 2017

😕1 👍1

why would a load of #if NET46 code have been removed as part of this change?

@willdean Yeah, that's a good point. If you just change the target frameworks, the implicit defines would just be gone and so would the code (from the compiled binaries) ¯\_(ツ)_/¯

khellang on 11 May 2017

For those looking for something official official in the meantime, it seems @migueldeicaza confirmed w/ the Register that ASP.NET Core 2 on .Net Standard 2 (and therefore NetFx) is the official plan: https://www.theregister.co.uk/2017/05/11/microsoft_backtracks_we_are_going_to_support_net_framework_with_aspnet_core_20/

RichiCoder1 on 11 May 2017

👍16 😄1

What about the compromises involved in maintaining compatibility with .NET Framework, will that hold back ASP.NET Core or impair its performance?

The answer, says de Icaza, is to use conditional code to “innovate and pursue performance. There is a spectrum of things you can do while still targeting the common denominator. You can always light up new things.” It is similar to how, on a PC, applications can support the latest CPU or GPU innovations while still running on old hardware. “If the CPU has new capabilities let’s use them, otherwise fall back to old code.”

stefan2410 on 11 May 2017

To clarify my earlier comment, since it seems to have been lost, I mentioned Angular 2 only because the comment before mentioned Angular 2, not because I thought it was a great analogy.

That said, it is pertinent to this discussion that the Angular team took what they had learned from building AngularJS, and applied it to the new technology that was available to them in the form of ES2016 and TypeScript, and broke with the old, slow, clunky, CPU-intensive code to build something _new_ that is exponentially better for building rich browser and mobile experiences. They took the hit, and Angular is better for it.

The full .NET framework is not the best thing to be building web applications on top of. It never will be. It just doesn't fit in a cloud-native, high-performance, cost-sensitive, distributed services world. That's the world that .NET Core is built for, and it's ever-changing. ASP.NET Core has dropped from 10th to 15th place on TechEmpower Round 14 because new things have come along in the last few months. No, benchmarks aren't everything, but they _are_ a thing, and being competitive is important.

So please, everyone, use this stay of execution wisely. If .NET Core 2.0, NetStandard2, and the increased compatibility with existing .NET packages (and hopefully the release of more actual netstandard packages) means that you can get off full .NET and onto Core, then do it. But if your millions of lines of legacy code mean that it's still not an option, then maybe that's God telling you to just stay on ASP.NET 4.7.

markrendle on 11 May 2017

👎12 👍4

@tbprince

If this thread didn't teach you that the problem is not if we have UTF8 strings but people depending on these technologies for a living, honestly...

Thanks for your insightful post. Especially the line above is IMHO very insightful.

FransBouma on 11 May 2017

👍1

@willdean there could be the expectation that stuff will be in an appropriate netstandard2x platform when Asp.Net Core targets it.

bbarry on 11 May 2017

@FransBouma

looks a bit ironic. I accept that. But I was tremendously serious.

tbprince on 11 May 2017

❤1

@stefanolson @alexwiese @yaakov-h As a aside XAML Standard 1.0 was just announced at Build https://github.com/microsoft/xaml-standard

benaadams on 11 May 2017

👍1

@markrendle love you Mark, but you're missing the big picture here. The TechEmpower benchmarks are trivial in the grand scheme of things, and I say that as someone who spends a significant portion of his day job performance-optimizing NETFX code. The ASP.NET Core team might care about them as a means of comparing their progress against that of other competing technologies and it might impact attracting net new people to .NET Core away from other platforms like Node.JS, but to the developers responsible for creating hundreds of billions of dollars in accumulated business value that currently runs on IIS and Windows it's just a nice feature, not the holy grail.

Besides, .NET is already cloud-native, whatever that means - I've run large scale distributed applications on it (100s of millions of requests per day) and I didn't need Docker or Linux to do it. There are others on this thread who've done even larger scale than that I suspect. Doesn't mean that we don't want what .NET Core offers in terms of better performance (edit: and better deployment experience,) but it does mean that there's nothing technically stopping us from hitting that scale today.

Try telling the ASP.NET / NETFX developers who build finance applications that move hundreds of millions of dollars a day, healthcare applications that deliver treatment to patients, services that manage energy production and consumption, and real-time safety monitoring for transportation systems all over the world to throw away their "legacy" code and start over. These developers are the reason why the ASP.NET team is employed in the first place - they buy the MSDN licenses, the big Azure enterprise agreements, the giant Office subscriptions, and the large SQL Server deployments that fund the creation, development, and maintenance of these tools to begin with.

What these folks are saying on the thread is "in no way, shape, or form could I sell a change of this magnitude to my management for so little benefit." Having a 10x improvement in request-per-second throughput is not a good tradeoff compared to the suspension of business activity it would require to replatform so abruptly, especially with the gaps in the two technologies being what they are today. @NickCraver did a good job of spelling that issue out in detail for SO on this thread. Platform migration, to be economical, must be done in parallel with going concerns of the business. These developers are not Luddites or idiots; they're constrained by the reality of the businesses that pay their salary and customers who use their software won't tolerate them taking months or years off to replatform their software without tremendous upside for said business and customers.

There's clearly a divide between two camps of people here: folks who want a greenfield future not constrained by .NET's past and folks who would like to be able to have that, but recognize that it's not economically feasible for them right now. The latter group already won the argument, and rightfully so, because they're the users who make up the biggest consumers of the .NET platform. The folks who are independent operators who can afford to adopt new technologies quickly are going to be stuck in the same boat as us, but that's the price they pay in exchange for free editions of Visual Studio, Code, great OSS tools from MSFT, et al.

That the enterprise / NETFX users bow to some sort of technical purity in the name of better benchmarks is an infeasible demand to make. Better for MSFT to do the brave thing and make NETFX better in parallel with NET Core, because that's what the customers are demanding in this thread.

.NET is a big tent and I admire the effort Microsoft is making to make it bigger with .NET Core and .NET Standard, and that effort should be lauded and supported by the community. But that being said, to disregard the 15+ years of adoption on NETFX (and its users) as some sort of inconvenient legacy that should be abandoned and forgotten post-haste is tone-deaf at best. Better to work with those developers to offer a clean, gradual migration path if the destiny is to eventually have the two platforms diverge. Maybe it would have been best if ASP.NET Core / .NET Core were branded as something entirely different with no relationship to .NET, but that bell can't be unrung and there's no going back now. So in the meantime, let's support Microsoft and hold them accountable too.

Aaronontheweb on 11 May 2017

👍42 ❤21

@markrendle

The full .NET framework is not the best thing to be building web applications on top of. It never will be. It just doesn't fit in a cloud-native, high-performance, cost-sensitive, distributed services world. That's the world that .NET Core is built for, and it's ever-changing. ASP.NET Core has dropped from 10th to 15th place on TechEmpower Round 14 because new things have come along in the last few months. No, benchmarks aren't everything, but they are a thing, and being competitive is important.

So please, everyone, use this stay of execution wisely. If .NET Core 2.0, NetStandard2, and the increased compatibility with existing .NET packages (and hopefully the release of more actual netstandard packages) means that you can get off full .NET and onto Core, then do it. But if your millions of lines of legacy code mean that it's still not an option, then maybe that's God telling you to just stay on ASP.NET 4.7.

Please try to refrain from being insensitive and instructing others where they should dedicate their future efforts, you have no idea how much time, effort, dedication and livelihoods there's at stake, everyone knows their own use-cases better than you and where they should dedicate their future efforts and will make their own informed decisions based on their own individual use-cases when the roadmaps becomes clearer.

An official spokesperson for the ASP.NET team will make their own official announcements and commitments when they're good and ready, everyone can decide for themselves what they should do after we have a clearer picture of what the future direction of their chosen platform looks like.

You've been poisoned looking at a single benchmark and think it's some kind of justification for destroying trust, creating uncertainty, abandoning most of your existing user base and 15 years of sensible language and platform evolution. It may take longer, it may require a different architecture but performance can still be achieved whilst maintaining compatibility. Maximum performance whilst sacrificing all else isn't everything, most of the fastest frameworks are unknown and the top three frameworks are written in C/C++, if you want the fastest performance possible go build your empire on C/C++ - .NET Core will never reach the top spot. Kestrel is still recommended to be run behind a reverse proxy which is going to overshadow any marginal micro improvements regardless, so the main thing that's at stake is getting to bragging rights sooner. We all want faster performance, but we all want to create value and deliver solutions - platforms are an enabler, like most framework's they're a means to an end, to facilitate creating multiplicative value-added solutions of which vastly overshadows the value in the platform itself.

The best path forward is to accept whatever plan the ASP.NET team has in store for us and do our own bit to help move the platform forward, harboring on about what might have been doesn't do anyone any good.

mythz on 11 May 2017

👍16 😕1

I have a lot of concerns about this, especially as my application is reliant on Active Directory. I don't know if there currently is or ever will be a .NET Core solution for Active Directory access.

Cowlephant on 11 May 2017

@twilliamsgsnetx Active Directory is coming. There are some good posts in the first 100 comments further up.

hallatore on 11 May 2017

@hallatore Yeah I was just reading Scott's post. Good stuff... wouldn't make much sense for Microsoft to pursue something that doesn't offer a solution to a Microsoft product. Heh.

Thanks! :+1:

Cowlephant on 11 May 2017

@hallatore Do you know if Active Directory support is available in the recently released Preview? Or is it still slated for sometime in the summer? I've got a greenfield project that requires AD integration and I'd really like to use Core.

adam3039 on 11 May 2017

@adam3039, you can use AD currently with Core 1.x if you're sitting on top of the .NET Framework. The System.DirectoryServices seems to be coming later on maybe in the next .NET Core 2.x preview?

snickler on 11 May 2017

@snickler Thank you for the clarification! I only saw Azure AD authentication options when creating a new Core application on top of .NET Framework. I'll investigate further!

adam3039 on 11 May 2017

The point with the benchmarks is not the raw speed, it's the ability to deliver much better performance and scalability on the same hardware. That translates into delivering equivalent-to-current performance using much less hardware, which relates directly to delivering business value. It means you can run your systems on one tenth of your current hardware setup or cloud commitment. On top of that, because .NET Core supports modern patterns and practices, developers can work more effectively, iterate and innovate faster, push ahead delivering more and better solutions for their businesses.

I also strongly believe that for most of the systems that are at issue here, a properly-planned migration to a solid, robust service-oriented or microservice architecture, one chunk of monolith at a time, should be encouraged. It's great that there's a path to do that where you can pretty much just copy and paste some files or lines of code into new projects. You used to have to rewrite everything from COBOL to 4GL or whatever, which is why there's still so much COBOL running the world.

And if the worst case scenario is that you really are stuck on full fat Windows ASP.NET and IIS, that's far from the worst thing that could happen. You're still going to get all the cool C# stuff that's coming, and these things that go into .NET Core will get to you eventually, it'll just take a bit longer.

markrendle on 11 May 2017

👍2

@mythz I'm pretty sure what I was suggesting people should do was exactly what you said they should do.

markrendle on 11 May 2017

@markrendle

The point with the benchmarks is not the raw speed, it's the ability to deliver much better performance and scalability on the same hardware. That translates into delivering equivalent-to-current performance using much less hardware, which relates directly to delivering business value. It means you can run your systems on one tenth of your current hardware setup or cloud commitment. On top of that, because .NET Core supports modern patterns and practices, developers can work more effectively, iterate and innovate faster, push ahead delivering more and better solutions for their businesses.

These are reasons for focusing on performance, which .NET Core already does and already delivers great performance, I'm not sure where you're pulling the 10x better utilization number from as that would put .NET Core 4.2x faster than the fastest C framework available and increasing the top-line numbers isn't going to make much of a difference as these numbers become marginalized as soon as they're made to serve real workloads. I agree delivering business value is important and cranking out faster performance numbers doesn't matter to organizations that can't migrate to .NET Core and .NET Core doesn't benefit from a smaller ecosystem, pool of knowledge, uncertainty, instability, poorer compatibility, etc.

The most valuable Internet properties were built with dynamic languages which aren't using the fastest frameworks, what matters more is a rich, vibrant, productive and stable ecosystem. For them scalability is more important than raw performance and even the slowest frameworks can be made fast with a good caching strategy, which is also more important than raw performance.

I also strongly believe that for most of the systems that are at issue here, a properly-planned migration to a solid, robust service-oriented or microservice architecture, one chunk of monolith at a time, should be encouraged.

So previously max performance is what's most important above all else and now the recommendation is to refactor working systems to introduce more network hops? Microservice architectures isn't fairy dust technology that can magically make all Systems in all use-case better, @NickCraver already covers why it doesn't make sense for StackOverflow, it doesn't make sense for Basecamp and many other prominent industry leaders also suggest going monolith first or that you can get more benefits with less trade-offs by modularizing your system. In makes more sense in greenfield projects as in most cases refactoring and rewriting working systems is a cardinal sin that's a poor use of resources that doesn't offer any Customer value.

@mythz I'm pretty sure what I was suggesting people should do was exactly what you said they should do.

It's not and you know it.

mythz on 12 May 2017

👍3

FYI .NET Standard 2.0 and .NET Core 2.0 was addressed live on https://channel9.msdn.com - starting at 11:54:00. There's also a direct link to the video.

Looks like all concerns have been officially alleviated:

Scott Hunter:

The plan is that we'll have ASP.NET Core 2.0 working on .NET Framework in preview 2

Github is not authoritative of what .NET is, the blogs (.NET blog or ASP.NET blog) are where the team will actually send a message to what we're doing with the tool, where we're going to move the tool and so on.

WinForms, WPF those are Windows features, .NET Core is meant to be a cross platform flavor of .NET and so we're not going to move Windows-only-isms into .NET Core... What I like to tell Customers .NET Framework is not going anywhere, we're going to support .NET Framework forever and so you should not feel compelled that you have to take all your old code and move it to .NET Core. The reasons to move to .NET Core are because you want cross-platform or you want to be fully side-by-side

.NET Core can move faster than .NET Framework because it's not a piece of Windows and it doesn't support side-by-side so the goal is not to say that everyone has to move their App completely off .NET Framework to .NET Core, if you're running WinForms or WPF or WCF those are great workloads to run on .NET Framework and we're going to support those things forever. Don't feel that you have to move, you should move because you want cross-platform or you want the full side-by-side.

mythz on 12 May 2017

👍10

They just answered this on the Channel 9 stream above:

ASP.NET Core 2.0 can both consume netstandard2.0 assemblies and run on any netstandard2.0-compliant platform.
ASP.NET Core 2.0 can run on the .NET Framework.

That sounds pretty definite, in spite of the above statements by other MS devs in this thread.

yaakov-h on 12 May 2017

👍17 🎉11 😄1

Great discussions everyone.

My 2 cents here is that ASP.NET Core is the biggest LIBRARY from Microsoft which promotes the use of .NET Core among developers.

Since they made a huge deal of creating .NET Standard to support compatibility, and usage of libraries throughout different flavors of .NET, they should just target NETSTANDARD2.0 in asp.net core so we can just use it everywhere, how cool is it to use it inside Xamarin app or WPF app to support embedded web server scenarios. That's why ASP.NET Core is so decoupled from the ground up (like hosting, servers etc) ..

The picture they are looking is that since .NET Core can run everywhere, there is no need to support other flavors of .NET, and just move on with the new rapidly changing stuff to support ASP.NET Core's future demanding API requirements and tie ASP.NET Core with .NET Core.

I don't know exactly what super advanced API they want in .NET Core to keep growing ASP.NET Core, but probably that's another story. The point is that, ASP.NET Core is just another LIBRARY and it must stay that way.

Full .NET Framework is still the mature one, battle tested. Lots of enterprise customers are using it (including myself) and wants to keep using ASP.NET Core on .NET Framework.

Thanks

joshua-mng on 12 May 2017

FYI .NET Standard 2.0 and .NET Core 2.0 was addressed live on https://channel9.msdn.com ... Looks like all concerns have been officially alleviated

Knowing that the politics inside MS are generally brutal I guess the rather dubious revisionism in the video is an effort to avoid publicly throwing the earlier contributors to this thread under the bus. I am never inclined to applaud corporate dishonesty but perhaps in this case it actually is for the greater good.

To borrow an earlier meme, "Onward, Oceania!"

willdean on 12 May 2017

@markrendle

And if the worst case scenario is that you really are stuck on full fat Windows ASP.NET and IIS, that's far from the worst thing that could happen. You're still going to get all the cool C# stuff that's coming, and these things that go into .NET Core will get to you eventually, it'll just take a bit longer.<

That's really one of the main points of this thread. Most of us would be quite satisfied if asp.net core can run on the .net framework even if it takes a six months to a year to catch up. But the impression that I have got is that the asp team want to completely separate and never come back to being able to run on .net framework. It is the lack of clarity on future plans that make it very difficult for those of us who are responsible to our clients for building long-term development and management plans.

stefanolson on 12 May 2017

👍4

@mythz Yes it was.

The best path forward is to accept whatever plan the ASP.NET team has in store for us and do our own bit to help move the platform forward

markrendle on 12 May 2017

@stefanolson You misunderstood me, I obviously wasn't clear enough. If for whatever reason ASP.NET Core running on .NET Core never gets to the point where it can run your code (e.g. the C++/CLI thing) and you can't rewrite your code or refactor your architecture, then stay on Classic ASP.NET MVC/WebAPI or WebForms.

(Incidentally, I notice we all finally moved on from the WebForms kerfuffle. Those guys are just getting on with it.)

markrendle on 12 May 2017

@markrendle that's obviously not what was being referred to

mythz on 12 May 2017

@markrendle WebForms to MVC was a completely different kettle of fish. All it was doing was changing the UI layer. I could still use the same backend code to do my document generation et cetera. So I had no problems with that at all. What is being discussed here is completely breaking compatibility with all of my code not just my UI code.. In actual fact the UI code is probably the most portable piece of it.

stefanolson on 12 May 2017

👍7

@stefanolson Maybe for you and your code the transition from WebForms to MVC was easy, but for a lot of people it was as insurmountable as full .NET to Core is now. And my point still stands: if you can't migrate your code to ASP.NET Core, then don't.

markrendle on 12 May 2017

👍2

@stefanolson @markrendle in the middle of a WebForms -> MVC5 transition right now, this was insurmountable to MVC/MVC2, less so in MVC5. We may be in a similar situation in that ASP .NET Core 3 or beyond may be an easier transition.

However, anyone who drank the WebForms coolaid HARD basically got screwed during the transition. We were saved because we didn't go HARD down the ViewState quagmire. I think what'll be important for the Framework -> Core transition is having a reliable, clear, documented plan for transition.

The uncertainty that has arisen around this is the problem, if it's a clear distinction that for the foreseeable future code written to the .NET Standard will be portable and not a wasted effort will help older projects begin the transition process by writing new code in .NET Standard and moving libraries to it.

If that goal is subject to change that's not great, and it means anything you do could be a nail in your project's coffin, or you'll get stuck on ~Python 2.x~ .NET Framework 4.x for a long time.

Reanmachine on 12 May 2017

Like any change in paradigm, people not using the right paradigm are going
to have a hard time.

I've warned so many people to not use HttpContext.Current... yet... it's
still being written today. Those apps are going to be hard to migrate since
they'll have tons of code depending on context values.

We had the same issue with the WebForms coolaid. Events, UpdatePanels,
etc... you could still use ASMX to do AJAX with jQuery. It was harder but
it was the "right" way to do it. Swapping from these kinds of apps were
easier when MVC came along.

The same thing is happening right now. The pattern is changing and what is
considered "good practice" has also evolved. All the code written in the
old way (against the grain) will have to be re-thought completely before
moving forward.

I don't think there's an easy transition plan other than knowing what is
"against the grain" and how to fix it. I'm not including non-ported APIs in
there of course. That's another issue altogether.

On Fri, May 12, 2017 at 3:29 PM Aren Blondahl notifications@github.com
wrote:

@stefanolson https://github.com/stefanolson @markrendle
https://github.com/markrendle in the middle of a WebForms -> MVC5
transition right now, this was insurmountable to MVC/MVC2, less so in MVC5.
We may be in a similar situation in that ASP .NET Core 3 or beyond may be
an easier transition.

However, anyone who drank the WebForms coolaid HARD basically got screwed
during the transition. We were saved because we didn't go HARD down the
ViewState quagmire. I think what'll be important for the Framework -> Core
transition is having a reliable, clear, documented plan for transition.

The uncertainty that has arisen around this is the problem, if it's a
clear distinction that for the foreseeable future code written to the .NET
Standard will be portable and not a wasted effort will help older projects
begin the transition process by writing new code in .NET Standard and
moving libraries to it.

If that goal is subject to change that's not great, and it means anything
you do could be a nail in your project's coffin, or you'll get stuck on Python
2.x .NET Framework 4.x for a long time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Home/issues/2022#issuecomment-301165679, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAMx6CoEdzs_Ys5a8W7Ri7lwfBqcIGUdks5r5LMIgaJpZM4NReOn
.

MaximRouiller on 12 May 2017

👍2 👎1

Wow, what a roller coaster journey this thread has been.

I'm relieved that microsoft is listening to the .net community on github
I'm amazed & delighted that this discussion, while passionate, has been almost completely professional
I think I finally grok what .net standard is supposed to mean (!!)

factormystic on 13 May 2017

🎉9

Edit: removed rant about stuff that actually isn't an issue. Finally read to the end of the post - video cleared up all worries.

poter134 on 14 May 2017

@poter134 Ehh. Did you read the thread? OK, I get it; it's long, but still... Everything's been resolved. It was a mishap. Next preview (and the final version) of ASP.NET Core will support .NET Standard, which again means .NET Framework.

@PinpointTownes Maybe you should close the issue and add a notice (at the top) that there's been a conclusion?

khellang on 14 May 2017

👍7

I'd even suggest locking & limiting to collaborators. I think everything has been said.

dasMulli on 14 May 2017

👍4

Apologies - Just got down to the video! that's a relief. Perhaps a summary at the top would be best for people like me that read 75% and despaired.

poter134 on 14 May 2017

👍1

Maybe link out to the Build video where they refer to this issue and clarify https://channel9.msdn.com/Events/Build/2017/C9L18

benaadams on 14 May 2017

@PinpointTownes Maybe you should close the issue and add a notice (at the top) that there's been a conclusion?

Done :+1:

kevinchalet on 14 May 2017

@PinpointTownes , we the community should also clean our communication on our side, and that is not easy. The rate at which issues, comments and so on are posted on GitHub is so high that it is hard for a smaller aspnet team to handle and keep track of everything. This asymmetry in number between us and the people behind .net core is well represented in the asp.net community standup, which is an almost exclusively unidirectional flow from them to us. Perhaps we could think of an inclusion of an extra layer between some community members and the .Net team where suggestions etc would be forwarded on skype meetings or standups. That would be hard to implement I assume but perhaps a direction to consider because the community is quite big.

Ponant on 14 May 2017

👍1

@ponant: that's the equivalent of what we had before, namely you report to some person and hope that person will pass it along. No, the community should be able to post their issues as-is and the team can then pick the ones they want to proceed with. If that is a lot of work, they (and not the community) should make sure they can handle it, e.g. by looking into using better tools than github issues (as it's not ideal: the set of questions how things work or why things don't work is mixed with the set of bug reports), add a layer for themselves which weed out the questions vs. the issues they have to work on. IMHO that's the most transparent as the community can see which issues are picked up and give feedback on other people's issues as well. If it is passed to a black box we have no control over it's IMHO a big step backwards.

FransBouma on 14 May 2017

👍4

Don't forget, you can also make PRs, contributions and bug fixes. Clearly know where to find the repos now 😉

benaadams on 14 May 2017

👍2 ❤1

@FransBouma , I agree with you as for transparency and I admit that adding a layer is generally a bad idea. But we need to understand the team if they get overwhelmed with info from the outside because we cannot dump info into GitHub and then complain if they take different directions. A better tool than GitHub would be welcomed and which would work in conjunction with it and more modern than the user voice.

Ponant on 14 May 2017

Why did you MS guys never learn the lessons? A break-everything-update will be killing the .NET Core's reputation and market, just like what happen in WP 7.x to 8.

The migration from ASP.NET 4 to ASP.NET Core is a hard and long-term painful progress, please do not make it even harder.

oldrev on 15 May 2017

👍2

they buy the MSDN licenses, the big Azure enterprise agreements, the giant Office subscriptions, and the large SQL Server deployments that fund the creation, development, and maintenance of these tools to begin with

So this is like the first-class passengers blocking improvements from being made in economy. OK.

markrendle on 15 May 2017

😄3 ❤1

@markrendle Microsoft is currently pulling in over two billion dollars a week in revenue. They can afford to do a better job managing their engineering projects.

For $400 million each workday I'd expect more than having the entire .NET team use the legendarily crappy NuGet to pull daily builds off an overloaded server in Belgium outsourced to a company named Tech Tomato. Which currently requires 200MB of metadata to install a 78k DLL. https://github.com/NuGet/Home/issues/4448

Perhaps it's the way Microsoft is choosing to use GitHub, but end-user communication is awful and communication between teams turns into a race to prematurely close bug reports and split issues before they gather enough community attention.

But if Microsoft is going to ignore the top UserVoice requests, and everything that doesn't seem fun to work on gets tagged as "backlog", what's the point of doing things in the open? Yeah, you're busy, we get that. You were busy before. Now you're busy, plus busy dealing with public community brigades, too.

Like any poorly-run 1990s web forum, stressed out admins react predictably. Comments mysteriously disappear from old threads. And senior management makes promises to tamp down the community outrage but does not deliver:

https://github.com/dotnet/cli/issues/5328
https://github.com/dotnet/corefx/issues/17522

Some Microsoft employees have embraced GitHub, many decided the time required just isn't manageable, others turned into GitHub addicts who do nothing useful but post polls and promote their Twitter accounts, asking "the community" how best to name a Factory method or providing rave reviews of Logitech mouse scroll wheels.

So I fix things by emailing internal contacts, just like I have since 1992. And the first reply inevitably mentions how this GitHub stuff is totally off the rails.

Edit for @PureKrome who didn't believe me about the mouse wheels.

Mouse Wheels is the new Mouse Balls

Incidentally when Hanselman showed up in this thread defending the decision I knew it would be reversed. If you want to know what Microsoft is doing, just read his blog then wait six months for the technology to go the exact opposite direction.

chadwackerman on 15 May 2017

👎10 😕6 👍6 🎉3 😄1

FYI: Some info on 2.0.0-preview2 and .NET Framework; https://github.com/aspnet/Announcements/issues/243

khellang on 16 May 2017

@chadwackerman I don't think they get to spend the whole two billion dollars on developing .NET, actually. Some of it probably goes on stupid-but-essential stuff like toilet paper, caffeinated beverages and Azure data-centers.

markrendle on 16 May 2017

😄4 👍2

@oldrev

Why did you MS guys never learn the lessons? A break-everything-update will be killing the .NET Core's reputation and market, just like what happen in WP 7.x to 8.

Maybe they did. Otherwise there would have been even more breaking changes.

The migration from ASP.NET 4 to ASP.NET Core is a hard and long-term painful progress, please do not make it even harder.

I totally agree the progress is hard, painful and going to take a while and I'm sure the MS folks are aware of that as well (whether they will make the progress easier is a different story)

Stepping back a little bit, my team did evaluate the possibility of switching from ASP.net to something else other than ASP.NET core but the decision is a no-brainer as we've so many dependencies on MS tech. At the end of the day, we've to accept the reality.

AlperenSarac on 17 May 2017

MS trying to repeat their own mistake and to drop support for the full .NET in Microsoft.Data.Sqlite repository https://github.com/aspnet/Microsoft.Data.Sqlite/pull/370

Without any discussions with the community and without any announces.

alexvaluyskiy on 18 May 2017

👎1

@alexvaluyskiy Not sure what you're on about. They're replacing net451 with netstandard2.0, so they're not dropping .NET support. netstandard2.0 is supported by .NET 4.6.1.

MartinJohns on 18 May 2017

👍5

@MartinJohns every change of TFS is a big breaking change, and I think it should be announced and discussed first.
.NET 4.5.2 is still supported by MS, and Microsoft.Data.Sqlite could be run on top of it. Why MS drops the support of it and forces users to update to net4.6.1 or netstandard2.0?

alexvaluyskiy on 18 May 2017

👍1

Because it's a reasonable expectation that you update your .NET version. This reduces maintenance cost, as they only have to support .NET Standard 2.0, and not multiple target runtimes. It's not that they're dropping .NET - they're still supporting it, but just a more recent version.

MartinJohns on 18 May 2017

👍5

Are you implying microsoft has to support all packages down to .NET 1.0?

Stuff has to converge to netstandard at some version

irwiss on 18 May 2017

@irwiss That comment is not really helpful. Nowhere did he imply that packages should be supported down to .NET 1.0. But he did mention "is still supported", which is right. .NET 4.5.2 is still an officially supported version as of 3rd May 2017 with no scheduled end of lifetime (https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework).

Supporting supported .NET versions is not a far fetched request.

MartinJohns on 18 May 2017

👍1

@MartinJohns Neither party is being terribly helpful to be honest - the initial link to the sqlite issue was based on a false premise, and trying to reshape the hole (into what would be a trivial 4.5.2 vs 4.6.1 debate) with a bit of extra digging wasn't a good idea.

willdean on 18 May 2017

👍2

I really don't know what is happening. Why do have many dotnet this and that. This is really crazy. How do we have keep tracks of this?

No proper documentation on migration from one to another.

smithaitufe on 13 Jun 2017

👎1

First we had DLL-hell, and we now have Package-hell...the more things change.... ;)

GiorgioG on 13 Jun 2017

👍1

Any way to lock this thread? This looks like it belongs in a chat format rather than a GitHub issue.

MaximRouiller on 13 Jun 2017

👍5

@MaximRouiller If only you know the hell I have been through since yesterday just to upgrade from netcoreapp1.1 to netcoreapp2.0.

If you know a link that can make it easier for me, please refer me to it.

Thanks

smithaitufe on 13 Jun 2017

👍1

@smithaitufe

https://weblog.west-wind.com/posts/2017/May/15/Upgrading-to-NET-Core-20-Preview

MaximRouiller on 13 Jun 2017

@smithaitufe That's kinda offtopic to this issue. Open a new issue instead.

Rutix on 13 Jun 2017

👍2

@PinpointTownes @Eilon

Any way to lock this thread? Everyone that comment something sends 100+ emails to notify of new activities while they may belong in a new thread.

MaximRouiller on 13 Jun 2017

👍2

@MaximRouiller I have gone through that and it didn't help.

For example, did you read this in that blog?

*
Overall this framework update provides a relatively smooth upgrade path aside from a few breaking changes.

But one thing that is extremely frustrating is the proliferation of SDKs, Runtimes, Tools and all the different versions that they incorporate. Especially when those things end up not quite lining up because they are all in different stages of preview.
*
I decided to create a new project just because I could not get it to work.

smithaitufe on 13 Jun 2017

@Rutix Thanks. I will figure a way out

smithaitufe on 13 Jun 2017

Per some of the discussion here, and given that this issue is fixed for the upcoming Preview 2 release, I'm locking this issue. For any additional questions about ASP.NET Core changes or issues, please file a new issue in the appropriate repo. If you're unsure where to file, please log an issue in the Home repo and tag me (@Eilon) and I'll help you find the right place.

Thanks!

Eilon on 14 Jun 2017

Aspnetcore: The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop

Most helpful comment

All 761 comments

NTLM/AD

System.Drawing

VSIX

Crypto

Oracle ADO.NET

WPF Interop

TL;DR;

Using ASP.NET to host a REST API for your application

Visual Studio support

*Remember, ASP.NET Core 2.0 running on .NET Core 2.0 doesn't need to _publish_ NETStandard packages to be able to _consume_ them.

Next steps

Preview 1 Issues

Preview 1 Issues

Related issues