New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
PinpointTownes opened this Issue May 5, 2017 · 761 comments

Comments

Projects
None yet
@PinpointTownes

PinpointTownes commented May 5, 2017

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 comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana May 5, 2017

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 commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ctolkien

ctolkien May 5, 2017

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 commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@MJomaa

MJomaa May 5, 2017

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 commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@aL3891

aL3891 May 5, 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 commented May 5, 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?

@gulbanana

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana May 5, 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

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

This comment has been minimized.

Show comment
Hide comment
@aL3891

aL3891 May 5, 2017

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 commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana May 5, 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..

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

This comment has been minimized.

Show comment
Hide comment
@nphmuller

nphmuller May 5, 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 commented May 5, 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+.

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 5, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@shanselman

shanselman May 5, 2017

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 commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mythz

mythz May 5, 2017

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 commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 5, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@daveaglick

daveaglick May 5, 2017

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 commented May 5, 2017

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.

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes May 5, 2017

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.

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.

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 5, 2017

Member

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

DamianEdwards commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes May 5, 2017

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

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

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 5, 2017

Member

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

Member

DamianEdwards commented May 5, 2017

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

@ap0llo

This comment has been minimized.

Show comment
Hide comment
@ap0llo

ap0llo May 5, 2017

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 commented May 5, 2017

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

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 5, 2017

Member

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

Member

DamianEdwards commented May 5, 2017

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

@daveaglick

This comment has been minimized.

Show comment
Hide comment
@daveaglick

daveaglick May 5, 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.

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

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 5, 2017

Member

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

Member

DamianEdwards commented May 5, 2017

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

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 5, 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.

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.

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes May 5, 2017

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

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

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 5, 2017

Member

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

Member

davidfowl commented May 5, 2017

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

@daveaglick daveaglick referenced this issue May 5, 2017

Open

Add support for .NET Core #300

44 of 47 tasks complete
@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 5, 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.

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

@khellang

This comment has been minimized.

Show comment
Hide comment
@khellang

khellang May 5, 2017

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 commented May 5, 2017

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

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 5, 2017

Member

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

Member

DamianEdwards commented May 5, 2017

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

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli May 5, 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 commented May 5, 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).

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock May 5, 2017

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?

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?

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 5, 2017

Member

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

Member

davidfowl commented May 5, 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.

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 5, 2017

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

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

@khellang

This comment has been minimized.

Show comment
Hide comment
@khellang

khellang May 5, 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 commented May 5, 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?

@jhurdlow

This comment has been minimized.

Show comment
Hide comment
@jhurdlow

jhurdlow May 5, 2017

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 commented May 5, 2017

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

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli May 5, 2017

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 commented May 5, 2017

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

@aL3891

This comment has been minimized.

Show comment
Hide comment
@aL3891

aL3891 May 5, 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 commented May 5, 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

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 5, 2017

Member

@khellang paging @terrajobst for the Portability Analyzer question.

Member

DamianEdwards commented May 5, 2017

@khellang paging @terrajobst for the Portability Analyzer question.

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst May 5, 2017

Member

@khellang

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

Member

terrajobst commented May 5, 2017

@khellang

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

@markrendle

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle May 12, 2017

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

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

@Reanmachine

This comment has been minimized.

Show comment
Hide comment
@Reanmachine

Reanmachine May 12, 2017

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

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

@MaximRouiller

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller May 12, 2017

@factormystic

This comment has been minimized.

Show comment
Hide comment
@factormystic

factormystic May 13, 2017

Wow, what a roller coaster journey this thread has been.

  1. I'm relieved that microsoft is listening to the .net community on github
  2. I'm amazed & delighted that this discussion, while passionate, has been almost completely professional
  3. I think I finally grok what .net standard is supposed to mean (!!)

Wow, what a roller coaster journey this thread has been.

  1. I'm relieved that microsoft is listening to the .net community on github
  2. I'm amazed & delighted that this discussion, while passionate, has been almost completely professional
  3. I think I finally grok what .net standard is supposed to mean (!!)
@poter134

This comment has been minimized.

Show comment
Hide comment
@poter134

poter134 May 13, 2017

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 commented May 13, 2017

Edit: removed rant about stuff that actually isn't an issue. Finally read to the end of the post - video cleared up all worries.

@khellang

This comment has been minimized.

Show comment
Hide comment
@khellang

khellang May 13, 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 commented May 13, 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?

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli May 13, 2017

I'd even suggest locking & limiting to collaborators. I think everything has been said.

I'd even suggest locking & limiting to collaborators. I think everything has been said.

@poter134

This comment has been minimized.

Show comment
Hide comment
@poter134

poter134 May 13, 2017

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.

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.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams May 13, 2017

Maybe link out to the Build video where they refer to this issue and clarify https://channel9.msdn.com/Events/Build/2017/C9L18

benaadams commented May 13, 2017

Maybe link out to the Build video where they refer to this issue and clarify https://channel9.msdn.com/Events/Build/2017/C9L18

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes May 14, 2017

