Repository.OpenFile on QEAX repository

[Ian Mitchell]

Finally getting around to regression testing EA16 64 bit, and I'm stuck in a strange place.
Managed to create a 64-bit version of my Addins, and they run 99% OK with a QEAX repository- so I now need to explore the 1% of differences.

So I created a test app which can open the EAPX or QEAX repositories.

• Repository.OpenFile(<my EAPXfile.EAPX>) works fine, of course.
• Repository.OpenFile(<my QEAXFile.QEAX>) doesn't.

I get an error, I guess from EA.Interop.DLL , and an old message "Unrecognized database format...." then some stuff about enabling JET4, whihc I'm fairly sure I can't do any more with 64-bit EA. Even tried with the EA.Interop.DLL from EA 16, but it's the same as it always was.
Same error with a QEA file.
EA 16, 64 bit, Build 1604

Can anyone think what i've missed ?

[Paolo F Cantoni]

Hi Ian,

Have you tried with 1605, in case there's some difference in behaviour?

Paolo

[Ian Mitchell]

Good advice, Paolo.
But it didn't make any difference, calling EA 16 1605.
Looking at Task Manager, an instance of EA is created, but it's the 32 bit version.
All I'm doing is:
myEARep = New EA.Repository
myEARep.OpenFile(>file name.QEAX>)
...so there is nowhere I can say "open the 64-bit version of EA, not the 32".
I'm running from VS2022, with a Debug/AnyCPU .
Maybe I'll try with a totally stand-alone app.

[Ian Mitchell]

So even with a 'hello world' stand-alone .exe file, it still opens the 32-bit EA, not the 64.
Which is maybe what's saying 'I don't understand QEAX files', which is fair enough.
BTW - i'm running EA 15.2 AND EA 16 (64 bit), which otherwise seems to work just fine together.

@Sparx - can you advise on how to make sure that Repository.new calls the 64 bit version?

[wivel]

Hi Ian

Are you running both the 32 and 64bit version on the same machine? Or perhaps EA 15.2? A shot in the dark, but it could be a Windows Registry issue, that the COM/Automation interface is still registered using the 32bit version and not the 64?

Been a long time since i developed for Windows, but I too often had issues like that after deleting and/or updating COM/Automation Interface services.

Henrik 

[Ian Mitchell]

I am running both, so I guess it must be a registry thing.
But where?

[Geert Bellekens]

Usually it's the last one that has been installed that the registry points to.

Geert

[EXploringEA]

I think the issue relates to how you build your app - AnyCPU has rules which I don't fully understand!  It's neither one nor the other but supports large address spaces so will work with both 32-bit and 64-bit processes.

So what/how does it select which version to use when there are 2 valid options available defined in the registry i.e. 64-bit under HKLM and 32-bit under HKLM..WOW6432Node.

Rather than start going through docs I did a quick check on a machine that has both 32-bit and 64-bit versions of EA running.

The results were:

• Build app x86 uses EA 32-bit
• Build app AnyCPU uses EA 32-bit
• Build app x64 uses EA 64-bit

Guess in this case an AnyCPU app defaults to using a 32-bit version of EA.

So by using a 64-bit build for your app you are forcing the selection of 64-bit EA as Windows will know that a 64-bit process needs to use a 64-bit app, a 32-bit app won't work.

BTW:  If interested and want to look further (and have time to spare!) a tool I find useful is Process Monitor which is included with the free Microsoft SysInternals suite - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

If you run this app and set the filter to select on "Process Name" with the value "EA.exe" and then run your code you'll get a long list of entries, 10,000's within a second of EA starting up!   In the examples above you can see the version of EA launched depending on the application build.

Hope this helps.

Adrian

[Eve]

Usually it's the last one that has been installed that the registry points to.

Geert

This. There is only one that is registered with COM, and .Net references COM. If you want to ensure that a particular instance of EA is loaded when you create a repository then make sure that EA is the last one to have written to those settings.

[EXploringEA]

Hi Eve,

I was curious by your response as it wasn't what I expected. So being me, I explored further and yes as Geert and you state the EA Com Server registration is set by the last installation. 

If I look at the EA registry entries I see that the LocalServer32 value reflects the different versions of EA and hence when you create a new instance of EA it launches the version of EA relevant for the build so consistent with my test (let’s forget AnyCPU for the moment!). 

However, the InprocServer32 for both EA32 and EA64 entries is the value set by the last installation and references Interop.EA.dll.  However these files are identical for both EA32 and EA64.  So, does it matter which directory is referenced?  Or does Interop.EA.dll uses libraries that are bitness specific?  If so why not do COM registration for the products seperately?

It would be good to know especially since a difference could create an installation order requirement (more likely for developers than users) to ensure correct operation! 

Also, it would also help understand whether the initial issue that Ian raised relates to the App that calls EA (as I had assumed) and/or which version/location of Interop.EA.dll is used.

Your comments appreciated.

Many thanks

Adrian

[Ian Mitchell]

So which entry do I need to change? And to what?
Good that we have a definitive view from @Eve as to the existence of a correct answer, but it would still be good to know what it is! 

[Eve]

Re-install the EA you want automation to use.

I would expect running EA as an administrator to have the same result, but I'm not going to guarantee that.

[EXploringEA]

Hi Ian

In case it's useful I updated EA Installation Inspector (V7009) to highlight in green the currently registered COM server.

Adrian

[Ian Mitchell]

Just to wrap this up, Adrian is right - they key is how you build your App in Visual Studio:
- build as x84 (32 bit) and, if you have a 32- and a 64-bit EA installed, you'll invoke the 32-bit one.
- build as a 64 bit app (and remember, all the bits which it calls must also be 64 bit, but that's a VS thing) then you'll call the 64 bit EA.

Not helpful for automated testing, but at least both 32- and 64-bit EAs are accessible from our apps.
Thanks Adrian for solving  this one.