DAO 3.6 missing in Visual Studio 2022 COM references

This is really strange: I have the good old Access 2002 installed, which I use a lot. I have some database utilities which were written in VS 2019 and which refer to DAO 3.6. All the exe and dll files do run without issues.

But after having Visual Studio updated to version 2022, I can't open these apps in VS 2022 anymore. It doesn't find DAO 3.6 and if I look into the COM references, I can see DAO 3.5 - but no DAO 3.6.

Anybody here who has the same problem? Or better ... a solution ;-)

DAO 3.6 is definitely correctly COM registered.

Hum, this is going to be "somewhat" of a problem.

The main issue is that vs2022 is the FIRST version of VS that is now x64 bits, and previous versions (like 2019) were x32 bits.

So, when you attempt to add a DAO 3.6 reference, it is not going to show up, since vs2022 is x64 bits, and thus it can't see the DAO reference.

Now, I could point out that using DAO from .net is not a great idea, since DAO (or ADO) for this matter are un-managed code (that means non .net objects).

If you don't have a lot of code (yet), then I strong suggest you adopt ado.net, and then use the oleDB provider. That setup will work, and work with Access databases rather fine.

However, you CAN use a direct DAO reference.

What you can do is use the office inter-op assemblies (there are ones for all office products from word to excel to Access).

So, from the project, go manage NuGet packages, and add the Access interop assembly for DAO.

This one:

And thus, you can now directly use DAO in your vb.net code, and do so even with vs2022.

So, code can look like this - we need the imports, so this at the top:

 Imports Microsoft.Office.Interop.Access

Now, you can write pure DAO code, say like this:

    Dim myDBEngine As New Dao.DBEngine
    Dim myCurrentDB As Dao.Database

    myCurrentDB = myDBEngine.OpenDatabase("C:\test\test444.accdb")

    Dim rstData As Dao.Recordset
    rstData = myCurrentDB.OpenRecordset("SELECT * FROM tblHotelsA")

    Do While rstData.EOF = False
        Debug.Print(rstData("HotelName").Value)
        rstData.MoveNext()
    Loop
    rstData.Clone()

Also, keep in mind that you now have/must force your project to run as x32 bits. You can't use ANY CPU anymore, since in the past, VS being x32 bits, when you hit f5, you wind up with an "in process" x32 bit running process. Now, hitting f5 will get a x64 bit program!!!

So, you have to force the vb.net project to x32 bits.

Hence this setting:

So, vs2022 can't see the non .net x32 bit objects anymore, but you can get around this issue by doing the above.

However, really, but really, I would consider using ADO.net, and thus you don't use nor deal with DAO and some un-managed objects in vb.net code.

Of course, it really depends on how much code you have, and if it is practical to change over to ado.net, and not use DAO anymore.

I should also point out that MS-Access since version 2017 does not require a DAO reference anymore, and the DAO object library is built into Access now. This is due to the change over from the original JET data engine, to now using the newer ACE data engine that ships with Access.

For the most part, while you don't thus need (or have) a DAO reference in MS-access, you still have use of the DAO objects in code, and that's fine and standard practice in VBA + Access code.

So, above is a way to get DAO into vs2022. However, as noted, I really don't think it is a good idea to use those un-managed DAO objects directly in vb.net code.

The better way is to setup a connection in your project to the Access database, and then use the ODBC or oleDB provider.