Database advice needed: porting VB6/ADO/JET app to VB.NET

I need to update (well, rewrite really) a SMALL VB6 application which uses ADO to access a JET database, to a vb.net app in Visual Studio 2008.

My research suggests that I should use LINQ, but it doesn't seem to be possible to connect to JET. If JET is now deprecated, what should I use? Or should I use ADO.NET without LINQ?

Please don't answer SQL Server! - this needs to be an app that end users can install easily in corporate or non-corporate environments, and must not require any ongoing technical maintenance. I started to install SQL Express, but stopped when it required at least 2 system updates, as that will be far too complex for this开发者_高级运维 little app.

Jet has been deprecated but there's a replacement in the form of ACE (Access Database Engine).

However, regarding using it from LINQ. The answers to this question have various suggestions and I've also read somewhere that it might be possible to use LINQ to DataSet to do it. Here's a blog post about it: Querying DataSets – Introduction to LINQ to DataSet but I can't find the link to where I read that someone had had success in using it to access an Access DB.

I'd suggest though, that if there are no clear cut solution for using LINQ, the pragmatic approach would be to just stick to normal ADO.Net and wait with using LINQ until you're sure that you're using a datasource that supports it fully.

Here is a good upgrade tool that is free if your project contains less than 10000 lines of code:
http://msdn.microsoft.com/en-us/vbasic/ff793478.aspx

The general approach you should follow, is first a clean migration from VB6 to VB.NET, and get the .NET version to work exactly as it did in VB6, and then start to look for alternative technologies in .NET. It is easier to convert between different technologies when you have a working .NET application than to manually try to convert directly from VB6 code to alternatives in .NET.

Here are some good reasons to migrate first instead of a manual rewrite:
5 myth busting reasons for choosing automatic migration vs manual rewrite

From the article:

even in the worst case scenario, where you still need to rewrite a certain piece of the application after the automated migration phase, the end result will always be a fraction of the total cost and time.

Just use OleDbConnection / OleDbCommand / OleDbDataReader objects to mimic the same logic that you have in the VB6/ADO code. It will work the same way and not require any more dependencies than your existing app.

These may be of interest:

Which O/RM tool supports Microsofts Access? http://blogs.msdn.com/b/adonet/archive/2007/01/26/querying-datasets-introduction-to-linq-to-dataset.aspx