2 seperate installs of Indy in the one IDE?

[Adam 5]

Hi,

 

I'm building my XE 12 development environment. Previously, I have just uninstalled Indy (that's packaged with the Delphi installer), and installed Indy separately. However I ran into issues with incompatibilities with Indy and DevEx. (All would work OK, but I could never install an updated version of DevEx without errors afterwards). 

 

I noticed on the notes listed on https://github.com/IndySockets/Indy/wiki/Updating-Indy#important-notes that LivePreview/EMSEdge will also be unavailable if I do the update, however the website goes on to say "You can use a separate installation of Indy 10 for non-LivePreview/EMSEdge projects. This has not been addressed by Embarcadero yet so Indy 10 upgrades and LivePreview/EMSEdge can co-exist."

 

However, I haven't been able to find any information on how I can have the two versions to co-exist. (My hope was to use the latest version to compile my Delphi projects, which require TIdSASLXOAuth2 which unfortunately doesn't appear to be available yet in the packaged version that ships with Delphi XE12.

 

Can anyone please point me in the direction of how to have both installed within the same IDE?

 

Thanks

 

Adam

[Remy Lebeau 1260]

 Multiple versions of Indy can't be installed in the IDE at the same time. You would have to maintain separate copies and switch between them on a per-project basis as needed.

Also, TIdSASLXOAuth2 is not in the master code,  it is still in a sasl-oath branch that hasn't been merged yet.

 

 

Edited March 6 by Remy Lebeau

[Adam 5]

Hi Remy.

 

Thanks for the clarification. I guess it's a spelling mistake on the Github website. "Can" probably was supposed to be typed in as "Can't"?  ;)

 

On a separate note, do you know if the sasl-oauth branch will be merged prior to the next Delphi release? This is the only reason I need to custom update indy, and it unfortunately restricts what other components I can use, and completely breaks my ability to install DevExpress updates once I do it.

 

Best Regards

 

Adam.

[shineworld 68]

I'm used to using a different Indy version in some programs.
I've left the official Indy of Delphi installation and I don't touch it.

In a project I add a sources\Indyxx path with the desired Indy version source code.
Usually this is a modified version of the current GitHub because I need to manage some base mechanism to adapt it to my embedded devices.

In the program options I added this path to Search Path:


Obviously I don't use IDE to place Indy components onto form but I've to create them programmatically.
At now building exe Delphi uses .\sources\Indy10 version file instead of Delphi native Indy.

 

[Remy Lebeau 1260]

11 hours ago, Adam said:

Thanks for the clarification. I guess it's a spelling mistake on the Github website. "Can" probably was supposed to be typed in as "Can't"?  😉

No, the spelling is correct. If you remove the preinstalled version of Indy then LivePreview/EMSEdge projects will break, but "you CAN use a SEPARATE installation of Indy 10 for non-LivePreview/EMSEdge projects" if you need to use multiple Indy versions.

11 hours ago, Adam said:

On a separate note, do you know if the sasl-oauth branch will be merged prior to the next Delphi release?

I don't have an ETA on that.  The code is pretty much done for now, but it is an interface change as there is an extra parameter added to the SASL login procedures.  And also, I don't have palette icons for the new OAuth SASL components yet.

[Adam 5]

4 hours ago, Remy Lebeau said:

No, the spelling is correct. If you remove the preinstalled version of Indy then LivePreview/EMSEdge projects will break, but "you CAN use a SEPARATE installation of Indy 10 for non-LivePreview/EMSEdge projects" if you need to use multiple Indy versions.

I don't have an ETA on that.  The code is pretty much done for now, but it is an interface change as there is an extra parameter added to the SASL login procedures.  And also, I don't have palette icons for the new OAuth SASL components yet.

Hi Remy,

 

Thanks for the clarification. I misread that in that there could be 2 consecutive installs of Indy. Thanks for clarifying. 

 

Best Regards

 

Adam.

[Adam 5]

20 hours ago, shineworld said:

I'm used to using a different Indy version in some programs.
I've left the official Indy of Delphi installation and I don't touch it.

In a project I add a sources\Indyxx path with the desired Indy version source code.
Usually this is a modified version of the current GitHub because I need to manage some base mechanism to adapt it to my embedded devices.

In the program options I added this path to Search Path:


Obviously I don't use IDE to place Indy components onto form but I've to create them programmatically.
At now building exe Delphi uses .\sources\Indy10 version file instead of Delphi native Indy.

 

Hi Shineworld,

 

