>I think this is more simple than that. You can create and consume web services today (VFP6) without CursorToXML and XMLToCursor. The Web Services toolkit does all the work of converting VFP component to a web service and consuming it. You don't have to do anything really. VS.NET and VFP will actually do it more automatically for you by doing all the ground work (please see today's answer to David)
>

Thanks - one down, and ony 1.544M to go...

>Now, having said that, the XML to Cursor functions will let you, among many things, interoperate and use the new DataSets to directly expose and bind data to controls in VS.NET. Gene showed this at DevCon and we will have white papers and documentation on how to do that.

>> I'm aware that we can publish a COM typelib to .NET - is there >something similar to express XML interfaces?
>
>The .NET model is an evolution of COM. The underlying concepts are the same. People will query the SDL file to understand the methods that are there. You will break clients if you delete methods. I've heard of much better versioning in VS.NET by attaching a version to the classes but don't have all the specifics. I will find out more about this and let you know more details in the future.
>

OK.

>>Secondly, will there be a way to fire up a VFP component, have it run to >completion, and then retain the VFP runtime environment (not so much the state >as the runtime engine itself, as IL would offer) between instances of VFP >services, where for some period in the life of the .NET application, there may >not be anything crying for VFP's runtime to be retained in the working set?
>
>I will have to refer to Calvin on this (he's on vacation). When I have the answers I'll follow up.
>

< Chuckle > His timing is good - drop the puppy off at DevCon, and head for the hills until the first few days have passed! < BEG >

Ed