Deleted the original version of this post as I posted under my boss’ name account info (which has the registration tied to it) rather than mine.
Setup:
Delphi 10.2 update 3
RemObjects 10.0.0.1471 (though the problem occurred in 9.4.109.1377 as well)
I have an existing application relying on an internal library that in turn relies on RO. I’ve been having problems (and a co-worker has as well, though we have basically identical setups, so there’s no surprise there) compiling the end application. This particular application can be compiled 32 or 64 bit and the problem only occurs in 64 bit.
The actual error message is: F2051 Unit uRemotingService was compiled with a different version of uROIndyHTTPChannel.TROIndyHTTPChannel
We’ve been using D10.2 for quite some time and only upgraded to RO 10 to attempt to solve this problem, which cropped up recently. RO 10 was installed recently, so obviously compiled with my Delphi version (ie mismatch should not be a problem), I’ve compared compiler settings for 32/64 in all the projects and see no differences, I’ve compiled RO 64 bit via the IDE (minus Core which throws an error when I try and compile that) though it should not be necessary as RO compiles during install, and I’ve checked for extraneous DCUs/cleaned the projects/deleted the DCUs/etc multiple times.
One extra piece of info that might help diagnose this is that when I compile applications that use RO a large number of RO DCUs end up in the applications DCU folder but none of our other libraries (open source, commercial or home grown) have that problem. I have at least 70 uRO*.dcu files in my DCU folder. That all being said, compiling 32 bit does the same thing and the above F2051 error does not occur when compiling 32 bit.
Does anyone have any guidance on what the solution is or where to look further to solve this?
My colleagues will have more insight in the morning, but generally this points to a .DCU mismatch; you have a uRemotingService.dcu that was build against a different (older?) of uROIndyHTTPChannel.dcu than the one you are using right now. I’d make sure that your search path doesn’t include multiple copies of the RO SDK .dcus in different folders (or that it includes the source), and check all the DCUs match (possibly rebuild em from source).
also you can reinstall ROD and specify to compile Win64 dcu files:
it will compile ROD dcu and put them to C:\Program Files (x86)\RemObjects Software\RemObjects SDK for Delphi\Dcu\D25\Win64 folder
I did have the RO source on the library path, mostly (IIRC) because compiling my generated *_intf.pas files requires access to RemObjects.inc and eDefines.inc and those are in the source folder for RO.
Is there some better method to make the *.INCs available to Delphi for my code other than adding the RO source to the library path that I’m missing? Anyway, I copied the INCs out, put them in a new folder, added that to my library path and removed RO’s source folder from the library path and I still have the same problem.
I have (previous to asking for help) used VoidTools Everything to search for uROIndyHTTPChannel.* files to be sure that I did not have extraneous DCUs around and while every RO based application has one (or two, from 32/64 bit) DCUs for used RO units, that’s from the application compilation creating them. I have, however, deleted all extras (ie leaving only in RO\DCU\Win32 or Win64) and built everything and still have this issue.
Please see my reply this morning to Marc about things I’ve tried this morning.
I have/do routinely not only do a build instead of compile during this debugging, but also have many times deleted all DCUs for my libraries/applications (minus RO generally). I uninstalled RO yesterday and installed the latest release (10.x) and during install asked it to compile Win32 and Win64 as I was (at the time) assuming that my using Delphi 10.2 update 3 was the problem (that maybe your installer included DCUs from an older compiler).
None of that has had any effect on the problem.
I will add that after the changes I mentioned to Marc this morning that now my application will no longer compile Win32 either.
Setup of full version doesn’t contain any .dcu/.dcp - they all are compiler on your computer from .pas during installing of ROD/DAD.
By default, setup adds Dcu\D25\Win32 prior Source folder into Library path so compiler should use .dcu files in Dcu folder before using .pas files in Source folder:
C:\Program Files (x86)\RemObjects Software\RemObjects SDK for Delphi\Dcu\D25\Win32
C:\Program Files (x86)\RemObjects Software\RemObjects SDK for Delphi\Source
the same applied to Win64.
if you uninstall ROD, remove all entries to RemObjects SDK for Delphi in Delphi Library path and reinstall ROD, will it solve your initial issue?
By default, setup adds Dcu\D25\Win32 prior Source folder into Library path so compiler should use .dcu files in Dcu folder before using .pas files in Source folder:
C:\Program Files (x86)\RemObjects Software\RemObjects SDK for Delphi\Dcu\D25\Win32
C:\Program Files (x86)\RemObjects Software\RemObjects SDK for Delphi\Source
the same applied to Win64 .
It’s possible I fiddled with the order while trying to make this work, so that makes sense.
I uninstalled RO, reopened Delphi and removed all RO related paths, edited the system path and removed all RO related paths, deleted everything in Program Filed (x86)\RemObjects Software\ and reinstalled, choosing only my Delphi version (10.2) and Win32 and Win64 DCU compilation. After install, the paths were as you said they would be (source after DCU). Win32 compiles again, Win64 still does not.
However, and this is probably a big clue, when compiling the application 32 bit despite the source path being after the DCU\D25\Win32 Delphi compiled all of the used RO units into the application’s DCU folder (at least 71 of them). Compiling my application Win64 also results in RO DCUs in the application folder, but a compiler error as well.
It seems like the wrong Delphi version is compiling the RO units somehow, but I only have 10.2 on my machine right now. It seems like Delphi doesn’t think the DCUs are current (or maybe not correct) and is causing it to force a rebuild of those units. I’ve never seen anything like that before, nor have I seen any discussion about that happening.
This is my current list of uROIndyHTTPChannel.* files. You can see that the DCUs in C:\Code are compiled after the the DCUs in Program Files.
try to play with debug/release configuration of your app.
Installer creates release version of Dcu in win32/win64 folder.
in your case, .dcu in Code folder have bigger size so it can be debug version…
as a result, perform Project->Cleanup (it should remove all .dcu) , set release configuration and compile files again.
However, I have found a work around. It’s not really how I want it working, but I am able to compile my application both as 32 and 64 bit.
I opened RO MegaDemo and found it could compile 32 and 64 without a problem. I also found that if I added uses statements for my library classes (RO base classed in a Delphi package) it would cause MegaDemo to fail to compile just as my app would. I found that if I add the unit that failed to compile (which always contained a class that derived from some RO class) I would progress past that class to another, which would fail as well. I followed that path until the failures stopped and ended up with 4 units from one of our internal libraries added in to my application and the application compiles. This is definitely not preferred, so if you have any suggestions, I’d love to hear them, but I can live with it.
As additional information:
First, I ended up removing (after the fact of making the application compile) the RO source folder from the Delphi Library path. If I don’t, I end up with the same 71 RO DCUs in my application DCU folder, which makes compilation take much longer than normal. So, there’s definitely something still wrong.
Second, and I can’t see why this would be a problem, we have a large number of internal/homegrown libraries with various code/classes/etc (and have had most of them 10+ years). One of them is a set of helper code for various RO classes/functions as we use them (and have had these for 18 months or so). Another library is the client side code for our internal logging system, and recently I added RO support as a logging mechanism (previous logging comm methods were simple UDP and/or a shared memory region). The logging library is of course used in all applications, but this is the first time it’s being used with RO derived classes in it. We do have other library setups similar to this that work without a problem, though, so I’m not sure there’s any significance of this.
Glad to hear that you have found a reason for such failure.
can you create a simple testcase that reproduces this issue with x64 compilation, pls?
we will be happy to investigate this case.
you can send it to support@ for keeping privacy.
have you recompiled your internal units after installing a new version of ROD?
Final solution (not ideal because will compile every time sources) is adding all the RO/DA source paths to Delphi.
That’s where I started from, but that left me with my original problem. The problem seems to be DPKs that are dependent on RO. I’m not sure what the root problem is because we have other packages that depend on RO without having this problem.
Who created that dpks? Are the source files needed fr this dpks also in the library path? If your coworkers have another source versions will never work as expected.
