>My answers are inserted below each question.
>
>>Hello everyone!
>>
>>Due to Microsoft's announcement that VFP will not continue into the 64 bit world, our company has decided to begin researching moving our suite of applications (all written in VFP) to a .NET platform. We are planning on doing this over a period of years with the thought of doing as much .NET through VFP 9 (Sedna) as possible and then moving pieces at a time to possibly a middle tier business model instead of trying to build a new .NET application from the ground up. Our applications are heavy into COM and XML but still use VFP tables for all backend pieces. We figure SQL Server (and Express?) is the probable choice for backend down the road.
>>
>>Having said that, we are faced with a question of do we code in VB.NET (Is this soon to be VB 9?) or C#. We are wondering what the advantages and disadvantages of each are? We have found articles on the UT and elsewhere that do some comparisions but many if not all of these are from many years ago, so we don't want to be confused with old criteria that may not apply in the latest VS. So...
>>
>>We are particular looking for answers to the following questions:
>>
>>1. Currently we have 2 developers (soon to be 3 possibly 4). One is heavy VFP with a little VB.NET or C#, the other is heavy .NET with C# and a little VB/VFP. Obviously, The C# developer can help the VFP developer to learn C#, which is a consideration, but the third and fourth developers skill sets are yet to be determined. (We are going to be posting a classified on the job link soon, by the way). So is there a higher learning curve going say from VFP to C# than there would be from VFP to VB.NET?
>
>The learning curve could be the same or different. Each developer will learn differently. Are you more comfortable with curly braces and case sensitive or not? There is no clear cut answer to this.

I remember my prof a few years ago saying that it takes about two days to learn a language.

>
>>2. What can C# do that VB.NET can't (or is a lot more difficult to do) and vice-versa? We are under the impression that C# handles Web Services better but VB.NET is stronger in XML features.
>
>They are basically identical. They both compile to the same runtime and both expose features of the .Net Framework. How those are implemented and exposed to the developer vary. But in the end, the runtime functionality will be the same.
>
>>3. What is the market for C# developers vs. VB.NET developers. Will it cost us more to hire a C# programmer than a VB.NET programmer? And is it harder to find one or the other?
>
>My unscientific browsing shows C# developers cost more, but there are more jobs for them. I think it will be easier to find C# devs than VB, but either one should be plentiful
>
>>4. What about sample code and existing libraries and classes. Are more available for VB.NET than C# or vice versa, or are these probably about the same.
>
>They are the same. Libraries and classes can be used interchangably between them.
>
>>5. Are development tools on the same level for both or is one easier to develop in than the other. Our clients have come to expect enhancements and upgrades to happen very quickly due to the fact that we have been using VFP and have continued to release quarterly updates (not including maintenance releases) with usually over 100 new features and enhancements each. So, which language going forward will provide us a better ability to do so (RAD) or is there not really a difference?
>
>They both use Visual Studio. I think the VB team is doing a better job of creating a RAD environment, but others have disagreed with me. The way it works is there is a Visual Studio shell team that creates the shell, then the C# and VB teams use the hooks in the shell to extend it.
>
>>6. If we are going to be using the .NET hooks in Sedna to migrate our VFP apps gradually, will this be easier to finally change over to VB.NET than C#??
>
>No. The .Net hooks in Sedna just make it easier to interact with .Net components.
>
>>7. And finally, are there other factors we haven't thought of yet that may effect development going forward?
>
>You need to look very, very carefully at architecture. You design a .Net app differently than VFP. You should look at .Net 3.0, particularly WCF, over ASMX web services. You may want to contract with a .Net guru to get you started on the architecture.