>Now the question:
>
>Why not use the Toolkit? I'm seeing a number of people say things like "I only want to use *pure* .NET - as if user created function and class libraries aren't pure .NET". I never saw people in Fox/DOS days say "I won't create my own CityStateZip function because it's not pure Fox".
>
>What's wrong with domain specific functions and classes?

I guess the answer is mostly philosophical. Unless I am mistaken, the primary purpose of the toolkit is to provide "Fox like language support" to .NET development - mostly to help VFP developers make an easier transition. For me, at least, I prefer to make a clean break with the past (VFP). While I'm all for nicely wrapped functionality explicitely mimicking VFP to accomplish it pays too much homage to a legacy I'm quite willing to leave behind. I want my developers to learn .NET (and in our case - C#), not just write "VFP code" and compile it differently :-).

Now - there are probably classes in the toolkit that make perfect sense to use, borrow from, etc. regardless of their heritage. In that case, I am very willing to use them or write similar wrappers. I will certainly be going through it in detail to make these decisions - and as I've pointed out, to help in the learning curve as needed.

Finally - the current "marketing" that seems to be pushing VFP developers to use .NET langaguge/tools based on their similarity to VFP simply has no appeal to me. If I want to write "VFP like" code, I will simply write in VFP. I am drawn to C#, because it seems much "cleaner" than VFP or even VB .NET. I don't know how to phrase it other than that.

Thanks for your question. If I've misinterpreted the toolkit's pupose, please correct me.