10 ms·

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

124 points by ern 9y ago

pjmlp 9y ago
Better wait until they make their minds and keep on using .NET Framework, it seems. EDIT: Replaced .NET Desktop with .NET Framework, which is more accurate.
- jug 9y ago
  This is what we're doing. Using .NET Framework and not having to pay energy to following this the past three years has been truly liberating. It's an as powerful framework as ever, perfectly suitable for modern web development and whatnot. Yes, you miss out on cross platform support from .NET Core, but I feel like that hasn't even begun taking off yet and I'd argue that using e.g. Go or Python might make you a happier human being in that case anyway, or at least with a more peaceful, productive state of mind.
  - piaste 9y ago
    And if you need cross platform support, Mono is likely to be significantly less trouble than .NET Core 0.2, whoops I meant 2.0 sorry.
    - WorldMaker 9y ago
      A increasing amount of Mono is .NET Core. The wonders of open source is that you can do the effort once and share it. Eventually there will be no Mono, only .NET Core.
kierenj 9y ago
From the comments, the title seems misleading - the only issues are with System.Drawing and System.DirectoryServices. Am I misunderstanding?
- mythz 9y ago
  The issue is about Microsoft having just decided to drop support for being able to run ASP.NET Core 2.0 on the full .NET Framework. The current plan is to drop support for .NET v4.x after the current ASP.NET Core 1.x release: [1]: https://github.com/aspnet/Home/issues/2022#issuecomment-300043783 https://github.com/aspnet/Home/issues/2022#issuecomment-3000...
insulanian 9y ago
My God, is this ever going to settle down?! I skipped all the .NET Core 1.x fiasco and decided to wait for .NET Standard 2.0, as it seemed like they learned the lesson, but now it starts all over again.
- mrweasel 9y ago
  Yeah, as good as .Net is, they really need to work towards a: "Just download this and everything will work ".
  - bad_user 9y ago
    When an upgrade breaks the ecosystem without that breakage being discussed and announced along with future plans, then .Net is not very good, is it?
    - insulanian 9y ago
      I don't think this has anything to do with .NET being good or bad. The issue is completely orthogonal.
  - SideburnsOfDoom 9y ago
    > "Just download this and everything will work " Ah, the old debate in .Net between the lumpers and the splitters. Between the "just install .Net and that's it, it makes no sense to install all these little interdependent pieces one at a time. it's too complex and versioning is hell" and the "this web server doesn't need the WPF libraries, it's just dead weight, bloat, and makes it harder to start up new machines. It makes no sense to bring out a new version of WPF because there's a bug fix in ASP. Or worse, delay release." The thing is, there is no one right answer, only opposing forces that have to be reconciled. .Net core started out fairly radical, which favoured the early adopters and neophiles who tend towards splitters, but is now generally veering towards larger corporate adoption, which tends to wards lumpers. But there are exceptions.
    - RubyPinch 9y ago
deleted 9y ago
[deleted]
kodfodrasz 9y ago
This seems like FUD to me. (just skimmed the thread on mobile) First, this is about a preview version only. Second: Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. This version will be supported by desktop .Net 4.7 (win7+) when the standard is RTM. This will be the point where depending technologies will be RTMd as well. We should revisit this discussion then.
- mythz 9y ago
  > Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. Read the issue carefully, they've done the exact opposite and have started changing ASP.NET Core 2.0 packages from targeting .NET Standard to now only target .NET Core netcoreapp2.0 so they will no longer be able to be referenced from the full .NET Framework. They've also just announced that ASP.NET Core 1.x will be the last version that will be able to run on the Desktop CLR: [1]: https://github.com/aspnet/Home/issues/2022#issuecomment-300043783 https://github.com/aspnet/Home/issues/2022#issuecomment-3000...
  - flukus 9y ago
    Doesn't that make sense? Why would you want to run a core 2 app on the desktop CLR instead of distributing a binary? Not having suitable replacements for a lot of existing libraries is the bad part.
    - mythz 9y ago
      Read the issue thread, it lists several use-cases that require usage of the full .NET framework.
      - jug 9y ago
        Yes, I agree with the guy for example needing NHibernate. It's a pretty big deal in the ASP .NET world. Anyway, here's an issue tracker for that one: https://nhibernate.jira.com/browse/NH-3807 https://nhibernate.jira.com/browse/NH-3807 I also agree with the opinion that ASP .NET Core shouldn't have run on the full framework to begin with to set the right expectations. We seem to be in yet a transitionary period by Microsoft and if the point is to decouple it from .NET Framework, it shouldn't have had legs in it.
bad_user 9y ago
This reminds me of Rich Hickey's keynote called "Spec-ulation": https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s He's classifying changes in library as either: - (backwards compatible) growth - breakage He's also saying that "semantic versioning" is a recipe for breaking people's software and that if you're going to break things, then you should change the name / namespace. I agree with him.
- Chyzwar 9y ago
  Problem is not semantic version but .Net platform that have multiple branches of the same thing[0]. If MS was not braindead they would promote Mono to become .Net Core instead of building a new thing. Hickey's Clojure introduce breaking changes even in minor versions[1] how this is more sensible?. [0]https://docs.microsoft.com/en-us/dotnet/articles/standard/library https://docs.microsoft.com/en-us/dotnet/articles/standard/li... [1]https://github.com/clojure/clojure/blob/master/changes.md https://github.com/clojure/clojure/blob/master/changes.md
  - bad_user 9y ago
    Even though its history isn't perfect, Clojure's changes are not breaking and it's one of those projects that sets a high bar for what backwards compatibility means. Clojure code written for 1.0 (May 2009) works just fine in Clojure 1.8 and you'd find it challenging to find an item in that linked document that actually breaks compatibility.
- _pmf_ 9y ago
  It's an unfortunate side effect of the limited way some ecosystems handle multi-version dependencies; I would not blame this on semantic versioning (which clearly states which changes are to be considered breaking). With OSGi I can use one module that uses an older version and one module that uses a newer version and use these together in an application (as long as the dependencies are not exposed, which they unfortunately will be in almost all real-world code).
NicoJuicy 9y ago
This is what Scott Hanselman wrote, please read that first: == 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.
- mattmanser 9y ago
  Easier to read here: https://github.com/aspnet/Home/issues/2022#issuecomment-299536123 https://github.com/aspnet/Home/issues/2022#issuecomment-2995... How does the reassure you? To me that reads: Boys! We've been caught. Quick, do Jazz hands and pretend it doesn't matter! That does not seem like a sane response to me. We move fast and break things and that's good is not something we should be hearing as a justification at this point. And he's making a deal out of it being supported till 2018! A whole year! What do they think people are making on their framework? Apps that disappear after a year? Once you commit to a framework you'll be supporting it for 5 or 6 years. Am I totally misreading it, as to me that is really not a reassuring response at all, quite the opposite. It seems to me that they've completely lost touch with their customers who want a stable, fast and predictable new version of MVC 4.
jug 9y ago
I sometimes feel like I need a PhD to understand Microsoft's overarching .NET philosophy and how it all interoperates. It's strange, because the systems and what they are supposed to be able to do in terms of computing, human computer interfaces, and networking is largely unchanged since decades back. What is going on? Isn't the only major change recently that mobile devices have become more popular targets and web development is more useful due to web browsers being cross-platform renderers?
- DanielBMarkham 9y ago
  I hear you, and I feel this pain. I give up. I have better things to do.
  - windwake12 9y ago
    It's incredibly frustrating. I've been on the .NET wagon since ASP.NET 1.0 (and ASP before that), and my day to day friction with .NET has been increasing steadily over the last few years as more and more of the eco system starts to support "core". Looking over an example doc of how to host .NET in IIS (by far the most common approach) really shows how out of control it has become: https://docs.microsoft.com/en-us/aspnet/core/publishing/iis https://docs.microsoft.com/en-us/aspnet/core/publishing/iis It's a mess.
    - UK-AL 9y ago
      That's because it's IIS. Setting up apache is similarly difficult. There's nothing stopping you just using self hosted websites.
    - manigandham 9y ago
      Hosting in IIS with .NET Core is no different than before, it all works the same. Only difference is that IIS won't be running the code but just acting as a simple proxy so you turn off the "Managed Code" setting in the application pool for that site. Than just web-deploy like before and everything works. All those other settings are settings that were there before.
bhrgunatha 9y ago
I understand what .Net standard and .Net core are but I think they need a better strategy for their nomenclature that using .Net in the name of every runtime, platform and set of libraries.
noir_lord 9y ago
I was really hoping for F#/.net (core) on Linux to be a thing but at this point I'm so confused about the versioning it makes my head hurt. At least over in JVM land things are somewhat clearer.
- hurricaneSlider 9y ago
  I've played around with it. It works.
  - piaste 9y ago
    .NET Core is totally fine for playing around or for small apps and services. It's usually for large projects that these backwards compatibility issues tend to crop up and be show-stoppers. You're likely better off with Mono in that case.
    - hurricaneSlider 9y ago
      We've built our entire backend on .NET Core. We've got a lot of moving parts. The main pain points have ironically been certain Azure libraries which haven't been ported to the standard yet. I've also been using F# core and while the experience isn't yet there, it feels close.
