1. - The server side technology I show is ASMX services which is part of ASP.NET and has been in .NET since V1. So it'll work with any version of ASP.NET and IIS that it supports. Yes it definitely works with Server 2012 R2 which is what I use on my server. IIS has actually been very stable in terms of functionality since IIS 7 in Vista/2008 was released. The overall architecture and support of features hasn't changed very since. Things will change drastically in the next version of Windows though with .NET Core and Nano server in partciular. Neither of these technologies support Win32 or COM, but there will still be full versions of Server that do for the foreseeable future.
2. - No - The old MS SOAP Toolkit generated very funky WSDL and the structure is very likely to change. You might be able to create a WCF service that matches the signature by importing the service as a WCF service and then re-creating the service with the imported service contract. I've done this with a few services but it usually end up being a mess to work with. And it would be WCF which is more difficult to work with. Possibly - perhaps, but certainly not desirable. Reversion the service and keep both the old one and the new one working side by side with different endpoints.
3. - I don't recall that feature. Are you talking about generting a server or generating a client proxy? 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 ---
>Hi Rick:
>
>Tanks for the link, it is a fantastic white paper!
>
>I have just some questions about it, that I didn't found clear:
>
>1) When you talk about the server, does this apply to any server, even Windows Server 2012 R2 (64 bits)? Because with every new Windows version, Microsoft is taking out functionallity and backward compatibility
>
>2) If you have existent VFP9 COM+ components on the server, serving web-services with there WSDL files, is doable a compatible WSDL (even using .Net 4 "dynamic" featuer) for not needing to change clients that uses the Soap toolkit or MSXMLHttp 2.0?
>
>3) (Extra:) Do you remember the "Enterprise Services" of Windows Server 2003, that allowed the autopublishing of COM+ components using automatically generated .Net 2.0 proxy DLLs? Well, are the steps you explained in your white paper (specially "Accessing Data and Passing it to .NET" at page 36/37) the most close we can get for reusing those services?
>
>Very thanks!
>
>
>>
>>FWIW, I did a session on calling and creating SOAP services with .NET using FoxPro last year at Southwest Fox. The white paper is online here:
>>
>>
http://west-wind.com/presentations/CreatingAndConsumingFoxProWebServicesWithDotNet.pdf>>
>>+++ Rick ---
