Jim, I agree with everything you've said. It obviously was a pure marketing piece aimed at promoting .NET at the expense of vfp. Why in the world they would consider "using the SOAP ToolKit along with VB 6 COM DLLs" instead of doing the same with VFP is anybody's guess. Did these people actually know anything about FoxPro??
On top of this Ken is telling us that VFP and .NET work great together and yet there are no case studies and a very fragmented set of white papers on the subject. You certainly couldn't tell .NET/.vfp. work great together from the re-written version of the Case Study. Ken mentions west-wind alot, but, from what I've heard from Rick Strahl in various postings, .NET interop with VFP leaves a lot to be desired. I am still waiting for Ken and company to come up with good Case Studies featuring vfp and good straight forward documentation on vfp/.NET interop...

>Hi Claude,
>I've had a closer look at the article and it leaves more questions than answers...
>
>Under "Situation"
>First and foremost, though certainly not clearly stated in the article, it seems to me that CDS opted for a "Microsoft Visual Studio .NET development system" solution because they wanted to and not because they 'had to'. The article fails miserably to enunciate this.
>
>The statement "While still using Visual FoxPro as a key part of the solution...", followed in the next sentence by the statement '"We have ported most of our clients over to SQL Server, there are a handful still using FoxPro tables,"...' will almost certainly cause confusion in a reader's mind. Is FoxPro still used only for that "handful still using FoxPro tables" or what?
>IF the intention was to state that Visual FoxPro is still a key part of the solution then what is the purpose of the second sentence cited above?
>IF, however, the intention was to communicate that Visual FoxPro is allowing them to simultaneously support users on either SQL Server or native FoxPro tables using the same code base then that would be something else again.
>
>Under "Solution"
>
>The statement "We also wanted to use the latest Microsoft technologies, which made the [Microsoft] .NET Framework a natural choice." has "wanted" as its operative word. Marketing-wise I guess it wouldn't be in the cards to declare that "Microsoft Visual FoxPro could easily have been used to accomplish the changeover (after learning the essentials of ASP.NET) but we wanted to ease our adoption of the lastest Microsoft technologies.".
>
>I wonder if anyone else is going to question the statement "We are amazed at how much a single developer can achieve in a short time using the .NET Framework. It's a truly incredible toolset." that is followed by a table showing an estimated 'number of months to build application' as 12 - 18 (est.)??? That's 48-72 man-months!! And, being "estimated", is the project even finished yet???
>
>I've just gotta believe that the transition could have been a much much shorter one but for the fact that they WANTED to get aboard the .NET train and used this project to get the necessary education.
>
>Under "Benefits"
>
>I'm way under-informed in this area, but the statement "...much faster than using our existing tools--we were considering a web wrapper around the FoxPro application, probably using the SOAP ToolKit along with VB 6 COM DLLs. That would have taken at least twice as long to build..." sounds highly dubious to me. Is "VB 6 COM DLLs" just a misprint?
>
>The statement "...and would have left us with our original code, based on a dated technology" is, to me, the major purpose of this article (it is, after all, a .NET promotional article).
>
>Ahhh! I see here that they are only "midway through the AM for .NET development process..". Interesting that they've already 'ported most of their clients to SQL Server...' yet they are only midway through. Was that porting a separate project in preparation for their .NET effort? How long did that take? was it a NECESSARY step to deploying their .NET.
>
>All in all the article remains, despite KenL's intervention, a back-of-the-hand to VFP and a glowing tribute to Visual Studio for .NET et. al.! Not to mention that what really happened, when, and why, is left to the determination of the reader.
>
>Jim
>
>
>>Thanks Ken. Is there a white paper that details this somewhere? And can we expect some good examples of this in Europa??
>>>>This is really kind of funny - I don't see a connection with any of the legacy vfp app. It says the dbf is being replaced with SQL and a web app and web services are being created with vs.net? How is the connection being achieved? Would it kill Microsoft to admit some web services are being created with vfp??? Or do you just mean they're still using vfp in the background somewhere and there's no integration at all? The whole thing is kind of confusing...
>>>
>>>They are using VFP COM DLLs objects being called from ASP.NET, and ASP.NET is being used for the XML Web services. This is the technique that we recommend and the way most solutions seem to be being built when XML Web services and VFP is involved. I think it is very rare to have XML Web services created with VFP without ASP.NET as a wrapper around the VFP DLL. Hanging a VFP DLL directly on HTTP via a VFP XML web service is not typical, maybe just FoxCentral.net is an exmaple which is not a typical VFP application. Having ASP.NET act as the XML web service and then calling the VFP DLLs offers far more flexibility and scalablity.