10 ms·

Lessons Learned while Converting from ASP.NET to .NET Core

154 points by beyti 10y ago

statictype 10y ago
So deploying web apps now consists of deploying a service that uses kestrel and having a reverse proxy in front of it (IIS or nginx or something)as the first point of contact. Is that correct? That's the recommended way to deploy?
- Frondo 10y ago
  Yes, that's correct. I have a side project with a couple of sites on a small Linux VPS, each one runs on port 5005, 5006, 5007, and so on. nginx passes requests to each different domain name onto the servers listening on their respective ports.
- taspeotis 10y ago
  Yes. If you want to see how it might work, Scott Hanselman posted an example [1] recently using nginx. [1] http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteToACheapLinuxVMHost.aspx http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteT...
eksemplar 10y ago
This is quite frankly an excellent list of why we won't be changing any time soon, with key points being: > Things like virtual hosts, logging, security, etc. > Newtonsoft now defaults to camelCase > Log4net doesn’t work and neither do countless other dependencies, unless you target .NET 4.5 I mean a lot of those things are the reason we're using .Net over more other technologies to begin with.
- chrisherring 10y ago
  .net core certainly does have security, logging etc. IIS, as opposed to kestral, has more features and you can host under IIS so this is a non issue. The camelCase setting is a one line code change if you don't like it. Not at all a reason to avoid the framework. It's using newtonsoft for this so it may even be a change in the package itself? Anyway I changed the default and then ended up reverting back anyway since camelCase is a better format when using the objects in JavaScript. It's not meant to support everything as the goal is cross platform. IMO it's a great platform if you understand its limits.
- dodyg 10y ago
  aspnet.core works fine with .NET 4.5. For me the big attraction to aspnetcore is not the aspnetcore MVC, but the new infrastructure that they build around it. I am working on a project right now going down to every single little tiny details of aspnetcore capabilities https://github.com/dodyg/practical-aspnetcore https://github.com/dodyg/practical-aspnetcore
  - restlessmedia 10y ago
    Some good work there, I'd be interested to see more examples of aspnetcore recipes.
    - dodyg 10y ago
      If you have anything particular in mind, please create an issue and I will get to them eventually.
blakeyrat 10y ago
What the heck are you supposed to do without System.Drawing? I find it incredible they've just plain removed it altogether.
- bobcostas55 10y ago
  You use the superior ImageMagick instead.
- taspeotis 10y ago
  System.Drawing is wed to GDI+ so not cross platform. There are third party libraries that work just fine. https://github.com/imazen/Graphics-vNext https://github.com/imazen/Graphics-vNext If you don't care about .NET Core but you do care about ASP.NET Core you can always run ASP.NET Core on Windows and use System.Drawing.
  - blakeyrat 10y ago
    It's only "wed to GDI+" because the current implementation is. Nothing's preventing them from implementing a cross-platform System.Drawing. There's no magic involved in what it does that requires GDI+. I find it unbelievable that they would even consider releasing this without System.Drawing or equivalent being available.
    - jamessouth 10y ago
      I've been working on a solution to that. github.com/JimBobSquarePants/ImageProcessor
      - blakeyrat 10y ago
        That's great, but it belongs in the framework. I'm incredibly disappointed by that decision.
        jamessouth 10y ago
        I do agree. When I spoke to one of the guys there a while back though they said they simply had too much on their plate at the time and were hoping the community would kick in and help.
ofir_geller 10y ago
I recently built a web app with the new dotnet core . the changes were not so bad, I even found that the docs were nicer than the ones you find for the "old" asp. After having to configure camalCase for json a couple of times I like the new default. But migrating an existing app at this point is out of the question, when I no longer need to have nugget packages with rc in the version name we might do it.
- philippelh 10y ago
  If you're talking about project.json, it's already dead :/ http://xoofx.com/blog/2016/05/11/goodbye-project-json/ http://xoofx.com/blog/2016/05/11/goodbye-project-json/
  - ofir_geller 10y ago
    No I'm talking about the version numbers themselves, things like: 1.0.0-preview2-final I will not take a working(and money-making) code base and migrate it to a platform where that is the version I need to use. As for project.json. I actually liked using JSON over XML, but it's a personal preference thing, can't really make a case that it's better.
