5 ms·

I'm a huge fan of C# and ASP.net, but this transition hasn't went as smoothly as I hoped. I tried .NET core a lot pre-1.0 and it seemed really fragile (especia

I'm a huge fan of C# and ASP.net, but this transition hasn't went as smoothly as I hoped. I tried .NET core a lot pre-1.0 and it seemed really fragile (especially on Mac and Linux, which was my main excitement around it). As I was a bit nervous about that, I started a new project in 'classic' .NET w/ MVC5. It however seems a lot of projects are migrating rapidly to .NET Core and leaving support for legacy projects recently. It does seem to be a giant pain to migrate a legacy asp.net app to asp.net core (very manual). Anyone have any tools/advice on this process?

sebazzz 8y ago
.NET core has several compatibility packages you can use. However, once you have Web Forms in your project there is no way forward but to rewrite the Web Forms pages.
- martinald 8y ago
  Any links? I don't use webforms, just MVC5 with razor pages.
  - benaadams 8y ago
    Assuming its C# you should mostly be able to copy the source of the razor pages and controllers over wholesale. The startup and identity/authentication is a bit different though.
swalsh 8y ago
I was an early adopter of .net core. It definitely had its quirks in the beginning. Recently I gave it another go, it's really improved a lot. Like it's production ready now. I'd say pick it up again.
- martinald 8y ago
  Yeah, I'll definitely use it from day 1 for new greenfield projects, but quite a lot of concepts have changed to make migration trivial.
- snarfy 8y ago
  I remember all of the KRE, KVM, project.json, etc. It was pretty rough, and that's from someone that's been using .net daily since the 1.0 beta many years ago. They've fixed all of that stuff.
DenisM 8y ago
Why even bother? Mvc5 still works well, and will continue working well for the years to come. Is there a pressing need to migrate? I’ve decided to wait it out.
- martinald 8y ago
  Some packages are getting EoLed - eg Auth0 have discontinued their System.Web implementation in favour of .NET core. If it wasn't for that, I wouldn't be worried at all...
  - DenisM 8y ago
    I see, yeah. Maybe you can convince them to stay the course by citing their own tagline? It says legacy right there. We provide a universal authentication & authorization platform for web, mobile, and legacy applications.
- scruffyherder 8y ago
  Donno. I've recently moved stuff to Visual C++ 1.10 with the NT 3.5 SDK and it's been amazingly fast building stuff. Who needs "features" anyway?
euroclydon 8y ago
It's stabile now. Just forget the alphas and 1.X ever existed. If you really want to get a hang of it, don't use Visual Studio. user VS Code, and the CLI tools: https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=netcore2x https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=net...
- c487bd62 8y ago
  Visual Studio is a must for 99% of .net jobs, right? I see a lot of praise and comments that it's so good you can't replace it Do you think they will drop VS and adopt VS Code as the recommended solution? Since it's locked to Windows, bloated and there's no 64 bits version
  - bpicolo 8y ago
    I'm not sure why he's suggesting VS is bad here. VS is still an insanely good C# environment, core or not
  - ickler9 8y ago
    There are some extremely opinionated assumptions underlying your question. VS isn't really bloated, given what it's trying to do- and in recent years it's been rock-solid stable. Visual Studio for Mac exists (old Xamarin Studio) and is coming along. And the engineering team has made its point on 64 bit clear that they don't believe it will bring the performance people like to say it will. But more importantly VS and VS Code are two different approaches- IDE vs TextEditor. The vast majority people would say C#, as a compiled language, is best in an IDE. Either way, I'm pretty confident in predicting that there is no way Visual Studio gets "dropped."
  - kristianp 8y ago
    VS isn't going to be dropped any time soon, there are so many features and plugins for it that it would be a massive job to replace it. They have moved more and more features to run into separate child processes to prevent the memory use requirements for the main VS process. VS 2017 uses a lot more memory than 2013 (the previous one I used). My 8GB machine gets slowdowns every now and due to SQL Server getting swapped out.
markmark 8y ago
Porting to 1.0 was a pretty big headache, there was a lot of stuff in full .NET that wasn't in 1.0, and a lot of open source libs hadn't been ported yet. In 2.0 they had a bit of a rethink about how stripped down Core was going to be and added a heap of stuff in, plus a lot more (most?) big open source libs have been ported. So porting legacy apps is much easier. However I don't see any point porting a legacy app unless there is something in core you want. Perhaps you'd like to move your app over to running on Linux servers? At my previous company we ported parts of our product so that we could sell cross-platform support without needing our users to install mono.
- da_chicken 8y ago
  > Porting to 1.0 was a pretty big headache, there was a lot of stuff in full .NET that wasn't in 1.0 Yeah, this. For example, originally they weren't going to include SqlDBAdapter or DataTables or any related classes. They really just thought everybody was going to be okay with using Entity Framework for everything and not having a generic, non-ORM database interface. Most of my coding involves either extremely simple tables or where I want to manipulate tables for third-party applications that have over a thousand tables where I don't have access to the source code. Most of it is ETL or ETL-like. It's also usually in PowerShell or Python, but some of it is in C#. Making an EF would take ages for some of these applications, especially when the schema isn't always relationally sound (but it's third party so I can't change it). It still just blows my mind they they thought it'd be okay to make everybody box and unbox their database into classed objects instead of just letting you manipulate it as a DataRow. As far as I know, they still consider DataTable and the like to be "legacy".
  - thomasz 8y ago
    That's not really correct. Raw SQL access (SqlCommand etc) was always part of .net core. You can't really call DataTable and friends a generic non-ORM data interface - it's an API unique to ADO.net.

sebazzz 8y ago

.NET core has several compatibility packages you can use. However, once you have Web Forms in your project there is no way forward but to rewrite the Web Forms pages.

martinald 8y ago
Any links? I don't use webforms, just MVC5 with razor pages.
- benaadams 8y ago
  Assuming its C# you should mostly be able to copy the source of the razor pages and controllers over wholesale. The startup and identity/authentication is a bit different though.

swalsh 8y ago

I was an early adopter of .net core. It definitely had its quirks in the beginning. Recently I gave it another go, it's really improved a lot. Like it's production ready now. I'd say pick it up again.

martinald 8y ago
Yeah, I'll definitely use it from day 1 for new greenfield projects, but quite a lot of concepts have changed to make migration trivial.
snarfy 8y ago
I remember all of the KRE, KVM, project.json, etc. It was pretty rough, and that's from someone that's been using .net daily since the 1.0 beta many years ago. They've fixed all of that stuff.

DenisM 8y ago

Why even bother? Mvc5 still works well, and will continue working well for the years to come. Is there a pressing need to migrate? I’ve decided to wait it out.

martinald 8y ago
Some packages are getting EoLed - eg Auth0 have discontinued their System.Web implementation in favour of .NET core. If it wasn't for that, I wouldn't be worried at all...
- DenisM 8y ago
  I see, yeah. Maybe you can convince them to stay the course by citing their own tagline? It says legacy right there. We provide a universal authentication & authorization platform for web, mobile, and legacy applications.
scruffyherder 8y ago
Donno. I've recently moved stuff to Visual C++ 1.10 with the NT 3.5 SDK and it's been amazingly fast building stuff. Who needs "features" anyway?

euroclydon 8y ago

It's stabile now. Just forget the alphas and 1.X ever existed. If you really want to get a hang of it, don't use Visual Studio. user VS Code, and the CLI tools: https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=netcore2x https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=net...

c487bd62 8y ago
Visual Studio is a must for 99% of .net jobs, right? I see a lot of praise and comments that it's so good you can't replace it Do you think they will drop VS and adopt VS Code as the recommended solution? Since it's locked to Windows, bloated and there's no 64 bits version
- bpicolo 8y ago
  I'm not sure why he's suggesting VS is bad here. VS is still an insanely good C# environment, core or not
- ickler9 8y ago
  There are some extremely opinionated assumptions underlying your question. VS isn't really bloated, given what it's trying to do- and in recent years it's been rock-solid stable. Visual Studio for Mac exists (old Xamarin Studio) and is coming along. And the engineering team has made its point on 64 bit clear that they don't believe it will bring the performance people like to say it will. But more importantly VS and VS Code are two different approaches- IDE vs TextEditor. The vast majority people would say C#, as a compiled language, is best in an IDE. Either way, I'm pretty confident in predicting that there is no way Visual Studio gets "dropped."
- kristianp 8y ago
  VS isn't going to be dropped any time soon, there are so many features and plugins for it that it would be a massive job to replace it. They have moved more and more features to run into separate child processes to prevent the memory use requirements for the main VS process. VS 2017 uses a lot more memory than 2013 (the previous one I used). My 8GB machine gets slowdowns every now and due to SQL Server getting swapped out.

markmark 8y ago

Porting to 1.0 was a pretty big headache, there was a lot of stuff in full .NET that wasn't in 1.0, and a lot of open source libs hadn't been ported yet. In 2.0 they had a bit of a rethink about how stripped down Core was going to be and added a heap of stuff in, plus a lot more (most?) big open source libs have been ported. So porting legacy apps is much easier. However I don't see any point porting a legacy app unless there is something in core you want. Perhaps you'd like to move your app over to running on Linux servers? At my previous company we ported parts of our product so that we could sell cross-platform support without needing our users to install mono.

da_chicken 8y ago
> Porting to 1.0 was a pretty big headache, there was a lot of stuff in full .NET that wasn't in 1.0 Yeah, this. For example, originally they weren't going to include SqlDBAdapter or DataTables or any related classes. They really just thought everybody was going to be okay with using Entity Framework for everything and not having a generic, non-ORM database interface. Most of my coding involves either extremely simple tables or where I want to manipulate tables for third-party applications that have over a thousand tables where I don't have access to the source code. Most of it is ETL or ETL-like. It's also usually in PowerShell or Python, but some of it is in C#. Making an EF would take ages for some of these applications, especially when the schema isn't always relationally sound (but it's third party so I can't change it). It still just blows my mind they they thought it'd be okay to make everybody box and unbox their database into classed objects instead of just letting you manipulate it as a DataRow. As far as I know, they still consider DataTable and the like to be "legacy".
- thomasz 8y ago
  That's not really correct. Raw SQL access (SqlCommand etc) was always part of .net core. You can't really call DataTable and friends a generic non-ORM data interface - it's an API unique to ADO.net.