@PinpointTownes Maybe you should close the issue and add a notice (at the top) that there's been a conclusion?

Done 👍

@PinpointTownes Maybe you should close the issue and add a notice (at the top) that there's been a conclusion?

Done 👍

@Ponant

This comment has been minimized.

Show comment
Hide comment
@Ponant

Ponant May 14, 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 commented May 14, 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.

@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma May 14, 2017

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

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

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams May 14, 2017

Don't forget, you can also make PRs, contributions and bug fixes. Clearly know where to find the repos now 😉

Don't forget, you can also make PRs, contributions and bug fixes. Clearly know where to find the repos now 😉

@Ponant

This comment has been minimized.

Show comment
Hide comment
@Ponant

Ponant May 14, 2017

@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 commented May 14, 2017

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

@oldrev

This comment has been minimized.

Show comment
Hide comment
@oldrev

oldrev May 15, 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 commented May 15, 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.

@markrendle

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle May 15, 2017

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.

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.

@khellang

This comment has been minimized.

Show comment
Hide comment
@khellang

khellang May 16, 2017

FYI: Some info on 2.0.0-preview2 and .NET Framework; aspnet/Announcements#243

FYI: Some info on 2.0.0-preview2 and .NET Framework; aspnet/Announcements#243

@markrendle

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle May 16, 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.

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

@AlperenSarac

This comment has been minimized.

Show comment
Hide comment
@AlperenSarac

AlperenSarac May 17, 2017

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

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

@alexvaluyskiy

This comment has been minimized.

Show comment
Hide comment
@alexvaluyskiy

alexvaluyskiy May 18, 2017

MS trying to repeat their own mistake and to drop support for the full .NET in Microsoft.Data.Sqlite repository aspnet/Microsoft.Data.Sqlite#370

Without any discussions with the community and without any announces.

alexvaluyskiy commented May 18, 2017

MS trying to repeat their own mistake and to drop support for the full .NET in Microsoft.Data.Sqlite repository aspnet/Microsoft.Data.Sqlite#370

Without any discussions with the community and without any announces.

@MartinJohns

This comment has been minimized.

Show comment
Hide comment
@MartinJohns

MartinJohns May 18, 2017

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

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

@alexvaluyskiy

This comment has been minimized.

Show comment
Hide comment
@alexvaluyskiy

alexvaluyskiy May 18, 2017

@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 commented May 18, 2017

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

@MartinJohns

This comment has been minimized.

Show comment
Hide comment
@MartinJohns

MartinJohns May 18, 2017

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.

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.

@irwiss

This comment has been minimized.

Show comment
Hide comment
@irwiss

irwiss May 18, 2017

Are you implying microsoft has to support all packages down to .NET 1.0?

Stuff has to converge to netstandard at some version

irwiss commented May 18, 2017

Are you implying microsoft has to support all packages down to .NET 1.0?

Stuff has to converge to netstandard at some version

@MartinJohns

This comment has been minimized.

Show comment
Hide comment
@MartinJohns

MartinJohns May 18, 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 commented May 18, 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.

@willdean

This comment has been minimized.

Show comment
Hide comment
@willdean

willdean May 18, 2017

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

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

@smithaitufe

This comment has been minimized.

Show comment
Hide comment
@smithaitufe

smithaitufe Jun 13, 2017

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.

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.

@GiorgioG

This comment has been minimized.

Show comment
Hide comment
@GiorgioG

GiorgioG Jun 13, 2017

First we had DLL-hell, and we now have Package-hell...the more things change.... ;)

First we had DLL-hell, and we now have Package-hell...the more things change.... ;)

@MaximRouiller

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller Jun 13, 2017

Any way to lock this thread? This looks like it belongs in a chat format rather than a GitHub issue.

Any way to lock this thread? This looks like it belongs in a chat format rather than a GitHub issue.

@smithaitufe

This comment has been minimized.

Show comment
Hide comment
@smithaitufe

smithaitufe Jun 13, 2017

@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 commented Jun 13, 2017

@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

@Rutix

This comment has been minimized.

Show comment
Hide comment
@Rutix

Rutix Jun 13, 2017

@smithaitufe That's kinda offtopic to this issue. Open a new issue instead.

Rutix commented Jun 13, 2017

@smithaitufe That's kinda offtopic to this issue. Open a new issue instead.

@MaximRouiller

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller Jun 13, 2017

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

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

@smithaitufe

This comment has been minimized.

Show comment
Hide comment
@smithaitufe

smithaitufe Jun 13, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@smithaitufe

smithaitufe Jun 13, 2017

@Rutix Thanks. I will figure a way out

@Rutix Thanks. I will figure a way out

@Eilon

This comment has been minimized.

Show comment
Hide comment
@Eilon

Eilon Jun 14, 2017

Member

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!

Member

Eilon commented Jun 14, 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!

@aspnet aspnet locked and limited conversation to collaborators Jun 14, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.