colemickens 10y ago
>We ended up using the JsonProperty attribute on some things to force their casing how we needed them. That's a weird choice. It's a one-line modification to change back to the legacy naming scheme [1]. (Which is completely non-standard and doesn't follow what basically the entire rest of the web accepts as the standard method of naming js object keys. But hey, .NET people are really beholden to some strange things.) [1]: https://github.com/aspnet/Mvc/issues/4842 https://github.com/aspnet/Mvc/issues/4842
cm2187 10y ago
For a website, not being able to manipulate files (no System.IO.File) or images (no System.Drawing) is a bit of a problem unless all you are doing is serve a database.
- tonyedgecombe 10y ago
  Using System.Drawing from ASP.Net was never supported anyway (although much of it did work). From https://msdn.microsoft.com/en-us/library/system.drawing.aspx https://msdn.microsoft.com/en-us/library/system.drawing.aspx "Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. For a supported alternative, see Windows Imaging Components."
  - joneholland 10y ago
    System.Drawing actually wraps GDI win32 calls, so while it works, running it on a server would be iffy, and running it on non Windows would be impossible. Now, they could reimplement system.drawing using a different backend per platform, but I don't think the demand is high enough.
cm2187 10y ago
Stupid question. How do you share IPs if all the websites on a machine are running their own webserver? When running in IIS, IIS handles the virtual hosts. Unless we found a massive stach of IPv4 IPs?
- awestroke 10y ago
  You typically still use IIS but only as a reverse proxy
  - cm2187 10y ago
    So you set up the self hosted webservers on some non routable local IPs / ports, and set up IIS to map these IPs / ports to the external IP / hostname? Sounds complicated. You have two states to maintain and keep synced. The .net core servers and IIS.
    - 35bge57dtjku 10y ago
      Of course it's complicated, you stipulated that all websites are running their own web server.
      - cm2187 10y ago
        I am not. This seems to be what .net core does, according to the article.
    - blitzd 10y ago
      It's done with Node.js and nginx all the time. Other than the initial configuration nginx is essentially stateless, and there's simple setups out there to automate the nginx config as well, with docker for example: https://github.com/jwilder/nginx-proxy https://github.com/jwilder/nginx-proxy.
- nikon 10y ago
  nginx reverse proxy would be relatively simple. There's even some docs straight from the asp.net site[0]. It's a bit of a paradigm shift from the "old" way but it's quite a normal thing to do with Node.js for example. [0] - https://docs.asp.net/en/latest/publishing/linuxproduction.html#configure-a-reverse-proxy-server https://docs.asp.net/en/latest/publishing/linuxproduction.ht...
faragon 10y ago
"As part of .NET Core, Microsoft (and the community) has created a whole new web server called Kestrel. The goal behind it has been to make it as lean, mean, and fast as possible. IIS is awesome but comes with a very dated pipeline model and carries a lot of bloat and weight with it. In some benchmarks, I have seen Kestrel handle up to 20x more requests per second. Yowzers!" So the new Microsoft web server replacing IIS, Kestrel, is 20x faster in some circumstances? Wasn't IIS "state of the art"?
- cmdkeen 10y ago
  It isn't replacing IIS, and they're very clear that you almost certainly shouldn't be exposing Kestrel to the internet without going through something like nginx or IIS. Kestrel does the bare basics of a web server, it goes a little bit further than the dev servers built into plenty of other language's web frameworks.
  - Avalaxy 10y ago
    > very clear that you almost certainly shouldn't be exposing Kestrel to the internet without going through something like nginx or IIS. Why is that? Will you still have the performance benefit of Kestrel if you use IIS in front of it? How would that work?
    - thomasz 10y ago
      IIS running your web app is kinda slow, because the request has to be pumped through a long, old and rusty pipeline. IIS as a reverse proxy in front of kestrel should be very fast.
    - WorldMaker 10y ago
      The same reasons that Python, Ruby, and Node are almost always reverse-proxied by a "bigger" web server. The "closer to the metal" server handles things like virtual hosts, load balancing, black lists/white lists, throttling, speaking to the kernel-layer about low level IP port specifics, while the "closer to the language" server deals with the realities of your business logic and application code. That separation of concerns between two web servers in a reverse-proxy has become a very useful mainstay "Production best practice" in the Linux/Unix world, so it's nice to see Kestrel follow the larger trends there. It makes it easier to use Kestrel in most Linux/Unix deployments, but some of the reasons that it became best practice apply back to Windows. For instance, the principal of least privilege applies in that the application web server can run in a much more isolated process space than the kernel-level web server and the service boundary to secure between them in a reverse-proxy scenario is "just HTTP". As for performance, IIS is a rather good reverse proxy and efforts to make it better for Kestrel have benefited Node, Python, and Ruby hosting on Windows, as well as vice versa.
sundvor 10y ago
Another "little" one: Studio tooling is still in preview, so NCrunch cannot be used. It's been a moving target for a long time, and too hard to complete until locked down.
jasonkester 10y ago
Just from the examples on this list, it sounds like the only winning move is not to play. I have a handful of sites running ASP.NET 4.5. Migrating them would cost an unknown amount of time and require substantial rewriting of major components (such as all data access). It might not even be physically possible to do, given dependencies on libraries that are still 4.5 only. It sounds like it would also kill our build process dead (adding another major rewrite to the tally). And of course, it would leave us reliant (correct me if I'm wrong here) on a lighter weight version of VS.NET so we'd roll back the clock about 10 years on ReSharper-like goodness. As reward for this, migrating over to Core would gain me roughly $0 in business value. The alternate course is to stay with 4.5 for as long as possible, eventually moving across when Microsoft decide to VB6 it. Sounds like a plan.
- Avalaxy 10y ago
  > it would leave us reliant (correct me if I'm wrong here) on a lighter weight version of VS.NET so No, you can just use the normal Visual Studio, with ReSharper support.
  - jasonkester 10y ago
    Glad to hear. I hadn't seen them mention it anywhere, and since it was such an obvious dealbreaker, I would have expected it to be a major talking point.
    - sundvor 10y ago
      Yep, Resharper is fine but NCrunch won't work for any projects targeting Core, however.
      - dan_b 10y ago
        ...and that is a dealbreaker.
- jsingleton 10y ago
  I'm tracking the dependencies of libraries at: https://anclafs.com https://anclafs.com (ASP.NET Core Library and Framework Support) Prefix is on there so I'll update it to support .NET Core in addition to the ASP.NET Core it already supported (on .NET 4.5). Migrating anything big is probably a bad idea but for new projects Core might be a good option.
Hondor 10y ago
It's depressing to me that no talk about .Net Core even bothers to mention desktop apps. Winforms and co aren't even on the radar. I guess I'm stuck in the past.
- cmdkeen 10y ago
  It supports UWP development. The .Net Framework isn't going anywhere though, if you're doing Windows desktop development in a legacy framework then you don't need the cross platform-ness of Core.
- DonnyV 10y ago
  Honestly if I had to do a new desktop app project. I would probably go with nodejs + chromium + html (front end) & C# + .NET Core (backend). You get total control over the UI without having to deal with WPF, plus it runs cross platform.
- jsgo 10y ago
  I could be totally wrong as I haven't really messed with it beyond dabbling, but from what I've heard, ASP.NET 4.? (6?) to ASP.NET Core is a pretty big shift which is why there's a lot of conversation around it. In fact, ASP.NET Core has a lot of changes vs the RCs (dipped toes into JSON configs, reverted back). Nuget has given up front end to bower now as well. Perhaps that means desktop .NET Core is a more familiar experience? I'm not sure. But unless it is UWP or ASP.NET, I don't know how much we'll see coming as far as talk goes.
- shanselman 10y ago
  Because Core is a server-side framework. WinForms and friends run on full framework. That said, check out Avalonia and some other OSS experiments.
- cartman82 10y ago
  Microsoft is building their own new desktop apps on Electron. That tells you all you need to know.
- WorldMaker 10y ago
  All of the work in .NET Core benefits ".NET Native". .NET Native is what powers the .NET stack side for Universal Windows Platform (UWP) apps. WinForms has been considered deprecated since WPF and WPF is essentially deprecated for UWP. (In an interesting historical aside, in some ways the UWP is what WPF was promised to be way back when WPF was still codenamed Avalon.) Certainly WinForms and WPF aren't going anywhere any time soon (both in terms of backward compatibility will be stable for a long time still, but don't expect any new things), but UWP is clearly the way forward for new apps and it is benefiting from the work going into .NET Core. The Desktop App Converter recently released (nee Project Centennial) can help if you've got a big investment in WinForms and wish to slowly migrate to UWP, so you aren't necessarily "stuck" in the past if you do want to try to move forward.
sklarsa 10y ago
I'm surprised that there's no DataTable in .NET Core. I've found them to be incredibly useful for ETL and other processes that involve ingesting or outputting tabular data. Are there any alternative 3rd party libraries out there that have similar functionality?

154 points by beyti 10y ago

So deploying web apps now consists of deploying a service that uses kestrel and having a reverse proxy in front of it (IIS or nginx or something)as the first point of contact. Is that correct? That's the recommended way to deploy?

Frondo 10y ago
Yes, that's correct. I have a side project with a couple of sites on a small Linux VPS, each one runs on port 5005, 5006, 5007, and so on. nginx passes requests to each different domain name onto the servers listening on their respective ports.
taspeotis 10y ago
Yes. If you want to see how it might work, Scott Hanselman posted an example [1] recently using nginx. [1] http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteToACheapLinuxVMHost.aspx http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteT...

eksemplar 10y ago

This is quite frankly an excellent list of why we won't be changing any time soon, with key points being: > Things like virtual hosts, logging, security, etc. > Newtonsoft now defaults to camelCase > Log4net doesn’t work and neither do countless other dependencies, unless you target .NET 4.5 I mean a lot of those things are the reason we're using .Net over more other technologies to begin with.

chrisherring 10y ago
.net core certainly does have security, logging etc. IIS, as opposed to kestral, has more features and you can host under IIS so this is a non issue. The camelCase setting is a one line code change if you don't like it. Not at all a reason to avoid the framework. It's using newtonsoft for this so it may even be a change in the package itself? Anyway I changed the default and then ended up reverting back anyway since camelCase is a better format when using the objects in JavaScript. It's not meant to support everything as the goal is cross platform. IMO it's a great platform if you understand its limits.
dodyg 10y ago
aspnet.core works fine with .NET 4.5. For me the big attraction to aspnetcore is not the aspnetcore MVC, but the new infrastructure that they build around it. I am working on a project right now going down to every single little tiny details of aspnetcore capabilities https://github.com/dodyg/practical-aspnetcore https://github.com/dodyg/practical-aspnetcore
- restlessmedia 10y ago
  Some good work there, I'd be interested to see more examples of aspnetcore recipes.
  - dodyg 10y ago
    If you have anything particular in mind, please create an issue and I will get to them eventually.

blakeyrat 10y ago

What the heck are you supposed to do without System.Drawing? I find it incredible they've just plain removed it altogether.

bobcostas55 10y ago
You use the superior ImageMagick instead.
taspeotis 10y ago
System.Drawing is wed to GDI+ so not cross platform. There are third party libraries that work just fine. https://github.com/imazen/Graphics-vNext https://github.com/imazen/Graphics-vNext If you don't care about .NET Core but you do care about ASP.NET Core you can always run ASP.NET Core on Windows and use System.Drawing.
- blakeyrat 10y ago
  It's only "wed to GDI+" because the current implementation is. Nothing's preventing them from implementing a cross-platform System.Drawing. There's no magic involved in what it does that requires GDI+. I find it unbelievable that they would even consider releasing this without System.Drawing or equivalent being available.
  - jamessouth 10y ago
    I've been working on a solution to that. github.com/JimBobSquarePants/ImageProcessor
    - blakeyrat 10y ago
      That's great, but it belongs in the framework. I'm incredibly disappointed by that decision.
      - jamessouth 10y ago
        I do agree. When I spoke to one of the guys there a while back though they said they simply had too much on their plate at the time and were hoping the community would kick in and help.

ofir_geller 10y ago

I recently built a web app with the new dotnet core . the changes were not so bad, I even found that the docs were nicer than the ones you find for the "old" asp. After having to configure camalCase for json a couple of times I like the new default. But migrating an existing app at this point is out of the question, when I no longer need to have nugget packages with rc in the version name we might do it.

philippelh 10y ago
If you're talking about project.json, it's already dead :/ http://xoofx.com/blog/2016/05/11/goodbye-project-json/ http://xoofx.com/blog/2016/05/11/goodbye-project-json/
- ofir_geller 10y ago
  No I'm talking about the version numbers themselves, things like: 1.0.0-preview2-final I will not take a working(and money-making) code base and migrate it to a platform where that is the version I need to use. As for project.json. I actually liked using JSON over XML, but it's a personal preference thing, can't really make a case that it's better.

colemickens 10y ago

>We ended up using the JsonProperty attribute on some things to force their casing how we needed them. That's a weird choice. It's a one-line modification to change back to the legacy naming scheme [1]. (Which is completely non-standard and doesn't follow what basically the entire rest of the web accepts as the standard method of naming js object keys. But hey, .NET people are really beholden to some strange things.) [1]: https://github.com/aspnet/Mvc/issues/4842 https://github.com/aspnet/Mvc/issues/4842

cm2187 10y ago

For a website, not being able to manipulate files (no System.IO.File) or images (no System.Drawing) is a bit of a problem unless all you are doing is serve a database.

tonyedgecombe 10y ago
Using System.Drawing from ASP.Net was never supported anyway (although much of it did work). From https://msdn.microsoft.com/en-us/library/system.drawing.aspx https://msdn.microsoft.com/en-us/library/system.drawing.aspx "Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. For a supported alternative, see Windows Imaging Components."
- joneholland 10y ago
  System.Drawing actually wraps GDI win32 calls, so while it works, running it on a server would be iffy, and running it on non Windows would be impossible. Now, they could reimplement system.drawing using a different backend per platform, but I don't think the demand is high enough.

cm2187 10y ago

Stupid question. How do you share IPs if all the websites on a machine are running their own webserver? When running in IIS, IIS handles the virtual hosts. Unless we found a massive stach of IPv4 IPs?

awestroke 10y ago
You typically still use IIS but only as a reverse proxy
- cm2187 10y ago
  So you set up the self hosted webservers on some non routable local IPs / ports, and set up IIS to map these IPs / ports to the external IP / hostname? Sounds complicated. You have two states to maintain and keep synced. The .net core servers and IIS.
  - 35bge57dtjku 10y ago
    Of course it's complicated, you stipulated that all websites are running their own web server.
    - cm2187 10y ago
      I am not. This seems to be what .net core does, according to the article.
  - blitzd 10y ago
    It's done with Node.js and nginx all the time. Other than the initial configuration nginx is essentially stateless, and there's simple setups out there to automate the nginx config as well, with docker for example: https://github.com/jwilder/nginx-proxy https://github.com/jwilder/nginx-proxy.
nikon 10y ago
nginx reverse proxy would be relatively simple. There's even some docs straight from the asp.net site[0]. It's a bit of a paradigm shift from the "old" way but it's quite a normal thing to do with Node.js for example. [0] - https://docs.asp.net/en/latest/publishing/linuxproduction.html#configure-a-reverse-proxy-server https://docs.asp.net/en/latest/publishing/linuxproduction.ht...

faragon 10y ago

"As part of .NET Core, Microsoft (and the community) has created a whole new web server called Kestrel. The goal behind it has been to make it as lean, mean, and fast as possible. IIS is awesome but comes with a very dated pipeline model and carries a lot of bloat and weight with it. In some benchmarks, I have seen Kestrel handle up to 20x more requests per second. Yowzers!" So the new Microsoft web server replacing IIS, Kestrel, is 20x faster in some circumstances? Wasn't IIS "state of the art"?

cmdkeen 10y ago
It isn't replacing IIS, and they're very clear that you almost certainly shouldn't be exposing Kestrel to the internet without going through something like nginx or IIS. Kestrel does the bare basics of a web server, it goes a little bit further than the dev servers built into plenty of other language's web frameworks.
- Avalaxy 10y ago
  > very clear that you almost certainly shouldn't be exposing Kestrel to the internet without going through something like nginx or IIS. Why is that? Will you still have the performance benefit of Kestrel if you use IIS in front of it? How would that work?
  - thomasz 10y ago
    IIS running your web app is kinda slow, because the request has to be pumped through a long, old and rusty pipeline. IIS as a reverse proxy in front of kestrel should be very fast.
  - WorldMaker 10y ago
    The same reasons that Python, Ruby, and Node are almost always reverse-proxied by a "bigger" web server. The "closer to the metal" server handles things like virtual hosts, load balancing, black lists/white lists, throttling, speaking to the kernel-layer about low level IP port specifics, while the "closer to the language" server deals with the realities of your business logic and application code. That separation of concerns between two web servers in a reverse-proxy has become a very useful mainstay "Production best practice" in the Linux/Unix world, so it's nice to see Kestrel follow the larger trends there. It makes it easier to use Kestrel in most Linux/Unix deployments, but some of the reasons that it became best practice apply back to Windows. For instance, the principal of least privilege applies in that the application web server can run in a much more isolated process space than the kernel-level web server and the service boundary to secure between them in a reverse-proxy scenario is "just HTTP". As for performance, IIS is a rather good reverse proxy and efforts to make it better for Kestrel have benefited Node, Python, and Ruby hosting on Windows, as well as vice versa.

sundvor 10y ago

Another "little" one: Studio tooling is still in preview, so NCrunch cannot be used. It's been a moving target for a long time, and too hard to complete until locked down.

jasonkester 10y ago

Just from the examples on this list, it sounds like the only winning move is not to play. I have a handful of sites running ASP.NET 4.5. Migrating them would cost an unknown amount of time and require substantial rewriting of major components (such as all data access). It might not even be physically possible to do, given dependencies on libraries that are still 4.5 only. It sounds like it would also kill our build process dead (adding another major rewrite to the tally). And of course, it would leave us reliant (correct me if I'm wrong here) on a lighter weight version of VS.NET so we'd roll back the clock about 10 years on ReSharper-like goodness. As reward for this, migrating over to Core would gain me roughly $0 in business value. The alternate course is to stay with 4.5 for as long as possible, eventually moving across when Microsoft decide to VB6 it. Sounds like a plan.

Avalaxy 10y ago
> it would leave us reliant (correct me if I'm wrong here) on a lighter weight version of VS.NET so No, you can just use the normal Visual Studio, with ReSharper support.
- jasonkester 10y ago
  Glad to hear. I hadn't seen them mention it anywhere, and since it was such an obvious dealbreaker, I would have expected it to be a major talking point.
  - sundvor 10y ago
    Yep, Resharper is fine but NCrunch won't work for any projects targeting Core, however.
    - dan_b 10y ago
      ...and that is a dealbreaker.
jsingleton 10y ago
I'm tracking the dependencies of libraries at: https://anclafs.com https://anclafs.com (ASP.NET Core Library and Framework Support) Prefix is on there so I'll update it to support .NET Core in addition to the ASP.NET Core it already supported (on .NET 4.5). Migrating anything big is probably a bad idea but for new projects Core might be a good option.

Hondor 10y ago

It's depressing to me that no talk about .Net Core even bothers to mention desktop apps. Winforms and co aren't even on the radar. I guess I'm stuck in the past.

cmdkeen 10y ago
It supports UWP development. The .Net Framework isn't going anywhere though, if you're doing Windows desktop development in a legacy framework then you don't need the cross platform-ness of Core.
DonnyV 10y ago
Honestly if I had to do a new desktop app project. I would probably go with nodejs + chromium + html (front end) & C# + .NET Core (backend). You get total control over the UI without having to deal with WPF, plus it runs cross platform.
jsgo 10y ago
I could be totally wrong as I haven't really messed with it beyond dabbling, but from what I've heard, ASP.NET 4.? (6?) to ASP.NET Core is a pretty big shift which is why there's a lot of conversation around it. In fact, ASP.NET Core has a lot of changes vs the RCs (dipped toes into JSON configs, reverted back). Nuget has given up front end to bower now as well. Perhaps that means desktop .NET Core is a more familiar experience? I'm not sure. But unless it is UWP or ASP.NET, I don't know how much we'll see coming as far as talk goes.
shanselman 10y ago
Because Core is a server-side framework. WinForms and friends run on full framework. That said, check out Avalonia and some other OSS experiments.
cartman82 10y ago
Microsoft is building their own new desktop apps on Electron. That tells you all you need to know.
WorldMaker 10y ago
All of the work in .NET Core benefits ".NET Native". .NET Native is what powers the .NET stack side for Universal Windows Platform (UWP) apps. WinForms has been considered deprecated since WPF and WPF is essentially deprecated for UWP. (In an interesting historical aside, in some ways the UWP is what WPF was promised to be way back when WPF was still codenamed Avalon.) Certainly WinForms and WPF aren't going anywhere any time soon (both in terms of backward compatibility will be stable for a long time still, but don't expect any new things), but UWP is clearly the way forward for new apps and it is benefiting from the work going into .NET Core. The Desktop App Converter recently released (nee Project Centennial) can help if you've got a big investment in WinForms and wish to slowly migrate to UWP, so you aren't necessarily "stuck" in the past if you do want to try to move forward.

sklarsa 10y ago

I'm surprised that there's no DataTable in .NET Core. I've found them to be incredibly useful for ETL and other processes that involve ingesting or outputting tabular data. Are there any alternative 3rd party libraries out there that have similar functionality?