4 ms·

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.

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.

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.