none
What is the future of LINQ to SQL as of 2016?

    Question

  • I am seeing a lot of posts questioning the future of LINQ to SQL, many from 2008-2010.  And many of those didn't seem to have an answer. 

    So, what's the current MS thinking, and if not encouraging, what's the alternative for someone who wants to use LINQ with a SQL database (in my case SQLite, which is great for my simple dbms needs and supports the IDbConnection interface)? 

    Steve

    P.S. I put the year in the title since Forums posts don't show the date of the post unless you click on them (a helpful improvement I would think).

    Saturday, April 23, 2016 7:21 PM

Answers

  • Sorry I didn't see this post (the forums are having big time trouble).

    As I said the code is mostly the same.  When I converted one big app what I came up with was to delete the LinqToSQl generated code (just exclude it from the project).  Then generate the EF code.  If you ensure that the EF context name is the same as the Linq context name then the changes should be minimal.

    Now I am still using VS 2013 (I really don't like 2015 so until at least a couple of service packs I won't be using it).  

    When you try to get a connection to SQLLite are you using the Server Explorer?  The following link may help with that.

    http://www.global-webnet.com/blog/post/2015/06/29/How-to-use-SQLite-Designer-Support-in-Visual-Studio.aspx

    Good luck.


    Lloyd Sheen

    • Marked as answer by Cincy Steve Monday, May 9, 2016 1:01 PM
    Sunday, May 8, 2016 11:05 PM
  • When I converted from Linq to EF (using SQLServer) the changes to the code were almost negligible.  The biggest thing is that the simple GetChangeSet to find out if there were changes is replaced (sorry not near a VS workstation) and that was about it.   The other thing was the generation of Stored Procedure code but I'm not familiar with SQLLite so that might not be a problem.

    I doubt that Linq will go away soon since Linq is used also in language just to query regular object collections.


    Lloyd Sheen

    Tuesday, April 26, 2016 8:16 PM

All replies

  • The "replacement" for Linq to SQL is the much enhanced Entity FrameWork.  There is a provider available for SQLLite.

    https://www.nuget.org/packages/EntityFramework.SQLite/


    Lloyd Sheen

    Sunday, April 24, 2016 6:50 PM
  • Lloyd - Thx for responding.  

    I've been trying unsuccessfully to test EF with SQLite, including using the EF.SQLite provider you suggested.  I can't get a SQLite data provider to appear in the EF Designer under VS Community 2015, so I can't connect to an existing SQLite database (and probably wouldn't be able to generate one either).  As a result, I have been looking at bypassing the EF Designer and hand-coding the EF objects, but that looks really ugly (e.g. I'm not proficient in XML).

    Unless I can come up with a way to use the EF Designer with SQLite (I have posts both in the MS Forums and an open SQLite.org ticket), I'll need to use Linq to SQL, which looks very simple and is currently working in my app. My main concern is that Linq to SQL will be pulled out from under me at an inopportune time.

    Is there much risk in plowing ahead with Linq to SQL and later replacing it with EF when I can get it to work?  I'm thinking that I should be able to easily change all my Linq queries and updates by replacing references to the Linq to SQL DataContext with references to an EF DbContext, provided I reference strongly typed entity classes in my Linq code.  Is that true?

    Thanks for the help.  Steve








    • Edited by Cincy Steve Tuesday, April 26, 2016 6:54 PM
    Tuesday, April 26, 2016 6:44 PM
  • When I converted from Linq to EF (using SQLServer) the changes to the code were almost negligible.  The biggest thing is that the simple GetChangeSet to find out if there were changes is replaced (sorry not near a VS workstation) and that was about it.   The other thing was the generation of Stored Procedure code but I'm not familiar with SQLLite so that might not be a problem.

    I doubt that Linq will go away soon since Linq is used also in language just to query regular object collections.


    Lloyd Sheen

    Tuesday, April 26, 2016 8:16 PM
  • Sorry I didn't see this post (the forums are having big time trouble).

    As I said the code is mostly the same.  When I converted one big app what I came up with was to delete the LinqToSQl generated code (just exclude it from the project).  Then generate the EF code.  If you ensure that the EF context name is the same as the Linq context name then the changes should be minimal.

    Now I am still using VS 2013 (I really don't like 2015 so until at least a couple of service packs I won't be using it).  

    When you try to get a connection to SQLLite are you using the Server Explorer?  The following link may help with that.

    http://www.global-webnet.com/blog/post/2015/06/29/How-to-use-SQLite-Designer-Support-in-Visual-Studio.aspx

    Good luck.


    Lloyd Sheen

    • Marked as answer by Cincy Steve Monday, May 9, 2016 1:01 PM
    Sunday, May 8, 2016 11:05 PM
  • Lloyd -

    Thanks for the additional input.  

    I'm sure that one of my attempts to get EF to work with SQLite in VS 2015 included following the steps noted in the link you provided, including installing the x86 version and the designer components into the GAC.  Not sure why that didn't work, but at this point I've marched on with Linq to SQL instead of EF. To fill in for the lack of designer support, I've written a small (and simple) utility that generates the Linq to SQL DataContext related code in C# based on a SQLite database's schema.  I offered it to Erik EJ for use in his SQL Server Compact & SQLite Toolbox, but he decided to pass.

    It's comforting to hear that moving from Linq to SQL to EF eventually should be very straightforward.  It certainly looked to me like that would be the case.  For now, I'm sticking with Linq to SQL since my simple needs do not require the additional capabilities offered by EF.

    Thanks again.  Steve


    Monday, May 9, 2016 12:57 PM