IndySoap lives Again

Many years ago, I wrote an web services library for Delphi called “IndySoap”. It took a WSDL and generated delphi code that could then be used to implement a client or a server, and was published as open source. For me, it was a real learning process, both in terms of http, xml, and web services, and also – because we dynamically generated machine code, and I thought that was risky  – we wrote a very thorough test suite. It was my first exposure to TDD.

A couple of years after it matured, a new version of delphi was released that changed the base string type from pure ansi (byte = char) to full Unicode. I tried to update IndySoap for that, but was stymied by some weird problem in the compiled code that I couldn’t figure out – and I got very few requests for a unicode version anyway. So IndySoap moved into the background – something I used for remote procedure invocation and interoperability, but gradually to be phased out as people switched over to REST – REST really is much simpler, and even the services built using “REST” are simpler than simple SOAP, let alone SOAP in it’s full glory.

Then, a couple of months ago, an IndySoap user with a depth of commitment to the code and with an architecture built on it contacted me and asked to me to update the code for the latest version of Delphi, and laid money on the table to make it happen (thanks).

So today I’m glad to announce a new version of IndySoap has been released through SourceForge ( This version compiles and passes all tests under both Delphi XE3 and Delphi 5. Versions of Delphi prior to Unicode should still be supported, and XE2, and probably XE4.

I don’t know how many people are still using SOAP, but IndySoap still has the same advantages it always offered over the out of the box Delphi choice:

  • Runs on any version of Delphi (not just the expensive ones)
  • Much more flexible and manageable than the Delphi one
  • Much more thoroughly tested, and easier to fix (instant fixes, no waiting for an overloaded programming team to get to fix old issues)
  • Deeper support for the web services stack (extending the web service stack is the #2 voted request for Delphi… IndySoap doesn’t have them but they can be added)

The old functionality tests we wrote were a wonderful aid to updating the code to use Unicode. There’s so many places where that could go wrong, and the functional tests made such a big difference. Long Live TDD (and, btw. down with SOAP!)

I’d like to thank Server Informatica for sponsoring the IndySoap work.





  1. Ian McNicoll says:

    Hi Grahame,

    Wow – what a small world. In a previous existence I wrote an accounting program for GPs in the UK which is still going strong and made use of IndySoap until the native Delphi VCL components caught up. Glad to hear IndySOAP is still alive. Thanks for a great piece of work which definitely saved a few of my brain cells.


  2. Hi,

    I am trying to connect a Delphi program with a webservice, generating the pascal code to interface with the webservice using IndySoap 2.0 SoapTools, but get the following error:

    IdSoapITIBuilder.BuildITI: You must specify a Valid BinOutput or ResOutput file.

    I just can’t figure out what is wrong.

    Could you please point me in the right direction?

    btw. I have been writing Delphi code since Delphi 1.0 when it took over for Visual Basic 🙂


    • Grahame Grieve says:

      In the ini file that manages the generation, you must have an entry in the [output] section


      one or both must be present, so that the convertor knows where to put the generated resource. this contains additional data about the exchange that isn’t implicit in the RTTI. Then you load that using the settings on TIdSoapITIProvider

  3. Bob Devine says:

    Hi Grahame

    First, thanks for this – it looks like it might be just what I need for some unavoidable SOAP work.

    I’ve got it installed in XE3 and can run the KeyServer example but I’m having trouble building a .res file for the ITI using the tools app. If I use ResOutput=$filename in the IdSoapCfg I get an AV in the tools app and if I use BinOutput=$filename I get a message about an invalid 16bit resource.

    I notice the source for the tools app is missing from this version – is it available?

    Thanks, Bob

  4. Bob Devine says:

    Hi Grahame

    I’ve a question about the wsdl -> pas generator. I’ve joined the yahoo group – is that a more appropriate pace to ask questions?

    I’m using a slice of the ACORD xsd but have a problem with the following:

    Where it’s raising the exception “Element reference “Policy” does not have a namespace. From the source it seems to be expecting a namespace qualifier in front of Policy.

    Policy is defined as

    Am I missing something in the settings? The Delphi wsdl importer generates code ok from this xsd (but of course isn’t Doc|Lit). I can always try and massage the Delphi code into IndySOAP, although if you’ve seen the ACORD xsd you’ll know how painful that looks…

    Thanks again, Bob

  5. Grahame Grieve says:

    the blog swallowed your xml. but yes, take the conversation to the yahoo group

  6. Jean-Francois Barbeau says:

    Hi Grahame,

    Is this available for 64bit projects? It seems to compile properly in 32bit, but the 64bit projects do not seem to like the assembly language used in IndySoap!

  7. Dennis says:

    After days of researching/trying/banging head against walls/tables/etc whilst trying to get Delphi 10 internal SOAP service implementation running: is your library able to create doc|lit (NOT rpc encoded) web services even for picky java clients? Regards, Dennis

    • Grahame Grieve says:

      yes, at least, in principle. However there are many things that doc|lit servers can do on the wire that are way beyond the scope of an xml|object mapper, so it depends on the document schema

  8. Dennis says:

    Sounds great. We have a simple service but need to present it as doc|lit. I’ll try it the next weeks and report back.

  9. TheCocce says:

    Hi, I tried with Delphi Berlin version and the 64bit ASM keyword raise an error during compile on some classes like TIdSoapDynamicAsm.Execute.

    Embarcadero says:
    Mixing of assembly statements with Pascal code is not supported in 64-bit applications. Replace assembly statements with either Pascal code or functions written completely in assembly.

    Any plan to port asm code?


  10. Rafet Sapancı says:

    Hi Grahame

    I downloaded the soap library, downloaded from the above address,
    I am installing with version of Delphi Tokyo. Installation for 32bit windows is being completed with some warnings. But when the vcl is added to the design screen from the soap components, it gives a compilation error.

    For 64bit windows, bpl compiled, IdSoapTracker.pas file on line 114 gives the following error.

    [Dcc64 Error] IdSoapTracker.pas (114): E1025 Unsupported language feature: ‘ASM’
    [Dcc64 Error] IdSoapTracker.pas (114): E2029 ‘;’ Expected but ‘ASM’ found

    For “Delphi Tokyo”, you could check the soap library for x32 and x64.

    Thank you

  11. TheCocce says:

    Hi, i download SVN version from

    Is it correct?

  12. Rafet Sapancı says:

    Hello there

    I tried the SVN version.

    Method 1: Set up the SVN as downloaded. Delphi version “Tokyo 10.2”
    Some warnings appeared in the component installation, but the installation is complete.
    When adding one of the indysoap components on form,
    Library path “\\indySoap\Source” was defined in the library but give an error.
    As the reason for the error, the compiler directives might be missing.
    I used the following method 2 for him.

    Method 2:

    Added directives for “Delphi Tokyo” in The installation was again completed with some warnings.
    Any indysoap component was added to the form.
    The project was compiled without writing code.
    He gave the error shown on the link below. — Add SoapClientTCP and press F9 — given this error

    Below are the additions made in
    Add this lines

    //Delphi & CBuilder XE3 (Waterdragon)
    {$IFDEF VER240}
    // DCC is now defined by the compiler

    //Delphi & CBuilder Tokyo (Godzilla)
    {$IFDEF VER320}
    // DCC is now defined by the compiler


    // end FPC


    {$IFDEF VCL_XE3}

    {$IFDEF VCL_XE3}

    {$IFDEF VCL_XE2}

  13. Henrik says:

    Hi Grahame!

    I am also trying to use this library in a 64-bit application – I am using the latest version from the SVN repository!

    However, I also run into the same problems as someone else in the comments here:

    (‘TIdSoapDynamicAsm.Execute’ – [dcc64 Error] IdSoapDynamicAsm.pas(343): E1025 Unsupported language feature: ‘ASM’)

    Is there support for 64-bit compilers using this library? 🙂

    Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen


%d bloggers like this: