18 ms·

ASP.NET Core 3.0 will only run on .NET Core

178 points by polskibus 8y ago

pknopf 8y ago
Is this the beginning of python 2 vs 3?
- hurricaneSlider 8y ago
  I somehow doubt it, most of the APIs (with the notable exception of some of the reflection APIs) are at parity and the language is the same. This is more like a major library dropping support for a legacy runtime going forward.
  - svick 8y ago
    What reflection APIs are you talking about? Do you mean things like AppDomain and remoting?
    - hurricaneSlider 8y ago
      Yes, at least when I last checked, that stuff wasn't present.
    - caseymarquis 8y ago
      When porting some reflection heavy code to .net standard I encountered several breaking changes. They were all easily fixed by using GetTypeInfo(), which is where a lot of reflection functionality seems to have moved. I remember reading that it was for performance improvements.
      - davidfowl 8y ago
        What version of netstandard?
        caseymarquis 8y ago
        I just checked the project.json from that library and it appears to have been 1.6.0. It was a while back. Also, thanks for SignalR! It's a great library!
pingec 8y ago
Does this mean .NET framework is being dropped slowly for new projects? I am using asp.net core 2.1 for .net framework because it comes handy to load third party .net framework dlls inprocess. I do not have any power to convince third parties to move to .net core.
- SideburnsOfDoom 8y ago
  Slowly, but yes. This is already happening for ASP.NET on .NET Core 2.1. And .NET Core 3.0 will support some desktop cases.
- Lord_Zero 8y ago
  Most major libraries have been ported. What are you using?
  - pingec 8y ago
    Very niche, proprietary libraries
  - polskibus 8y ago
    Adomd lib for communicating with SQL Server Analysis Services (from MS) has not been ported. WCF is also absent from .net core which makes migrating to .net core much harder for existing projects.
    - sebazzz 8y ago
      I'm not sure (haven't tried it), but I believe there are few tricks where the assembly can be loaded on .NET Core _but_ the called APIs in the assembly must of course be present.
    - rblatz 8y ago
      WCF support is in Core, we use it extensively to communicate to legacy systems. It is missing some features, like WCF Relays. As for hosting WCF services on Core, we've been trying to distance ourselves from WCF in favor of other technologies.
password4321 8y ago
The v2.0 attempt's uproar: https://news.ycombinator.com/item?id=14297974 https://news.ycombinator.com/item?id=14297974
- svick 8y ago
  Note that one difference is that the 2.0 attempt was noticed by a user following commits to the repo. This time, they've made a public announcement about it.