Thanks so much for that suggestion. It's very encouraging to hear that this is possible. This would allow me to continue to perform DevEx updates as they come through, as well as use other components in other projects I don't have Indy, but also utilise indy and not have to switch to a different set of mail components!

 

I've given this a try. Just adding the indy10 directory didn't work for me. I was getting errors such as undeclared identifier TIdSASLXOAuth2 (which is a component in the branch I wish to use, but not available in the original install).

 

I then tried adding the paths to Protocols, Core and System, it compiles past this point, however I end up with a compile error of "Ambiguous overloaded call to LocaleCharsFromUnicode'" in idglobal.pas.  I was just wondering if you encountered that when you first started out and if you know what the solution might be?  I've added the Protocols, Core and System paths to the projects compiler search path, but just wondering if I'm missing a directory or step?

 

Like you, 

 

Thanks & Regards

 

Adam.

 

 

Edit: Please disregard. I managed to get this to work by prefixing the calls with "idGlobal." to specify to use the function contained in it's own unit. I'm now also going through this in a few other places, as well as getting rid of some IFDEFS and forcing the code for my version of Delphi to try and get it to compile. I'm guessing there's some conditional defines that work themselves out automatically if I was to compile the dpk's but of course that's what we're bypassing to have a dual install. My application now compiles, but the indy components don't seem to be have (just seem to do nothing after they attempt to connect, so I might be stuck with having to uninstall the Delphi ones, and commit to this build and not be able to get any future DevEx updates unless I completely reinstall the IDE each time). 

 

 

Edited March 7 by Adam

[Adam 5]

Looks like trying to install it seperately is failing too. I'm hitting the same problem again with ambiguous overloaded call to LocaleCharsFromUnicode, so I'm thinking the SASL branch may not be XE12 compatible. 

 

@Remy Lebeau - are you able to advise please whether or not the SASL-OAuth branch at https://github.com/IndySockets/Indy/tree/sasl-oauth is compatible with Delphi XE14 at this time? I'm only seeing up to Indy280.groupproj, and I believe Delphi 12 should be Indy290?

 

Thanks & Regards

 

Adam.

[shineworld 68]

I've missed saying that you also have to "disable" temporary the native Delphi Indy10 in the Browsing path:

 

I simply added a '_' char so it is fast to re-enable it with normal projects.


 

[Adam 5]

28 minutes ago, shineworld said:

I've missed saying that you also have to "disable" temporary the native Delphi Indy10 in the Browsing path:

 

I simply added a '_' char so it is fast to re-enable it with normal projects.


 

Thanks Shineworld, 

Nifty way to do it. At present I'm suspicious that part of my issue is that the branch I have hasn't been upgraded to work with Delphi 12 yet. I could be wrong, just waiting on confirmation first.

[Remy Lebeau 1260]

18 hours ago, Adam said:

I then tried adding the paths to Protocols, Core and System, it compiles past this point, however I end up with a compile error of "Ambiguous overloaded call to LocaleCharsFromUnicode'" in idglobal.pas.

...

Edit: Please disregard. I managed to get this to work by prefixing the calls with "idGlobal." to specify to use the function contained in it's own unit.

It should not be ambiguous.  Indy uses the LocaleCharsFromUnicode() function that Delphi provides in the System unit.  The IdGlobal unit defines its own version of that function only if Delphi's version doesn't exist.  So there should be no such function defined in the IdGlobal unit in Delphi 12.  If there is, then something is wrong.

18 hours ago, Adam said:

I'm now also going through this in a few other places, as well as getting rid of some IFDEFS and forcing the code for my version of Delphi to try and get it to compile. I'm guessing there's some conditional defines that work themselves out automatically if I was to compile the dpk's but of course that's what we're bypassing to have a dual install.

The DPKs don't provide the conditionals that Indy uses.  They are all defined in IdCompilerDefines.inc which is included by the individual .pas files....  OH, yeah, the branch wasn't up-to-date with the latest .inc file yet.

13 hours ago, Adam said:

Looks like trying to install it seperately is failing too. I'm hitting the same problem again with ambiguous overloaded call to LocaleCharsFromUnicode, so I'm thinking the SASL branch may not be XE12 compatible. 

 

@Remy Lebeau - are you able to advise please whether or not the SASL-OAuth branch at https://github.com/IndySockets/Indy/tree/sasl-oauth is compatible with Delphi XE14 at this time? I'm only seeing up to Indy280.groupproj, and I believe Delphi 12 should be Indy290?

I have updated the branch with the latest master code for Delphi 12.

Edited March 7 by Remy Lebeau

[shineworld 68]

10 hours ago, Adam said:

Grazie Shineworld, 

