13 ms·

I'd be curious to know what is the actual adoption of .net core. I.e. of all the actively developed applications (not just new projects), what is the .net core

by cm2187 4y ago

I'd be curious to know what is the actual adoption of .net core. I.e. of all the actively developed applications (not just new projects), what is the .net core / .net framework split. I found that the upgrade process is not seamless. Asp.net core has little to do with asp.net MVC. Winform introduced all sorts of contraints. The BCL is full of small changes or features missing. People are less vocal than for the python schism, but I'd expect a lot of projects to be stuck on .net framework, not the least because of incompatible dependencies. Nullable reference type is another massive breaking change coming if they make it more than a compiler warning, which I suspect is the long term intention. Not breaking your users used to be a laudable goal of the .net team. I miss it.

jve 4y ago
> Not breaking your users used to be a laudable goal of the .net team. I miss it Is it that bad once you are on .NET Core? Asking as someone still on Framework. Framework -> Core ofcourse is breaking, what did you expect when going cross platform and totally rearchitected?
- cm2187 4y ago
  I am sure cross platform is useful to some users but not to me. So to me it's all breaking changes for little benefits. I am not saying .net core is bad, just that the migration is a lot of work. And you need to disable all sorts of compiler warnings unless you are ready to rewrite pretty much all your code to make it nullable ref type friendly. And some day those warnings will be errors.
  - Kwpolska 4y ago
    > And you need to disable all sorts of compiler warnings unless you are ready to rewrite pretty much all your code to make it nullable ref type friendly. Not really. Just disable nullability checking — you can do it project-wide by removing the Nullable tag from your .csproj, and you can continue ignoring nullability. > And some day those warnings will be errors. [citation needed]. A lot of code is written without nullability in mind. That includes the .NET Core BCL, AFAIK.
    - Hawxy 4y ago
      > That includes the .NET Core BCL, AFAIK. The BCL was completely annotated with NRTs for the .NET 7 release, minus some #nullable disable spots.
- simooooo 4y ago
  It’s fine while on core. Maybe adjusted the app setup 2-3 times, fairly trivial stuff, an hour or so in the last year
starik36 4y ago
I just ported a pretty large domain specific library from VB with .NET Framework 4.61 to C# with .NET 7. It took me probably 3 to 4 days to do with the assistance of Instant C# converter. There are lots of gotchas here and there and it does require a pretty reasonable understanding of both legacy and new frameworks.
- NicoJuicy 4y ago
  I'm interested in this case! I have a bit app: Razor, MVC, EF, custom nuget packages, reflection, very advanced expressions ( linq) and my IoC is Autofac ( .net 4.7.2). 101 projects in one solution. Have you got any pointers on gotchas? Did a quick attempt ( 1 evening) and got blocked on my nugets+ Autofac.
  - twodave 4y ago
    Getting all your private nugets onto .NET standard 2.0 first will help immensely. You can add precompiler directives for anything strictly incompatible. After that it’s just the usual dependency hell that plagues every modern ecosystem. Also have a look at the MS upgrade/migration guides for .NET. They’re exhaustive and extremely helpful.
    - NicoJuicy 4y ago
      Thanks, that's indeed exactly what I tried. I'll have another try later this year probably :p
  - starik36 4y ago
    > 101 projects Yikes. This is in C# I assume? If in VB, I'd run one project through Instant C# and see how many problems you encounter. There are lots of VBisms that are simply not in C# (like statement for one, xml literals, etc...). Run the simplest project through the `upgrade-assistant` tool. It'll convert it to .NET Core. I saw the sibling post recommend .NET Standard, but if you don't plan on using anything legacy this is more headache than its worth. But yeah, I hear you on the nuget dependencies. Some of them were never ported to .NET Standard or Core so you are left trying to recompile them manually yourself.
twodave 4y ago
The move away from web forms has indeed been painful. Mostly because our web forms were pretty stupidly implemented, though. It’s a legitimate downer, though. It’s been a lot easier to migrate back-end services. Nullable reference types are completely optional. You can turn them off at the project level. I find they make more sense for some projects (domain logic, etc.) than others (EF and API projects for example).
nickpeterson 4y ago
Another thing to keep in mind is Microsoft shops don’t tend to use anything else. So while I’m sure many have not transitioned, it’s basically a forgone conclusion. The competitors to most .net apps are excel and saas.
JenrHywy 4y ago
We moved from ASP.NET MVC on Framework 4.8 to .net core without it being too painful. Mostly we needed to re-work the authentication pipeline stuff, but the netcore way ends up being much nicer anyway

