5 ms·

Just that in difference to Python, everyone wants but not everyone can migrate to .NET Core. Also the source code is compatible.

• pjmlp 6y ago
  Not even Microsoft teams themselves have done it, plenty of MS stuff like SharePoint, Dynamics and SQL Server rely on .NET Framework. Source being compatible doesn't help when the libraries require code rewrites anyway.
  • pionar 6y ago
    SQL Server itself does not rely on .NET Framework. SQL CLR, an optional component does. We run SQL Server in Linux containers now.
    • meepmorp 6y ago
      MS SQL Server started out as a port (to OS/2!) of Sybase SQL Server, which ran on Xenix (among other unixes). History doesn't repeat, but it does rhyme.
    • pjmlp 6y ago
      Try to run SQL Server stored procedures that rely on SQL CLR.
      • pionar 6y ago
        Why? That's just asking for poor perf, even on Windows. I would never do that. Leave CLR in applications, where it belongs.
        • pjmlp 6y ago
          Customers decide what gets done.
• moron4hire 6y ago
  Also, .NET 5 is now here, and 6 is already in preview, which are much, much more backwards compatible than .NET Core 3. And unlike Python, we had .NET Standard to start migrating code between Framework and Core. A lot of extant code on NuGet has already migrated and there is really very little you can't do these days.
  • pjmlp 6y ago
    Unless one is using third party controls, CMS like SiteCore, SharePoint and Dynamics, writing custom .NET code to be called by SQL Server stored procedures, having a working WCF infrastructure, using RDMS with EF 6 that isn't SQL Server, in-house stuff that isn't fully covered by the Windows Compatibility Pack, and a couple of other little things.
    • hackerfromthefu 6y ago
      Also asp.net webforms is not supported, webservice/soap are 'supported' but the tooling is broken and i don't think you could extend a system with it in modern VS. The winforms editor works but is buggier with each new version, and asp.net mvc projects are similar but changed, and I'm sure the list of issues continues. Also from my experience coaching and consulting there's a significant learning curve for .NET framework developers to work in the new core/.NET 5 systems.
      • moron4hire 6y ago
        So keep using .NET Framework. v4.8 is only 3 years old and there is no end date set on the support yet. Considering the last version of the v3 era will be supported until 2029, I'm sure the last version of the v4 era will get quite a long period of support as well. https://docs.microsoft.com/en-us/lifecycle/products/microsoft-net-framework https://docs.microsoft.com/en-us/lifecycle/products/microsof... I bit the bullet and transitioned from WebForms to ASP.NET Core. I think it's easier than WebForms ever was. You can replicate 90% of what WebForms did with Razor Pages, but you also get much easier support for building RESTful APIs. And with DI built-in, I don't have to worry about junior devs forgetting to close/dispose database connections ever again.
• hackerfromthefu 6y ago
  Actually its not that easy, depending which parts of framework you used. It's certainly reasonable, but will take re-work for many applications beyond the project structure migration. I think in .NET 6/7/8 the .NET framework migration situation will improve to be mostly pure migration. For example I migrated about 75% of a moderately large winforms system directly, but 25% needed rewrites due to missing core implementations for framework libraries. e.g. MS chart component not implemented in core yet, soap services changing to grpc, and various others. And this system was originally built to minimise third party dependencies and use the core framework or microsoft provided libraries wherever possible.