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

[kevinchalet]

Edit: the "no .NET Framework support for ASP.NET Core 2.0" plan has been officially cancelled and running ASP.NET Core 2.0 on .NET Desktop will be supported in the next previews. For more information, read Announcing ASP.NET Core 2.0.0-Preview1 and Updates for .NET Web Developers or watch .NET Standard 2.0 and .NET Core 2.0.

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 700 messages, woot!)

It's amazing to see such a great community in action, I'm so proud of being part of it 🤙

---

Original message: earlier today, most of the ASP.NET Core 2.0 packages were updated to target netcoreapp2.0 instead of netstandard1.* and net4* (e.g aspnet/Security#1203 and aspnet/Mvc#6234), making them totally incompatible with .NET Desktop and Mono.

Although this major breaking change is likely to have a huge impact on the entire ASP.NET ecosystem, it was neither discussed nor announced publicly (demonstrating once again that the ASP.NET team is not very good at communicating and is not really willing to discuss such important changes with its community, but that's another story).

In this thread, @Eilon partially mentioned the reasoning behind this decision, but didn't say whether less extreme options have been considered or not (e.g cross-compilation, introduction of a netstandard2.1 TFM, etc.):

Yes, for ASP.NET Core 2, most of the libraries will target .NET Core 2 in order to use new APIs that are not yet available in a .NET Standard TFM. Code that needs to target multiple platforms, such as Microsoft.Extensions.*, Entity Framework Core, and a few other libraries, will continue to use .NET Standard.

My question is simple: are you going to amend/revert these changes at some point before RTM, so people can use the ASP.NET Core 2.0 packages on .NET Desktop, or is ASP.NET Core 2.0 on .NET Desktop definitely dead? (which would be a major blocker for many people, including me).

Thanks.

[gulbanana]

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.

[ctolkien]

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?

[MJomaa]

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?

[aL3891]

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?

[gulbanana]

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

[aL3891]

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

[gulbanana]

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

[nphmuller]

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

[NickCraver]

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.

[shanselman]

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.

[mythz]

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?

[NickCraver]

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

[daveaglick]

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.