Un modo ingegnoso per farlo. Al momento ho il sospetto che parte del mio problema sia che il mio ramo non è stato ancora aggiornato per funzionare con Delphi 12. Potrei sbagliarmi, aspetto solo prima la conferma.

I'm some commits far from latest in Indy10 git repository but to work I've:

1] moved all files in folder from git project to be close on what I've found on Delphi 
2] changed the .inc to be close to Delphi originals



all work fine and I'm free to modify Indy to meet my "odd and old" protocols...

Edited March 7 by shineworld

[DelphiUdIT 132]

Why you don't use only the modified files along with yours projects (in a common repository for example) instead to porting all Indy environment ?

 

I use Indy from a long time and I never saw a big changes. I used in the past ( very past  ) to modify some IdAuto* protocols 'cause incompatibility with private Servers (MD5 bugged ... and stay bugged on their side).

Bye

 

[Adam 5]

5 hours ago, Remy Lebeau said:

OH, yeah, the branch wasn't up-to-date with the latest .inc file yet.

I have updated the branch with the latest master code for Delphi 12.

Hi Remy,

 

Thanks for updating that branch so promptly. That's greatly appreciated. I will update it my end.

1 hour ago, DelphiUdIT said:

Why you don't use only the modified files along with yours projects (in a common repository for example) instead to porting all Indy environment ?

 

I use Indy from a long time and I never saw a big changes. I used in the past ( very past  ) to modify some IdAuto* protocols 'cause incompatibility with private Servers (MD5 bugged ... and stay bugged on their side).

Bye

 

Hmm... if I can do that, this would be definitely the best way to go. I'm not sure whether the SASL components are compatible with the version that comes with Delphi (if additional parameters are required or not). If I could just add the OAUTH/SASL, and leave everything else alone - that may allow me to keep all the existing components that are normally removed when updating Delphi, along with being able to do DevEx updates in the future - which would be ideal!

 

 

Thanks for the suggestion!

[DelphiUdIT 132]

I think @Remy Lebeau is working on repository branch of SASL-OAuth. 

 

UPDATE: I updated this repository in Rad Studio and TLS1_3 is working, an also the OAUTH2 is available on the component palette. Waiting for @Remy Lebeau news.

 

Edited March 7 by DelphiUdIT

[Adam 5]

OK - an update. I was unfortunately not able to get Indy to work just by including the changed units that I needed for oAuth. It seems that the changes go deep right back to the idpop3 unit, which is pretty much integrated throughout a lot of Indy.

 

What I did manage to do however was uninstall and remove Delphi's Indy, and replaced with the latest Indy, and get DevEx installed afterwards. It requires having access to DevEx path in the library for builds so that it rebuilds the units relating to Indy. Some components had to be dropped - but I think this will get me out of trouble, and hopefully allow me to keep updating DevEx on Windows 12 moving into the future. 

 

It would be good though to have SASL-oAuth officially distributed by Embarcadero in their future releases of Delphi. That would allow me to use all the components accordingly.

 

I think the idea of just using individual indy units for what has changed would work well for minor changes, and possibly bug fixes, but unfortunately the SASL being so involved appears as though it's not a possibility in this instance.

 

Thank you to everyone who has kindly taken the time out of your day to reply and assist me with all this!

 

Adam.

[DelphiUdIT 132]

3 hours ago, Adam said:

Some components had to be dropped

What components were dropped ? I replaced totally Indy without any issue, restoring also the IDE functionalities.

I think that DevEx (if it recompile the units) should no have issues.

 

Edit:

I tested quickly the old project that use the IdSmtp, IdTCP, IdFTP, IdHttp all with SSL and were no change on compilation. I don't use IdPop3.

Edited March 8 by DelphiUdIT

[Remy Lebeau 1260]

19 hours ago, Adam said:

I'm not sure whether the SASL components are compatible with the version that comes with Delphi (if additional parameters are required or not).

The new OAuth SASL classes are not compatible with the pre-bundled Indy version. The sasl-oauth branch contains some interface changes, to add an APort parameter to the SASL process.

19 hours ago, Adam said:

If I could just add the OAUTH/SASL, and leave everything else alone...

Unfortunately, not.

[Remy Lebeau 1260]

13 hours ago, Adam said:

I was unfortunately not able to get Indy to work just by including the changed units that I needed for oAuth. It seems that the changes go deep right back to the idpop3 unit, which is pretty much integrated throughout a lot of Indy.

More accurately, there are some interface changes to the base TIdSASL class and the TIdSASLMechanisms class, which affects several Indy components that use SASL, including TIdPOP3, TIdSMTP, TIdIMAP4, and TIdDICT.