cm2187 8y ago
So in other words Microsoft doesn't think .net standard is a practical approach to prevent the fragmentation of the .net ecosystem and won't use it themselves. Also it probably means blazor (which runs on mono) won't be able to share libraries with asp.net core...
- sebazzz 8y ago
  The core issue is that it is too hard to update the full .NET Framework without making breaking changes in this Operating System component. As actually mentioned by David Fowler, if there are missing API that are required in .NET Core, requests for them can be made. I cannot find the comment from @terrajobst in Github anymore but it states that it is simply not possible to port some of the breaking changes to the .NET framework (because they are breaking changes in the CLR, and maintaining a third CLR version (2.0, 4.0, vnext) is very hard because of a number of shared components used). edit: It appears some comments have been deleted, luckily we have still mail notifications from Github. > > Do what you promised: make .NET Framework a stable framework that evolves slower instead of a dead end for the ones who trusted you when migrating to ASP.NET Core. > That still makes the assumption that .NET Framework will eventually get all features .NET Core has, but with a time delay. We learned that's simply not realistic. We can either decide not to innovate drastically in .NET Core or accept the engineering reality that a good chunk of the new features will never make it back to .NET Framework. We believe that we serve our customers best to preserve .NET Framework's core value prop (a mature & rich development platform) while also allowing customers to exploit new capabilities on .NET Core. Moving forward, I'd expect that we'll be more willing to innovate in areas that require runtime, library, and language changes like we did for Span<T>. While these things are costly, they also allow us to change the way people can write code. A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk. And later on: > > What prevents you from introducing a new side-by-side .NET Framework version (let's say .NET Framework 5) that includes those "risky" changes? Again, it's not a technical issue. > What makes you think it's not a technical issue? Shipping side-by-side versions of .NET Framework isn't a workable solution. First of all, it's fairly expensive due to the fact that it's an OS component and thus needs to be serviced. You have no idea how complex our branching/servicing/patching strategy for .NET Framework 3.5 and 4.x is. Adding a 3rd one is close to impractical. Secondly, just doing that also has risks, as we need to make changes to activation in order so select the correct runtime for things like COM activated managed components. And that begs the question of whether or not we support in-proc side-by-side as well and with how many combinations. It's not a simple task and not free of risk either.
Nelkins 8y ago
Fine by me. The faster we can get everyone off of .NET Framework, the better.
- gameswithgo 8y ago
  Agreed. Having both around is a nightmare, I still can't believe they ever did it this way.
  - Nelkins 8y ago
    I completely understand why they did it, and it actually makes a lot of sense to me. I wish PCLs never happened and I wish .NET Standard happened a lot earlier (seriously, the idea of platform profiles vs a standard API is idiotic and completely unmaintainable). The other place MS has not executed well is versioning/naming and the communication of those versions/names. But soon(?) it'll all be .NET Core and we can put this behind us.
  - testvox 8y ago
    Its actually very nice, you can update your framework projects to 4.7 which can cross compile as dotnet core 2.1 then after you are comfortable with the dotnet core build you can drop framework.
    - dxetech 8y ago
      Any way you could provide more information about this? I have some legacy projects on 4.7 that I would love to migrate over to core 2.1
      - svick 8y ago
        If you're using .Net Core version of csproj, it's the difference between e.g. <TargetFramework>netcoreapp2.1</TargetFramework> and <TargetFrameworks>net47;netcoreapp2.0</TargetFrameworks>. I don't know if there's a good way to migrate the csprojs automatically (maybe https://github.com/hvanbakel/CsprojToVs2017? https://github.com/hvanbakel/CsprojToVs2017?), but it shouldn't be that hard manually (by creating a new project), assuming you have just a few projects to migrate.
tluyben2 8y ago
This is good news I think. The fragmentation is quite annoying and not needed I believe. We moved everything (15 years of code) to Core 2 and it was not a lot of work. I could not be happier; the experience for developers is so much nicer.
- nobody271 8y ago
  How is it nicer? It's a .NET shop but devs are free to use linux as their OS?
  - SolarNet 8y ago
    Also not tied to visual studio to build. `dotnet` is an node style command line tool.
    - lkitching 8y ago
      You haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.
      - hermitdev 8y ago
        You've never needed Visual Studio to build .Net projects. They have supported MSBuild from v1.0, you just needed to write the project files by hand - a very tedious process. It's just that building from Visual Studio is by far the most convenient method.
        pjmlp 8y ago
        MSBuild was introduced around .NET 2.0 after Ant's introduction in the Java world. Before there was a project format, callable with devenv command line tool.
      - rblatz 8y ago
        Speaking of the project files, the new csproj format is my favorite thing. We used to always get conflicts in them, and now we basically never do.
setquk 8y ago
Excellent. I look forward to all of our .Net Framework only 3rd party dependencies being unsupported and abandoned instantly because there's no way anyone is going to bother supporting two distinct platform versions. And also the humongous porting effort to move everything over if we want something that isn't half arsed and abandoned which is what happens in the long tail of any MSFT product cycle. When you phone partner support because something is broken and no one knows how to help you. Another "fuck you" from MSFT. Just like that whole opt-out telemetry crapfest. I want off this crazy train now. Anyone need a Python/C developer (where knowledge is valuable for more than a 3 year window)?
- mr_overalls 8y ago
  As a Python developer, are you actually surprised by breaking changes? The Python 2/3 split originated a decade ago, after all.
  - setquk 8y ago
    Python 3 was released a decade ago. Python 2 is still supported until 2020. 2to3 exists. Python actually give a shit about their users. What a lot of people seem to forget about .Net is that for those of us who have been around since day one, we've been burned over and over again by large product and framework deprecations over the years. This is one too many.
    - kyberias 8y ago
      > burned over and over again by large product and framework deprecations over the years. What large framework deprecations? I've been around and I don't feel burned at all.
      - setquk 8y ago
        WCF, WWF, UWP, AppFabric, EF incompatibility etc etc. Basically the entire enterprise stack. And I’m not even talking about the whole original .net and com stuff.
TimTheTinker 8y ago
Now that Microsoft no longer has a "Windows or Office" angle to everything they do, what is their angle here (i.e. how does a cross-platform .NET target contribute to their bottom line)? I know they generally want to grow (1) Azure, and (2) developer mindshare. I see how a cross-platform .NET Core contributes to Microsoft's developer mindshare, and perhaps how Azure could follow up by cornering the market on really great back-end .NET Core hosting and operations. Is there anything beyond that?
- cptskippy 8y ago
  There are libraries for .NET Core that play very very nicely with Azure. And there are parts of Azure that play very nicely with their Enterprise software like Active Directory. It's all circular.
- int_19h 8y ago
  Think about how many cross-platform products Microsoft itself is working on. And how many engineers it has that are already proficient in .NET and C#...
mariusmg 8y ago
This is bullshit actually. They should also come out publicly and announce if .NEt Framework 4.8 is the last version or not.
da_chicken 8y ago
I guess my thinking is that if ASP.NET Core 3.0 requires a different framework and there's no way to easy the transition through .NET Standard code, why should I consider ASP.NET Core 3.0 over any other framework? What makes moving to ASP.NET Core 3.0 appealing for an existing project is exactly .NET Standard. If that goes away, then what's the draw? The product line will need to have a version with a compatibility break no matter what. Why should we favor ASP.NET Core 3.0 over anything else, especially when the vendor just screwed us for picking their last product, ASP.NET? Why wouldn't the same thing happen again when Microsoft releases ASP.NET Core Futuro 1.0 in 2030?
ksec 8y ago
I wonder if Stackexchange has moved everything to .Net Core and Linux along with ASP.Net 3.0?
- jongalloway2 8y ago
  They've already started moving to .NET Core: https://twitter.com/nick_craver/status/1031858480888639488 https://twitter.com/nick_craver/status/1031858480888639488
garganzol 8y ago
Worst PR move Microsoft could ever take. Developers don't need another Python 2 vs 3 debacle. There should not be .NET Framework. There should not be .NET Core. There should be .NET, a singular powerful platform that does it all.
- Quarrelsome 8y ago
  I remember a confused developer looking at a brochure that said: "when to choose WinForm and when to choose WPF". His question was: > why do I have to choose?
- manigandham 8y ago
  "platform" is vague and doesn't describe much on its own. .NET is vast, and the runtimes are what actually run the code packages on various devices. .NET Framework has been the original Windows implementation and now we have a fast, lightweight and modern cross-platform implementation with .NET Core. It makes sense to consolidate on a single runtime that now works well on Windows and is at 99% parity with legacy features.
  - garganzol 8y ago
    .NET Core is not on par. It is seriously lacking in vision and attitude. It has some nice properties like portable deployment and that's basically it. The rest is just one to one copy from .NET Framework, plus a bit of quick and dirty additions here and there without a further thought. Please note how the latter statement signifies the endangered future state of the platform.
    - manigandham 8y ago
      "vision and attitude" is 100x more vague than platform. Care to actually explain what you think it should be then? .NET Core is cross-platform. That is a massive change that you seem to just ignore.
      - deleted 8y ago
        [deleted]
manigandham 8y ago
Makes perfect sense, and seems to have been general expectation of the community for a long time. No need to keep maintaining 2 runtimes when there is a modern, fast, lightweight version that is cross-platform and will now be beyond parity at the next release.
jimnotgym 8y ago
I feel like .NET Core has become a technology I should be considering for my team, not least because it is so much easier to find .NET devs in the UK than just about anything else (apart from php WordPress and Magento peeps). I feel I know nothing about it at all, and I wonder if anyone would be kind enough to suggest some resources? I'm primarily going to be working with enterprise CRUD apps, and ERP stuff. Out of interest, what are the options for cross platform desktop apps, if the Windows GUIs are going to remain closed source?
- avinium 8y ago
  > Out of interest, what are the options for cross platform desktop apps, if the Windows GUIs are going to remain closed source? .NET Core 3 will support WPF -https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/ https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...
  - blinkingled 8y ago
    No, it's not cross platform. WPF will be supported on .Net Core runninng on Windows platform only - previously you needed .NET framework to run WPF apps - given everything will be .NET Core going forward this move makes sense.
    - avinium 8y ago
      Oops, you’re right, didnt read my own link closely enough. I guess Avalonia is the only option for cross platform .NET UI? https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia
- jf- 8y ago
  There is no official cross platform desktop GUI solution for .NET core. There are third party efforts however, take a look at avalonia and eto.forms. Or alternatively think of doing a web app in ASP.NET core. If you don’t need a bells and whistles SPA then ASP.NET core MVC is a very performant solution.
akra 8y ago
A link on the original announcement page states "Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.". If this is right the high coupling between the CLR and what really is a framework/library on top astounds me and is somewhat worrying. I'm foreseeing future deployment horrors. One of the advantages of .NET is portable IL code across anything that can interpret it similar to Java. If this is broken and I can only use .NET/ASP.NET Core CLR with certain native system dependencies installed then this big advantage of the .NET platform IMO is gone and creates some surprising non-intuitive issues. You can see one example of this in the issue here: https://github.com/aspnet/AspNetCore/issues/3307 https://github.com/aspnet/AspNetCore/issues/3307. I install the package; then also need to install a system wide package using my package manager to back it? If I install the package I should be able to use it. It seems as if the GAC is back just for ASP.NET however? Unfortunately as I experienced recently installing the right asp net runtime doesn't necessarily fix the problem either; it just allows the app to start but then other run-time issues pop up. The only fix is self-containing the app - tough luck if your on a distro not supported. Maybe these are teething issues but the constant change between minor versions has been painful. ASP.NET is no longer just another Nuget library it seems - it's now been promoted to be part of the CLR and this decision is the logical extension of that.
sayali321 8y ago
Microsoft will make major updates to ASP.NET Core, including integration of projects and frameworks, tighter integration with .NET Core, and integration with third-party open source kits, these improvements will help developers complete development work faster The way the project is referenced and run on ASP.NET Core changes as the version’s iteration changes. In 1.0, ASP.NET Core itself is a “package” and appears in the project just like any other NuGet package reference. This has its advantages and disadvantages. Over time, this model has evolved. In 2.1, ASP.NET Core eventually evolved into a “shared framework” for .NET Core. To know more about.net core follow our Website: https://crbtech.in/programmes/dot-net-training-programme https://crbtech.in/programmes/dot-net-training-programme

178 points by polskibus 8y ago

pknopf 8y ago

Is this the beginning of python 2 vs 3?

hurricaneSlider 8y ago
I somehow doubt it, most of the APIs (with the notable exception of some of the reflection APIs) are at parity and the language is the same. This is more like a major library dropping support for a legacy runtime going forward.
- svick 8y ago
  What reflection APIs are you talking about? Do you mean things like AppDomain and remoting?
  - hurricaneSlider 8y ago
    Yes, at least when I last checked, that stuff wasn't present.
  - caseymarquis 8y ago
    When porting some reflection heavy code to .net standard I encountered several breaking changes. They were all easily fixed by using GetTypeInfo(), which is where a lot of reflection functionality seems to have moved. I remember reading that it was for performance improvements.
    - davidfowl 8y ago
      What version of netstandard?
      - caseymarquis 8y ago
        I just checked the project.json from that library and it appears to have been 1.6.0. It was a while back. Also, thanks for SignalR! It's a great library!

pingec 8y ago

Does this mean .NET framework is being dropped slowly for new projects? I am using asp.net core 2.1 for .net framework because it comes handy to load third party .net framework dlls inprocess. I do not have any power to convince third parties to move to .net core.

SideburnsOfDoom 8y ago
Slowly, but yes. This is already happening for ASP.NET on .NET Core 2.1. And .NET Core 3.0 will support some desktop cases.
Lord_Zero 8y ago
Most major libraries have been ported. What are you using?
- pingec 8y ago
  Very niche, proprietary libraries
- polskibus 8y ago
  Adomd lib for communicating with SQL Server Analysis Services (from MS) has not been ported. WCF is also absent from .net core which makes migrating to .net core much harder for existing projects.
  - sebazzz 8y ago
    I'm not sure (haven't tried it), but I believe there are few tricks where the assembly can be loaded on .NET Core _but_ the called APIs in the assembly must of course be present.
  - rblatz 8y ago
    WCF support is in Core, we use it extensively to communicate to legacy systems. It is missing some features, like WCF Relays. As for hosting WCF services on Core, we've been trying to distance ourselves from WCF in favor of other technologies.

password4321 8y ago

The v2.0 attempt's uproar: https://news.ycombinator.com/item?id=14297974 https://news.ycombinator.com/item?id=14297974

svick 8y ago
Note that one difference is that the 2.0 attempt was noticed by a user following commits to the repo. This time, they've made a public announcement about it.

cm2187 8y ago

So in other words Microsoft doesn't think .net standard is a practical approach to prevent the fragmentation of the .net ecosystem and won't use it themselves. Also it probably means blazor (which runs on mono) won't be able to share libraries with asp.net core...

sebazzz 8y ago
The core issue is that it is too hard to update the full .NET Framework without making breaking changes in this Operating System component. As actually mentioned by David Fowler, if there are missing API that are required in .NET Core, requests for them can be made. I cannot find the comment from @terrajobst in Github anymore but it states that it is simply not possible to port some of the breaking changes to the .NET framework (because they are breaking changes in the CLR, and maintaining a third CLR version (2.0, 4.0, vnext) is very hard because of a number of shared components used). edit: It appears some comments have been deleted, luckily we have still mail notifications from Github. > > Do what you promised: make .NET Framework a stable framework that evolves slower instead of a dead end for the ones who trusted you when migrating to ASP.NET Core. > That still makes the assumption that .NET Framework will eventually get all features .NET Core has, but with a time delay. We learned that's simply not realistic. We can either decide not to innovate drastically in .NET Core or accept the engineering reality that a good chunk of the new features will never make it back to .NET Framework. We believe that we serve our customers best to preserve .NET Framework's core value prop (a mature & rich development platform) while also allowing customers to exploit new capabilities on .NET Core. Moving forward, I'd expect that we'll be more willing to innovate in areas that require runtime, library, and language changes like we did for Span<T>. While these things are costly, they also allow us to change the way people can write code. A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk. And later on: > > What prevents you from introducing a new side-by-side .NET Framework version (let's say .NET Framework 5) that includes those "risky" changes? Again, it's not a technical issue. > What makes you think it's not a technical issue? Shipping side-by-side versions of .NET Framework isn't a workable solution. First of all, it's fairly expensive due to the fact that it's an OS component and thus needs to be serviced. You have no idea how complex our branching/servicing/patching strategy for .NET Framework 3.5 and 4.x is. Adding a 3rd one is close to impractical. Secondly, just doing that also has risks, as we need to make changes to activation in order so select the correct runtime for things like COM activated managed components. And that begs the question of whether or not we support in-proc side-by-side as well and with how many combinations. It's not a simple task and not free of risk either.

Nelkins 8y ago

Fine by me. The faster we can get everyone off of .NET Framework, the better.

gameswithgo 8y ago
Agreed. Having both around is a nightmare, I still can't believe they ever did it this way.
- Nelkins 8y ago
  I completely understand why they did it, and it actually makes a lot of sense to me. I wish PCLs never happened and I wish .NET Standard happened a lot earlier (seriously, the idea of platform profiles vs a standard API is idiotic and completely unmaintainable). The other place MS has not executed well is versioning/naming and the communication of those versions/names. But soon(?) it'll all be .NET Core and we can put this behind us.
- testvox 8y ago
  Its actually very nice, you can update your framework projects to 4.7 which can cross compile as dotnet core 2.1 then after you are comfortable with the dotnet core build you can drop framework.
  - dxetech 8y ago
    Any way you could provide more information about this? I have some legacy projects on 4.7 that I would love to migrate over to core 2.1
    - svick 8y ago
      If you're using .Net Core version of csproj, it's the difference between e.g. <TargetFramework>netcoreapp2.1</TargetFramework> and <TargetFrameworks>net47;netcoreapp2.0</TargetFrameworks>. I don't know if there's a good way to migrate the csprojs automatically (maybe https://github.com/hvanbakel/CsprojToVs2017? https://github.com/hvanbakel/CsprojToVs2017?), but it shouldn't be that hard manually (by creating a new project), assuming you have just a few projects to migrate.

tluyben2 8y ago

This is good news I think. The fragmentation is quite annoying and not needed I believe. We moved everything (15 years of code) to Core 2 and it was not a lot of work. I could not be happier; the experience for developers is so much nicer.

nobody271 8y ago
How is it nicer? It's a .NET shop but devs are free to use linux as their OS?
- SolarNet 8y ago
  Also not tied to visual studio to build. `dotnet` is an node style command line tool.
  - lkitching 8y ago
    You haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.
    - hermitdev 8y ago
      You've never needed Visual Studio to build .Net projects. They have supported MSBuild from v1.0, you just needed to write the project files by hand - a very tedious process. It's just that building from Visual Studio is by far the most convenient method.
      - pjmlp 8y ago
        MSBuild was introduced around .NET 2.0 after Ant's introduction in the Java world. Before there was a project format, callable with devenv command line tool.
    - rblatz 8y ago
      Speaking of the project files, the new csproj format is my favorite thing. We used to always get conflicts in them, and now we basically never do.

setquk 8y ago

Excellent. I look forward to all of our .Net Framework only 3rd party dependencies being unsupported and abandoned instantly because there's no way anyone is going to bother supporting two distinct platform versions. And also the humongous porting effort to move everything over if we want something that isn't half arsed and abandoned which is what happens in the long tail of any MSFT product cycle. When you phone partner support because something is broken and no one knows how to help you. Another "fuck you" from MSFT. Just like that whole opt-out telemetry crapfest. I want off this crazy train now. Anyone need a Python/C developer (where knowledge is valuable for more than a 3 year window)?

mr_overalls 8y ago
As a Python developer, are you actually surprised by breaking changes? The Python 2/3 split originated a decade ago, after all.
- setquk 8y ago
  Python 3 was released a decade ago. Python 2 is still supported until 2020. 2to3 exists. Python actually give a shit about their users. What a lot of people seem to forget about .Net is that for those of us who have been around since day one, we've been burned over and over again by large product and framework deprecations over the years. This is one too many.
  - kyberias 8y ago
    > burned over and over again by large product and framework deprecations over the years. What large framework deprecations? I've been around and I don't feel burned at all.
    - setquk 8y ago
      WCF, WWF, UWP, AppFabric, EF incompatibility etc etc. Basically the entire enterprise stack. And I’m not even talking about the whole original .net and com stuff.

TimTheTinker 8y ago

Now that Microsoft no longer has a "Windows or Office" angle to everything they do, what is their angle here (i.e. how does a cross-platform .NET target contribute to their bottom line)? I know they generally want to grow (1) Azure, and (2) developer mindshare. I see how a cross-platform .NET Core contributes to Microsoft's developer mindshare, and perhaps how Azure could follow up by cornering the market on really great back-end .NET Core hosting and operations. Is there anything beyond that?

cptskippy 8y ago
There are libraries for .NET Core that play very very nicely with Azure. And there are parts of Azure that play very nicely with their Enterprise software like Active Directory. It's all circular.
int_19h 8y ago
Think about how many cross-platform products Microsoft itself is working on. And how many engineers it has that are already proficient in .NET and C#...

mariusmg 8y ago

This is bullshit actually. They should also come out publicly and announce if .NEt Framework 4.8 is the last version or not.

da_chicken 8y ago

I guess my thinking is that if ASP.NET Core 3.0 requires a different framework and there's no way to easy the transition through .NET Standard code, why should I consider ASP.NET Core 3.0 over any other framework? What makes moving to ASP.NET Core 3.0 appealing for an existing project is exactly .NET Standard. If that goes away, then what's the draw? The product line will need to have a version with a compatibility break no matter what. Why should we favor ASP.NET Core 3.0 over anything else, especially when the vendor just screwed us for picking their last product, ASP.NET? Why wouldn't the same thing happen again when Microsoft releases ASP.NET Core Futuro 1.0 in 2030?

ksec 8y ago

I wonder if Stackexchange has moved everything to .Net Core and Linux along with ASP.Net 3.0?

jongalloway2 8y ago
They've already started moving to .NET Core: https://twitter.com/nick_craver/status/1031858480888639488 https://twitter.com/nick_craver/status/1031858480888639488

garganzol 8y ago

Worst PR move Microsoft could ever take. Developers don't need another Python 2 vs 3 debacle. There should not be .NET Framework. There should not be .NET Core. There should be .NET, a singular powerful platform that does it all.

Quarrelsome 8y ago
I remember a confused developer looking at a brochure that said: "when to choose WinForm and when to choose WPF". His question was: > why do I have to choose?
manigandham 8y ago
"platform" is vague and doesn't describe much on its own. .NET is vast, and the runtimes are what actually run the code packages on various devices. .NET Framework has been the original Windows implementation and now we have a fast, lightweight and modern cross-platform implementation with .NET Core. It makes sense to consolidate on a single runtime that now works well on Windows and is at 99% parity with legacy features.
- garganzol 8y ago
  .NET Core is not on par. It is seriously lacking in vision and attitude. It has some nice properties like portable deployment and that's basically it. The rest is just one to one copy from .NET Framework, plus a bit of quick and dirty additions here and there without a further thought. Please note how the latter statement signifies the endangered future state of the platform.
  - manigandham 8y ago
    "vision and attitude" is 100x more vague than platform. Care to actually explain what you think it should be then? .NET Core is cross-platform. That is a massive change that you seem to just ignore.
    - deleted 8y ago
      [deleted]

manigandham 8y ago

Makes perfect sense, and seems to have been general expectation of the community for a long time. No need to keep maintaining 2 runtimes when there is a modern, fast, lightweight version that is cross-platform and will now be beyond parity at the next release.

jimnotgym 8y ago

I feel like .NET Core has become a technology I should be considering for my team, not least because it is so much easier to find .NET devs in the UK than just about anything else (apart from php WordPress and Magento peeps). I feel I know nothing about it at all, and I wonder if anyone would be kind enough to suggest some resources? I'm primarily going to be working with enterprise CRUD apps, and ERP stuff. Out of interest, what are the options for cross platform desktop apps, if the Windows GUIs are going to remain closed source?

avinium 8y ago
> Out of interest, what are the options for cross platform desktop apps, if the Windows GUIs are going to remain closed source? .NET Core 3 will support WPF -https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/ https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...
- blinkingled 8y ago
  No, it's not cross platform. WPF will be supported on .Net Core runninng on Windows platform only - previously you needed .NET framework to run WPF apps - given everything will be .NET Core going forward this move makes sense.
  - avinium 8y ago
    Oops, you’re right, didnt read my own link closely enough. I guess Avalonia is the only option for cross platform .NET UI? https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia
jf- 8y ago
There is no official cross platform desktop GUI solution for .NET core. There are third party efforts however, take a look at avalonia and eto.forms. Or alternatively think of doing a web app in ASP.NET core. If you don’t need a bells and whistles SPA then ASP.NET core MVC is a very performant solution.

akra 8y ago

A link on the original announcement page states "Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.". If this is right the high coupling between the CLR and what really is a framework/library on top astounds me and is somewhat worrying. I'm foreseeing future deployment horrors. One of the advantages of .NET is portable IL code across anything that can interpret it similar to Java. If this is broken and I can only use .NET/ASP.NET Core CLR with certain native system dependencies installed then this big advantage of the .NET platform IMO is gone and creates some surprising non-intuitive issues. You can see one example of this in the issue here: https://github.com/aspnet/AspNetCore/issues/3307 https://github.com/aspnet/AspNetCore/issues/3307. I install the package; then also need to install a system wide package using my package manager to back it? If I install the package I should be able to use it. It seems as if the GAC is back just for ASP.NET however? Unfortunately as I experienced recently installing the right asp net runtime doesn't necessarily fix the problem either; it just allows the app to start but then other run-time issues pop up. The only fix is self-containing the app - tough luck if your on a distro not supported. Maybe these are teething issues but the constant change between minor versions has been painful. ASP.NET is no longer just another Nuget library it seems - it's now been promoted to be part of the CLR and this decision is the logical extension of that.

sayali321 8y ago

Microsoft will make major updates to ASP.NET Core, including integration of projects and frameworks, tighter integration with .NET Core, and integration with third-party open source kits, these improvements will help developers complete development work faster The way the project is referenced and run on ASP.NET Core changes as the version’s iteration changes. In 1.0, ASP.NET Core itself is a “package” and appears in the project just like any other NuGet package reference. This has its advantages and disadvantages. Over time, this model has evolved. In 2.1, ASP.NET Core eventually evolved into a “shared framework” for .NET Core. To know more about.net core follow our Website: https://crbtech.in/programmes/dot-net-training-programme https://crbtech.in/programmes/dot-net-training-programme