Manual installation of RemObjects SDK

Remoting SDK
1

I’m trying to get RemObjects SDK into source control since I need to support multiple versions of my application that was compiled with different version of library (9.7.115.1441 and 10.0.0.1485). This would allow me to:

  • rapidly switch between two version of my application
  • make initial setup of development environment easier

For that purpose I performed these steps:

  1. I backed up original installation files.
  2. I uninstalled RemObjects SDK.
  3. I added BPLs, DCUs, DCPs and optionally source code files to source control.
  4. I amended library path, since those files no longer reside in Program Files.
  5. I amended some keys in Windows registry:
    HKLM\SOFTWARE\WOW6432Node\RemObjects\RemObjects SDK\ServiceBuilder
    FullPath
    HKLM\SOFTWARE\WOW6432Node\RemObjects\RemObjects SDK\ServiceTester
    FullPath
    HKLM\SOFTWARE\WOW6432Node\RemObjects\RemObjects SDK (Common)
    FullPath
    HKLM\SOFTWARE\WOW6432Node\RemObjects\RemObjects SDK for Delphi
    InstallDir
  6. I manually registered assembly RemObjects SDK (Common)\Bin\RemObjects.SDK.CodeGen4.dll.
  7. I manually installed packages to Delphi IDE.

So far it seems to work fine, but I have a few questions:

  1. Do I need to install RemObjects.Everwood.RadStudio.XE12.dll as an IDE assembly? I’m not sure what does it do? I use Delphi 10.3.3.
  2. Do I need to register (RegAsm.exe) any other assembly than RemObjects.SDK.CodeGen4.dll?
  3. Is there anything else that the installer does, but I didn’t?
  4. Is there any official way to achieve my goal?
2

Hi,

this assembly is needed for DataAbstract wizard. If you are using only Remoting SDK, you can ignore it

you may need to register dll that were used in RemObjects.SDK.CodeGen4.dll i.e.

  • Elements.dll
  • RemObjects.SDK.dll

you should unregister RemObjects.SDK.CodeGen4.dll before registration. w/o it, some issues can be caught later.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /u RemObjects.SDK.Codegen4.dll

No, it isn’t designed for switching between versions dynamically

3

Thanks @EvgenyK for all the useful information you provided. The reason for switching to manual installation is that I’m getting my codebase ready for frequent releases of RemObjects SDK that you announced a year ago:

With RemObjects SDK as a part of my repository I will be able to support and build older versions of my application. I hope that other users will benefit from this technique.

At this point I really think that Delphi desperately lacks proper package manager like NuGet.

4

GetIt, Delphinus and the Delphi package manager are attempting to do a lot of that, but the situation is a complex one. .Net uses dlls and you can wrap your dlls in versions, then deal with a bit of dll hell by keeping only the version that is supported among all packages inside a program, or doing explicit binding via a config file, etc, etc.

But with Delphi that is compiled into a single binary you will need the different code versions (unless you start trusting dcus, bpls, etc) to be wrapped and deployed on some sort of package. Vendors use include files, switches and other items that could need to be setup on the IDE level, library paths and switches not at the project level so the complexity increases even more. Add to it that you will need not only code versions but also versions per IDE per “package”, run time and design time (which integrate to the IDE).

So I agree, its needed, but by just observing the progress of the existing ones on GitHub and GetIt on Embarcadero it is a LOT of work that probably they prefer to do in small increments and use the man power on other stuff.