Hi Nancy,

The project has not been given to me yet although I may yet get a piece of it. It is quite small but who knows, it could grow as they usually do but budget considerations are driving it for the moment. The client has actually decided on .NET and the person to who I'm contracted to has asked that I write a white paper to support their decision and/or to least point out any obstacles to using .NET.

Thanks,
Steve


>Stephen-
>
>The others have offered you some great suggestions. Even if you only skimmed McNeish book, it would be well worth an hour of your time for getting a sense of the comparison.
>
>I have an additional comment to add to the others. IMO VS.NET and FoxPro are as different as a router and a drill. Both are critical tools, but they do different things. What I find is that the situation will dictate the choice of tool. Rarely are there situations where I could substitute one for the other.
>
>Since most developers have given themselves over to the siren song of SQL Server (or Oracle) *g*, I'll stick up for the biggest, most critical difference between the two tools is the native data engine, or lack thereof. When the situation is appropriate for it, there isn't much that beats the nicely simple (KISS, right?), really powerful, and terrifically useful FoxPro data engine. Being able to directly grub around in data is very useful for a data wonk.
>
>OTOH, when you use VS.NET you will also have to consider what data engine you'll use. One choice, of course, is FoxPro. However, it's more likely you'll want to use a DBMS, and there will be a cost associated with that. So, your comparison might be between FoxPro and ASP.NET + Oracle.
>
>I'm working on a project right now that is building an ASP.NET front end to a legacy Visual FoxPro application. (Luckily, it's not a massive e-commerce site!) I wouldn't, today, build an web-enabled application based on a FoxPro application. Strahl saved the community for years with Web Connect, and I'm nto dismissing his contribution (btw, he has a framework for ASP.NET commerce applications now), but it's not the best choice, IMO, today.
>
>>In VFP most of us have developed a set of class libraries based on VFP's native class definitions. I'm sure that in .Net one would do the same but how does one go about it.
>
>First, there is subclassing. Keep in mind C# is a brand-spanking new language. 100% OOP-oriented (ha). So, you get subclassing, interfaces, all sorts of wonderous things. IOW, anything OOPy Fox does will be doable in VS.NET. However, as is mentioned elsewhere, there are 2000+ classes, so there isn't quite the same need.
>
>>How good is the .Net IDE? Any real obstacles when doing development, especially for forms, compared to VFP?
>
>I like it fine. Syntax coloring, visual or code views, debugging, watch points, so on. There's so much it's a little daunting at first, IMO.
>
>>Anyway, you begin to get the idea. It is not a full comparison of the languages but I do need to find out about the good, the bad and the ugly about .Net. I've always managed work-arounds to problems in VFP so I need to know if .Net is just as good.
>
>Er, just as good at having problems or work arounds? *g* Work arounds aren't really about the tool, it's about developers, so, I'd say, yeah. There are lots of people using it, so lots of information about how to use the tool and work arounds.
>
>Maybe if you told us what sort of project the comparison is being used for (if there is something specific) we could provide some more specific information about what we've found out.