>3. - I don't recall that feature. Are you talking about generting a server or generating a client proxy?

I mean the "Uses Soap" feature available on the IIS, inside the Virtual directory configuration.

This article explains it:
https://msdn.microsoft.com/en-us/library/ms973810.aspx

This simple thing allowed to automatically generate .Net Proxy DLLs for every VFP DLL you register on COM+, and updated a WSDL automatically to. A great feature without an actual equivalence on latest Servers.


> The problem with COM - and specifically FoxPro COM - is that FoxPro COM objects don't publish their entire type hierachy (VFP doesn't provide that info). So FoxPro COM Objects only include first level object members, but no nested type info which makes exporting from COM to any sort of proxy pretty useful for all but the most simple services that pass back simple values or single level objects (which very few services do).
>
>The steps I describe in the article are for importing WSDL into client side .NET proxies. Those proxies can include deep class hierarchy but they stay in .NET and are accessed from FoxPro via Interop (either native interop or wwDotnetBridge which allows more features). For server side the reverse runs into the problems I mentioned in the previous paragraph.
>
>If you're building a new server today I would think long and hard on whether you want to create a SOAP service. These days REST or Microservices using JSON are more in vogue as they make it much easier to create the necessary message structures from code. Generating the proxies isn't automated but it's a lot easier to match the simple object structures of JSON objects than the crazy potentially complicated types of an XSD based contract. The other advantage is that you can build your services with anything that can serve HTTP easily. So you can use tools like Web Connection, FoxInCloud, ActiveVfp etc. If you can avoid it I would skip the whole SOAP train and go that route - it'll make life easier both for creating and consuming the service.
>
>+++ Rick ---
>


Thanks Rick!