- enricosada 9y ago
  See https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-1.0.1 https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for quickstart and info for F# on .NET Core. VSCode (with ionide), vim (vim-fsharp binding), emacs (fsharp-mode) already support it, with full intellisene. VSCode also support debugging. About the aspnet stack, same future limitation of C#, as discussed on the post. But there are also alternative web stack, like Suave.
  - noir_lord 9y ago
    Thanks, I'm aware of that as a resource. That isn't the issue, the issue is that when I play with things I restrict myself to playing with things that I can potentially use in production at some point, I don't have a lot of 'play time' so it makes sense to prioritise things that have a potential return.
deleted 9y ago
[deleted]
merb 9y ago
well I think a big minus in the ecosystem is that many projects (including something popular like NHibernate) actually pulled themselfs too much into the framework, they didn't created their own (which of course wasn't/isn't bad) but it tangled it, with a lot of implementation from microsoft (which microsoft now breaks). I always was very curious why that happened. I mean .NET has something like DataTable/DataReader, classes that were fully!!! implemented. In Java for SQL access you just gotten some interfaces and a Socket, the rest was up to you. (and somehow that worked, we have drivers for every major database in Java). Actually besides some java.io.InputStream/java.io.Reader there weren't such high level classes used/are used in these drivers. I mean since java8 we now have some nio classes that makes byte manipulation a lot of easier, but most stuff is still implemented by the driver and not any framework at all. (even ResultSet/Connection/DataSource is just an interface)
- pjmlp 9y ago
  Usually the culture on the .NET side of the fence tends to be more practical code oriented for quick solutions to daily use cases, than the enterprise solutions targeted to every possible use case one might eventually encounter. I love working on both sides, but sometimes we get into these kind of issues. On Java side I never liked that Sun engineers never grasped the expectations of what being a desktop developer actually means (AWT, Swing, Java 3D, JAI, JDI...). Which is an area, where Oracle actually managed to handle slightly better, but lets see.
  - UK-AL 9y ago
    I find that strange since some of the most popular "enterprise" patterns in use were made popular in .net. CQRS/EVENT SOURCING/DDD
    - pjmlp 9y ago
      I never used any of those, and I have been in the enterprise since the mid-90's. The only .NET enterprise pattern I can relate to is MVVM.
JohnBooty 9y ago
I moved away from the .NET world less than three years ago and this announcement might as well be written in Klingon or ancient Greek to me. Now, keep in mind that I actually thought (and still think?) that .NET and C# make for a very productive development environment. I didn't leave due to antipathy; no axe to grind here. But... "netcoreapp2.0"? "netstandard1"? "net4"? Huh? What? From Scott Hanselman's reply: .NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard. .NET Core? .NET Full? .NET Standard? .NETfx? And .NET Core is a superset of .NET Standard? How does that make sense? "Core" sounds like a stripped-down version of... something? But, apparently it's a superset. Because nothing makes sense any more. My only point here is: at first glance, this is an utterly bewildering set of choices. I'm sure there's a pretty simple relationship between all these things, but the .NET people probably aren't doing themselves any favors this these naming choices and (what appears to be) fragmentation between .NET development targets.
- giancarlostoro 9y ago
  I always loved .NET Framework, but I agree, some of the names are confusing and don't make entire sense later on. Like if I want to code ASP .NET Core in SublimeText 3 the plugin mentions ASP .NET vNext, which I'm honestly not sure if that was just code for ASP .NET Core or some abandoned version of .NET (the fact it's not even in your post...) and it's sad. The only one's I know currently are: * .NET Core - a new spin on .NET Framework for the cloud and such, not always compatible with .NET Framework but sometimes compatible. * .NET Framework (or "Full") - the .NET Framework we've known and loved, what was a few years ago merely known as .NET * .NET Standard - the bridge between the two, made after .NET Core so that they could break backwards compatibility to some extent, or they realized "whoops we gotta make a compatibility layer" or some other reason... I'm not even sure what .NETfx is, nor what ASP .NET vNext was, and if it was just an alpha, all I know is in Sublime Text I don't have sane / easy options. On Visual Studio Code I can just install the "C#" plugin on the other hand and get going. It's not as good as Visual Studio's IntelliSense though. One nice thing about .NET Core is the ability to develop from any platform and to deploy to any platform. .NET Framework needed Mono for that, I wonder how much of .NET Core will become Mono Core or something similar (if at all?).
kayoone 9y ago
I recently started a new project in .NET Core because i really like C# (mostly from working with Unity) but i am pretty sure that i won't use it again for some time. I naively believed i could now use the .NET ecosystem on a small microservice running on linux, but i quickly learned that support for .NET Core has to be actively built by maintainers of libs and the current choice isn't great, documentation is lacking and there is a lot of confusion like the issue linked to here or the whole project.json vs csproj debacle.
- m_fayer 9y ago
  I use NancyFX on the old .NET/Mono for that purpose and it works well. I keep hoping to switch to Core and it keeps not happening, but the old way seems to have a lot of life left in it.
j_s 9y ago
> 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 Microsoft, although demonstrably more open-source friendly, still moving the cheese.
mariusmg 9y ago
The first thing they need to change for .Net Core is the name. "Core" is such a meaningless term. Call it something like .Net Multiplatform or something.
sproketboy 9y ago
Why do people use .NET at all if they don't have to since Java is superior to .NET in every single conceivable way? Serious question.
styfle 9y ago
We wrote a .NET Core microservice a few months back and there were problems upgrading from 1.0 t 1.1 (or some minor point like that). I scraped it and rewrote it in node.js and now looking at this, I'm glad I did it. I just don't see .NET Core having any stability. Meanwhile, node just landed promises in core[0] a few minutes ago. [0]: https://news.ycombinator.com/item?id=14299623 https://news.ycombinator.com/item?id=14299623
manigandham 9y ago
.NET Standard - interface/API definition, not implementation, that specifies what functionality is supported at what version number. .NET Framework - older desktop/windows-only that implements the .NET Standard. Various other smaller frameworks created over the years for mobile, embedded, etc. .NET Core - newest cross-platform framework that implements the .NET Standard, although with less coverage than the full framework because it's new, but .NET Core 2.0 will have much more in parity and will eventually outpace. ASP.NET - web framework built on top of the .NET Framework that offers webforms, mvc, web api, razor views, etc related to making webapps. ASP.NET Core - web framework built on top of the .NET Core framework that offers a faster, streamlined pipeline/middleware model with mvc/web api, razor views, SPA services and integration, etc. Yes Microsoft is one of the worst companies at naming -- however it makes perfect sense that ASP.NET Core (the web framework) targets .NET Core (the underlying cross-platform framework) which itself implements .NET Standard. It's a case of superset functionality being layered on top. Eventually the .NET Core code will move faster and outpace .NET Framework, so you will be able to run .NET Framework libraries inside .NET Core apps but not run .NET Core apps inside .NET Framework.
- cptskippy 9y ago
  > Yes Microsoft is one of the worst companies at naming I think you're being too generous. Microsoft branded it's Office Suite, BA Suite and Operating system .NET once upon a time. They'd have named their own variety of orange juice OJ.NET if they'd had one. They are the worse company at naming.
  - manigandham 9y ago
    Every major company has naming problems from Google to Oracle to IBM and more. It's just teams, bureaucracy and marketing forces all fighting against each other. I do think Microsoft could just hire a VP of Naming who's in charge of all names and improve productivity by billions but alas, this is where we are today. However, once the names become familiar, the actual issues are not nearly as dire as made out to be.
  - kawsper 9y ago
iask 9y ago
I also find this extremely confusing, even after using .NET since 1.0. I wish they would make a chart, diagram...call it what you may, on MSDN or the Github repo, indicating all the frameworks, a description and what developers should target when using one e.g. Desktop, Web or API, Mobile, Cloud etc. That way, when comes the time to develop an app, we reference the chart and go from there.
- equasar 9y ago
  There's already one: - https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/ https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...
Sir_Cmpwn 9y ago
I actually quit using .NET entirely because Mono is a trainwreck while this stuff is being sorted. Half of the libraries I'm used to spewed esoteric errors about framework mismatching and such last time I tried. The new stuff from MS is difficult to use except on a few blessed Linux distros and Mono is slow on the uptake.
jamescostian 9y ago
I started using .NET for one, and only one reason: interop. Now that they're gutting interop, I want to jump ship, except there aren't any alternatives!
tekism 9y ago
They should allow the community to vote on naming these products, they have done a terrible job at it.
- svaha1728 9y ago
  My votes would be: Bloaty McBloatface - .NET Standard Fleabiscuit - .NET Core
dep_b 9y ago
As a .net Developer this also doesn't make much sense to me. I do know that I can keep firing up Visual Studio and keep working on my existing applications without this stuff hurting me. Also switching between .net versions will be fairly painless since they're all really similar. The only hard thing is understanding if you can port legacy app x to new stack y. Nothing that would stop me from using .net. Microsoft is really good to keep developers dangling. Can / should I still use WPF? Did it secretly continue under a different name?
- WorldMaker 9y ago
  This issue seems to mostly be (healthy) debate on that "can you port legacy app x to new stack y" front. It should (eventually) resolve to most people's satisfaction, but the sausage is being made in public on GitHub and that's new and frightening to some .NET veterans. «Can / should I still use WPF? Did it secretly continue under a different name?» You can still use WPF if you are happy with it. The Universal Windows Platform (UWP)'s .NET/XAML stack is the relatively open and acknowledged successor to WPF. It should be quite familiar to existing WPF developers and offers some nice new features and performance. Porting to UWP is still sometimes tough from WPF, but Project Centennial/the Desktop Bridge can make it a lot easier to do the transition a piece at a time.

124 points by ern 9y ago

Better wait until they make their minds and keep on using .NET Framework, it seems. EDIT: Replaced .NET Desktop with .NET Framework, which is more accurate.

jug 9y ago
This is what we're doing. Using .NET Framework and not having to pay energy to following this the past three years has been truly liberating. It's an as powerful framework as ever, perfectly suitable for modern web development and whatnot. Yes, you miss out on cross platform support from .NET Core, but I feel like that hasn't even begun taking off yet and I'd argue that using e.g. Go or Python might make you a happier human being in that case anyway, or at least with a more peaceful, productive state of mind.
- piaste 9y ago
  And if you need cross platform support, Mono is likely to be significantly less trouble than .NET Core 0.2, whoops I meant 2.0 sorry.
  - WorldMaker 9y ago
    A increasing amount of Mono is .NET Core. The wonders of open source is that you can do the effort once and share it. Eventually there will be no Mono, only .NET Core.

kierenj 9y ago

From the comments, the title seems misleading - the only issues are with System.Drawing and System.DirectoryServices. Am I misunderstanding?

mythz 9y ago
The issue is about Microsoft having just decided to drop support for being able to run ASP.NET Core 2.0 on the full .NET Framework. The current plan is to drop support for .NET v4.x after the current ASP.NET Core 1.x release: [1]: https://github.com/aspnet/Home/issues/2022#issuecomment-300043783 https://github.com/aspnet/Home/issues/2022#issuecomment-3000...

insulanian 9y ago

My God, is this ever going to settle down?! I skipped all the .NET Core 1.x fiasco and decided to wait for .NET Standard 2.0, as it seemed like they learned the lesson, but now it starts all over again.

mrweasel 9y ago
Yeah, as good as .Net is, they really need to work towards a: "Just download this and everything will work ".
- bad_user 9y ago
  When an upgrade breaks the ecosystem without that breakage being discussed and announced along with future plans, then .Net is not very good, is it?
  - insulanian 9y ago
    I don't think this has anything to do with .NET being good or bad. The issue is completely orthogonal.
- SideburnsOfDoom 9y ago
  > "Just download this and everything will work " Ah, the old debate in .Net between the lumpers and the splitters. Between the "just install .Net and that's it, it makes no sense to install all these little interdependent pieces one at a time. it's too complex and versioning is hell" and the "this web server doesn't need the WPF libraries, it's just dead weight, bloat, and makes it harder to start up new machines. It makes no sense to bring out a new version of WPF because there's a bug fix in ASP. Or worse, delay release." The thing is, there is no one right answer, only opposing forces that have to be reconciled. .Net core started out fairly radical, which favoured the early adopters and neophiles who tend towards splitters, but is now generally veering towards larger corporate adoption, which tends to wards lumpers. But there are exceptions.
  - RubyPinch 9y ago

deleted 9y ago

[deleted]

kodfodrasz 9y ago

This seems like FUD to me. (just skimmed the thread on mobile) First, this is about a preview version only. Second: Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. This version will be supported by desktop .Net 4.7 (win7+) when the standard is RTM. This will be the point where depending technologies will be RTMd as well. We should revisit this discussion then.

mythz 9y ago
> Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. Read the issue carefully, they've done the exact opposite and have started changing ASP.NET Core 2.0 packages from targeting .NET Standard to now only target .NET Core netcoreapp2.0 so they will no longer be able to be referenced from the full .NET Framework. They've also just announced that ASP.NET Core 1.x will be the last version that will be able to run on the Desktop CLR: [1]: https://github.com/aspnet/Home/issues/2022#issuecomment-300043783 https://github.com/aspnet/Home/issues/2022#issuecomment-3000...
- flukus 9y ago
  Doesn't that make sense? Why would you want to run a core 2 app on the desktop CLR instead of distributing a binary? Not having suitable replacements for a lot of existing libraries is the bad part.
  - mythz 9y ago
    Read the issue thread, it lists several use-cases that require usage of the full .NET framework.
    - jug 9y ago
      Yes, I agree with the guy for example needing NHibernate. It's a pretty big deal in the ASP .NET world. Anyway, here's an issue tracker for that one: https://nhibernate.jira.com/browse/NH-3807 https://nhibernate.jira.com/browse/NH-3807 I also agree with the opinion that ASP .NET Core shouldn't have run on the full framework to begin with to set the right expectations. We seem to be in yet a transitionary period by Microsoft and if the point is to decouple it from .NET Framework, it shouldn't have had legs in it.

bad_user 9y ago

This reminds me of Rich Hickey's keynote called "Spec-ulation": https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s He's classifying changes in library as either: - (backwards compatible) growth - breakage He's also saying that "semantic versioning" is a recipe for breaking people's software and that if you're going to break things, then you should change the name / namespace. I agree with him.

Chyzwar 9y ago
Problem is not semantic version but .Net platform that have multiple branches of the same thing[0]. If MS was not braindead they would promote Mono to become .Net Core instead of building a new thing. Hickey's Clojure introduce breaking changes even in minor versions[1] how this is more sensible?. [0]https://docs.microsoft.com/en-us/dotnet/articles/standard/library https://docs.microsoft.com/en-us/dotnet/articles/standard/li... [1]https://github.com/clojure/clojure/blob/master/changes.md https://github.com/clojure/clojure/blob/master/changes.md
- bad_user 9y ago
  Even though its history isn't perfect, Clojure's changes are not breaking and it's one of those projects that sets a high bar for what backwards compatibility means. Clojure code written for 1.0 (May 2009) works just fine in Clojure 1.8 and you'd find it challenging to find an item in that linked document that actually breaks compatibility.
_pmf_ 9y ago
It's an unfortunate side effect of the limited way some ecosystems handle multi-version dependencies; I would not blame this on semantic versioning (which clearly states which changes are to be considered breaking). With OSGi I can use one module that uses an older version and one module that uses a newer version and use these together in an application (as long as the dependencies are not exposed, which they unfortunately will be in almost all real-world code).

NicoJuicy 9y ago

This is what Scott Hanselman wrote, please read that first: == 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.

mattmanser 9y ago
Easier to read here: https://github.com/aspnet/Home/issues/2022#issuecomment-299536123 https://github.com/aspnet/Home/issues/2022#issuecomment-2995... How does the reassure you? To me that reads: Boys! We've been caught. Quick, do Jazz hands and pretend it doesn't matter! That does not seem like a sane response to me. We move fast and break things and that's good is not something we should be hearing as a justification at this point. And he's making a deal out of it being supported till 2018! A whole year! What do they think people are making on their framework? Apps that disappear after a year? Once you commit to a framework you'll be supporting it for 5 or 6 years. Am I totally misreading it, as to me that is really not a reassuring response at all, quite the opposite. It seems to me that they've completely lost touch with their customers who want a stable, fast and predictable new version of MVC 4.

jug 9y ago

I sometimes feel like I need a PhD to understand Microsoft's overarching .NET philosophy and how it all interoperates. It's strange, because the systems and what they are supposed to be able to do in terms of computing, human computer interfaces, and networking is largely unchanged since decades back. What is going on? Isn't the only major change recently that mobile devices have become more popular targets and web development is more useful due to web browsers being cross-platform renderers?

DanielBMarkham 9y ago
I hear you, and I feel this pain. I give up. I have better things to do.
- windwake12 9y ago
  It's incredibly frustrating. I've been on the .NET wagon since ASP.NET 1.0 (and ASP before that), and my day to day friction with .NET has been increasing steadily over the last few years as more and more of the eco system starts to support "core". Looking over an example doc of how to host .NET in IIS (by far the most common approach) really shows how out of control it has become: https://docs.microsoft.com/en-us/aspnet/core/publishing/iis https://docs.microsoft.com/en-us/aspnet/core/publishing/iis It's a mess.
  - UK-AL 9y ago
    That's because it's IIS. Setting up apache is similarly difficult. There's nothing stopping you just using self hosted websites.
  - manigandham 9y ago
    Hosting in IIS with .NET Core is no different than before, it all works the same. Only difference is that IIS won't be running the code but just acting as a simple proxy so you turn off the "Managed Code" setting in the application pool for that site. Than just web-deploy like before and everything works. All those other settings are settings that were there before.

bhrgunatha 9y ago

I understand what .Net standard and .Net core are but I think they need a better strategy for their nomenclature that using .Net in the name of every runtime, platform and set of libraries.

noir_lord 9y ago

I was really hoping for F#/.net (core) on Linux to be a thing but at this point I'm so confused about the versioning it makes my head hurt. At least over in JVM land things are somewhat clearer.

hurricaneSlider 9y ago
I've played around with it. It works.
- piaste 9y ago
  .NET Core is totally fine for playing around or for small apps and services. It's usually for large projects that these backwards compatibility issues tend to crop up and be show-stoppers. You're likely better off with Mono in that case.
  - hurricaneSlider 9y ago
    We've built our entire backend on .NET Core. We've got a lot of moving parts. The main pain points have ironically been certain Azure libraries which haven't been ported to the standard yet. I've also been using F# core and while the experience isn't yet there, it feels close.
enricosada 9y ago
See https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-1.0.1 https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for quickstart and info for F# on .NET Core. VSCode (with ionide), vim (vim-fsharp binding), emacs (fsharp-mode) already support it, with full intellisene. VSCode also support debugging. About the aspnet stack, same future limitation of C#, as discussed on the post. But there are also alternative web stack, like Suave.
- noir_lord 9y ago
  Thanks, I'm aware of that as a resource. That isn't the issue, the issue is that when I play with things I restrict myself to playing with things that I can potentially use in production at some point, I don't have a lot of 'play time' so it makes sense to prioritise things that have a potential return.

deleted 9y ago

[deleted]

merb 9y ago

well I think a big minus in the ecosystem is that many projects (including something popular like NHibernate) actually pulled themselfs too much into the framework, they didn't created their own (which of course wasn't/isn't bad) but it tangled it, with a lot of implementation from microsoft (which microsoft now breaks). I always was very curious why that happened. I mean .NET has something like DataTable/DataReader, classes that were fully!!! implemented. In Java for SQL access you just gotten some interfaces and a Socket, the rest was up to you. (and somehow that worked, we have drivers for every major database in Java). Actually besides some java.io.InputStream/java.io.Reader there weren't such high level classes used/are used in these drivers. I mean since java8 we now have some nio classes that makes byte manipulation a lot of easier, but most stuff is still implemented by the driver and not any framework at all. (even ResultSet/Connection/DataSource is just an interface)

pjmlp 9y ago
Usually the culture on the .NET side of the fence tends to be more practical code oriented for quick solutions to daily use cases, than the enterprise solutions targeted to every possible use case one might eventually encounter. I love working on both sides, but sometimes we get into these kind of issues. On Java side I never liked that Sun engineers never grasped the expectations of what being a desktop developer actually means (AWT, Swing, Java 3D, JAI, JDI...). Which is an area, where Oracle actually managed to handle slightly better, but lets see.
- UK-AL 9y ago
  I find that strange since some of the most popular "enterprise" patterns in use were made popular in .net. CQRS/EVENT SOURCING/DDD
  - pjmlp 9y ago
    I never used any of those, and I have been in the enterprise since the mid-90's. The only .NET enterprise pattern I can relate to is MVVM.

JohnBooty 9y ago

I moved away from the .NET world less than three years ago and this announcement might as well be written in Klingon or ancient Greek to me. Now, keep in mind that I actually thought (and still think?) that .NET and C# make for a very productive development environment. I didn't leave due to antipathy; no axe to grind here. But... "netcoreapp2.0"? "netstandard1"? "net4"? Huh? What? From Scott Hanselman's reply: .NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard. .NET Core? .NET Full? .NET Standard? .NETfx? And .NET Core is a superset of .NET Standard? How does that make sense? "Core" sounds like a stripped-down version of... something? But, apparently it's a superset. Because nothing makes sense any more. My only point here is: at first glance, this is an utterly bewildering set of choices. I'm sure there's a pretty simple relationship between all these things, but the .NET people probably aren't doing themselves any favors this these naming choices and (what appears to be) fragmentation between .NET development targets.

giancarlostoro 9y ago
I always loved .NET Framework, but I agree, some of the names are confusing and don't make entire sense later on. Like if I want to code ASP .NET Core in SublimeText 3 the plugin mentions ASP .NET vNext, which I'm honestly not sure if that was just code for ASP .NET Core or some abandoned version of .NET (the fact it's not even in your post...) and it's sad. The only one's I know currently are: * .NET Core - a new spin on .NET Framework for the cloud and such, not always compatible with .NET Framework but sometimes compatible. * .NET Framework (or "Full") - the .NET Framework we've known and loved, what was a few years ago merely known as .NET * .NET Standard - the bridge between the two, made after .NET Core so that they could break backwards compatibility to some extent, or they realized "whoops we gotta make a compatibility layer" or some other reason... I'm not even sure what .NETfx is, nor what ASP .NET vNext was, and if it was just an alpha, all I know is in Sublime Text I don't have sane / easy options. On Visual Studio Code I can just install the "C#" plugin on the other hand and get going. It's not as good as Visual Studio's IntelliSense though. One nice thing about .NET Core is the ability to develop from any platform and to deploy to any platform. .NET Framework needed Mono for that, I wonder how much of .NET Core will become Mono Core or something similar (if at all?).

kayoone 9y ago

I recently started a new project in .NET Core because i really like C# (mostly from working with Unity) but i am pretty sure that i won't use it again for some time. I naively believed i could now use the .NET ecosystem on a small microservice running on linux, but i quickly learned that support for .NET Core has to be actively built by maintainers of libs and the current choice isn't great, documentation is lacking and there is a lot of confusion like the issue linked to here or the whole project.json vs csproj debacle.

m_fayer 9y ago
I use NancyFX on the old .NET/Mono for that purpose and it works well. I keep hoping to switch to Core and it keeps not happening, but the old way seems to have a lot of life left in it.

j_s 9y ago

> 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 Microsoft, although demonstrably more open-source friendly, still moving the cheese.

mariusmg 9y ago

The first thing they need to change for .Net Core is the name. "Core" is such a meaningless term. Call it something like .Net Multiplatform or something.

sproketboy 9y ago

Why do people use .NET at all if they don't have to since Java is superior to .NET in every single conceivable way? Serious question.

styfle 9y ago

We wrote a .NET Core microservice a few months back and there were problems upgrading from 1.0 t 1.1 (or some minor point like that). I scraped it and rewrote it in node.js and now looking at this, I'm glad I did it. I just don't see .NET Core having any stability. Meanwhile, node just landed promises in core[0] a few minutes ago. [0]: https://news.ycombinator.com/item?id=14299623 https://news.ycombinator.com/item?id=14299623

manigandham 9y ago

.NET Standard - interface/API definition, not implementation, that specifies what functionality is supported at what version number. .NET Framework - older desktop/windows-only that implements the .NET Standard. Various other smaller frameworks created over the years for mobile, embedded, etc. .NET Core - newest cross-platform framework that implements the .NET Standard, although with less coverage than the full framework because it's new, but .NET Core 2.0 will have much more in parity and will eventually outpace. ASP.NET - web framework built on top of the .NET Framework that offers webforms, mvc, web api, razor views, etc related to making webapps. ASP.NET Core - web framework built on top of the .NET Core framework that offers a faster, streamlined pipeline/middleware model with mvc/web api, razor views, SPA services and integration, etc. Yes Microsoft is one of the worst companies at naming -- however it makes perfect sense that ASP.NET Core (the web framework) targets .NET Core (the underlying cross-platform framework) which itself implements .NET Standard. It's a case of superset functionality being layered on top. Eventually the .NET Core code will move faster and outpace .NET Framework, so you will be able to run .NET Framework libraries inside .NET Core apps but not run .NET Core apps inside .NET Framework.

cptskippy 9y ago
> Yes Microsoft is one of the worst companies at naming I think you're being too generous. Microsoft branded it's Office Suite, BA Suite and Operating system .NET once upon a time. They'd have named their own variety of orange juice OJ.NET if they'd had one. They are the worse company at naming.
- manigandham 9y ago
  Every major company has naming problems from Google to Oracle to IBM and more. It's just teams, bureaucracy and marketing forces all fighting against each other. I do think Microsoft could just hire a VP of Naming who's in charge of all names and improve productivity by billions but alas, this is where we are today. However, once the names become familiar, the actual issues are not nearly as dire as made out to be.
- kawsper 9y ago

iask 9y ago

I also find this extremely confusing, even after using .NET since 1.0. I wish they would make a chart, diagram...call it what you may, on MSDN or the Github repo, indicating all the frameworks, a description and what developers should target when using one e.g. Desktop, Web or API, Mobile, Cloud etc. That way, when comes the time to develop an app, we reference the chart and go from there.

equasar 9y ago
There's already one: - https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/ https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...

Sir_Cmpwn 9y ago

I actually quit using .NET entirely because Mono is a trainwreck while this stuff is being sorted. Half of the libraries I'm used to spewed esoteric errors about framework mismatching and such last time I tried. The new stuff from MS is difficult to use except on a few blessed Linux distros and Mono is slow on the uptake.

jamescostian 9y ago

I started using .NET for one, and only one reason: interop. Now that they're gutting interop, I want to jump ship, except there aren't any alternatives!

tekism 9y ago

They should allow the community to vote on naming these products, they have done a terrible job at it.

svaha1728 9y ago
My votes would be: Bloaty McBloatface - .NET Standard Fleabiscuit - .NET Core

dep_b 9y ago

As a .net Developer this also doesn't make much sense to me. I do know that I can keep firing up Visual Studio and keep working on my existing applications without this stuff hurting me. Also switching between .net versions will be fairly painless since they're all really similar. The only hard thing is understanding if you can port legacy app x to new stack y. Nothing that would stop me from using .net. Microsoft is really good to keep developers dangling. Can / should I still use WPF? Did it secretly continue under a different name?

WorldMaker 9y ago
This issue seems to mostly be (healthy) debate on that "can you port legacy app x to new stack y" front. It should (eventually) resolve to most people's satisfaction, but the sausage is being made in public on GitHub and that's new and frightening to some .NET veterans. «Can / should I still use WPF? Did it secretly continue under a different name?» You can still use WPF if you are happy with it. The Universal Windows Platform (UWP)'s .NET/XAML stack is the relatively open and acknowledged successor to WPF. It should be quite familiar to existing WPF developers and offers some nice new features and performance. Porting to UWP is still sometimes tough from WPF, but Project Centennial/the Desktop Bridge can make it a lot easier to do the transition a piece at a time.