by cm2187 4y ago

jve 4y ago

> Not breaking your users used to be a laudable goal of the .net team. I miss it Is it that bad once you are on .NET Core? Asking as someone still on Framework. Framework -> Core ofcourse is breaking, what did you expect when going cross platform and totally rearchitected?

cm2187 4y ago
I am sure cross platform is useful to some users but not to me. So to me it's all breaking changes for little benefits. I am not saying .net core is bad, just that the migration is a lot of work. And you need to disable all sorts of compiler warnings unless you are ready to rewrite pretty much all your code to make it nullable ref type friendly. And some day those warnings will be errors.
- Kwpolska 4y ago
  > And you need to disable all sorts of compiler warnings unless you are ready to rewrite pretty much all your code to make it nullable ref type friendly. Not really. Just disable nullability checking — you can do it project-wide by removing the Nullable tag from your .csproj, and you can continue ignoring nullability. > And some day those warnings will be errors. [citation needed]. A lot of code is written without nullability in mind. That includes the .NET Core BCL, AFAIK.
  - Hawxy 4y ago
    > That includes the .NET Core BCL, AFAIK. The BCL was completely annotated with NRTs for the .NET 7 release, minus some #nullable disable spots.
simooooo 4y ago
It’s fine while on core. Maybe adjusted the app setup 2-3 times, fairly trivial stuff, an hour or so in the last year

starik36 4y ago

I just ported a pretty large domain specific library from VB with .NET Framework 4.61 to C# with .NET 7. It took me probably 3 to 4 days to do with the assistance of Instant C# converter. There are lots of gotchas here and there and it does require a pretty reasonable understanding of both legacy and new frameworks.

NicoJuicy 4y ago
I'm interested in this case! I have a bit app: Razor, MVC, EF, custom nuget packages, reflection, very advanced expressions ( linq) and my IoC is Autofac ( .net 4.7.2). 101 projects in one solution. Have you got any pointers on gotchas? Did a quick attempt ( 1 evening) and got blocked on my nugets+ Autofac.
- twodave 4y ago
  Getting all your private nugets onto .NET standard 2.0 first will help immensely. You can add precompiler directives for anything strictly incompatible. After that it’s just the usual dependency hell that plagues every modern ecosystem. Also have a look at the MS upgrade/migration guides for .NET. They’re exhaustive and extremely helpful.
  - NicoJuicy 4y ago
    Thanks, that's indeed exactly what I tried. I'll have another try later this year probably :p
- starik36 4y ago
  > 101 projects Yikes. This is in C# I assume? If in VB, I'd run one project through Instant C# and see how many problems you encounter. There are lots of VBisms that are simply not in C# (like statement for one, xml literals, etc...). Run the simplest project through the `upgrade-assistant` tool. It'll convert it to .NET Core. I saw the sibling post recommend .NET Standard, but if you don't plan on using anything legacy this is more headache than its worth. But yeah, I hear you on the nuget dependencies. Some of them were never ported to .NET Standard or Core so you are left trying to recompile them manually yourself.

twodave 4y ago

The move away from web forms has indeed been painful. Mostly because our web forms were pretty stupidly implemented, though. It’s a legitimate downer, though. It’s been a lot easier to migrate back-end services. Nullable reference types are completely optional. You can turn them off at the project level. I find they make more sense for some projects (domain logic, etc.) than others (EF and API projects for example).

nickpeterson 4y ago

Another thing to keep in mind is Microsoft shops don’t tend to use anything else. So while I’m sure many have not transitioned, it’s basically a forgone conclusion. The competitors to most .net apps are excel and saas.

JenrHywy 4y ago

We moved from ASP.NET MVC on Framework 4.8 to .net core without it being too painful. Mostly we needed to re-work the authentication pipeline stuff, but the netcore way ends up being much nicer anyway