13 hours ago, Adam said:

It would be good though to have SASL-oAuth officially distributed by Embarcadero in their future releases of Delphi.

Yes, but that's not going to happen until the branch is merged into the master code.  Embarcadero doesn't ship branched code.

[Remy Lebeau 1260]

10 hours ago, DelphiUdIT said:

What components were dropped ? I replaced totally Indy without any issue, restoring also the IDE functionalities.

Yes, but you did that using Indy's master code, which only had bug fixes and new package files.  Try it again with branched code that has interface changes in it, and you may have a different result.

[DelphiUdIT 132]

34 minutes ago, Remy Lebeau said:

Yes, but you did that using Indy's master code, which only had bug fixes and new package files.  Try it again with branched code that has interface changes in it, and you may have a different result.

I used the last update branch (SASL-OAuth) yesterday night.

[Adam 5]

On 3/8/2024 at 6:29 PM, DelphiUdIT said:

What components were dropped ? I replaced totally Indy without any issue, restoring also the IDE functionalities.

I think that DevEx (if it recompile the units) should no have issues.

 

Edit:

I tested quickly the old project that use the IdSmtp, IdTCP, IdFTP, IdHttp all with SSL and were no change on compilation. I don't use IdPop3. 

I had to disable the LivePreview package, along with some DevEx packages, such as SchedulerWebServiceStorage, CloudServiceLibrary, MapControl, and a few others. 

 

I'm pretty sure this (especially the livepreview) comes down to dcu/bpl's being compiled with a different version of <indyunit> than what is now currently installed. In DevEx's case, it comes down to procedure entry points not being able to be located.  I get what you're saying - with DevEx it should (and does) recompile the units when it installs. For some reason these last few don't seem to work. (Possibly not all the source code is included for those, I don't know?)

 

It's been unfortunate but over the last couple of Delphi versions I've given up on being able to have both. DevEx won't support any Indy installs except for the one packaged with Delphi when it ships. Since my apps require what's in the SASL-oAuth branches, I have no options except to either ditch using these incompatible packages, or to ditch Indy.  So far I've been able to avoid those other components and stay with Indy, but it's getting harder, since components that use Indy don't support patching Indy to the latest version, and from what I can tell, Embarcadero doesn't include Indy updates with their patch updates. (Although even if they did - in this case with sasl-oauth not being merged in, it wouldn't make a difference at this point anyway). 

 

I have no idea how you managed to replace indy totally without losing (at least) the livepreview that comes with Delphi. (I'd hate to guess how many weeks in total over the past couple of years I've spent trying to get this to work over the past few Delphi installs I've done)., and have never been able to achieve what you have. (Plus, according to Remy it seems like he's suprirsed you could do it too)?

 

For now - I have what I need - the updated installed and the ability to update DevEx (as long as those other packages aren't needed). Thanks to everyone who's helped and taken the time out to reply.

 

Who knows... maybe the next version of Delphi will be my lucky build where the included Indy components contain all I need and I don't need to go through this again, and 13 will be my lucky number. 😁

Edited March 12 by Adam

[esegece 46]

If you want to compile the latest Indy package with Devexpress installed, you should do some changes, there is a post in the devexpress website which explains this:

 

https://supportcenter.devexpress.com/ticket/details/t421126/installation-with-updated-indy-components

 

Additionally, I wrote a blog post a month ago about how install the sgcIndy package installer and Devexpress:

 

https://www.esegece.com/community/blog/sgcindy-devexpress

[DelphiUdIT 132]

25 minutes ago, esegece said:

If you want to compile the latest Indy package with Devexpress installed, you should do some changes, there is a post in the devexpress website which explains this:

This is right if you want maintain the full compatibility with Embarcadero and all third parts packages.

But this is not all, you must set also the $LIBSUFFIX to "AUTO", because the BPL packages should be named with "290" version. Indy packages in the repo are not set for this, there are some "ticket" open (and "closed") about this.

 

I wrote some posts about substitute the original Indy and restore the compatibility with Embarcadero environment, but after last changes in Indy repository I will rewrite again a full post with all steps in simply mode including openssl indy repo and ssl-oauth indy repo, possibly via script.

[Remy Lebeau 1260]

5 hours ago, DelphiUdIT said:

But this is not all, you must set also the $LIBSUFFIX to "AUTO", because the BPL packages should be named with "290" version. Indy packages in the repo are not set for this, there are some "ticket" open (and "closed") about this.

The ticket is not closed: https://github.com/IndySockets/Indy/issues/133