>>We are a FoxPro 9 shop that needs to move to C# or we could lose our contract with our one customer.
>>
>>I know C#, but am a beginner. I've written a number of ASP.NET apps and my first one was in 2003 and I wrote my own Data Access Layer using old school command object, parameters, datasets, datatables and datarows. It was a lot of work.
>>
>>Sine then I've used Mere Mortals and have enjoyed the fact that the BO Generator writes the DAL and the fields in tables become strongly typed class fields/properties and the Intellisense kicks in.
>>
>>And I've been studying the new EF in .NET Framework 4.0.
>>
>>So, in our programming meeting yesterday I was demo'ing LINQPad and the whole concept of LINQ. Well, practically everyone flipped out saying it was too hard and that they wouldn't have time to learn it. Well, for starters none of them even know C#, so they've got a huge learning curve ahead of them regardless.
>>
>>Then the manager stated that we wouldn't use LINQ and instead we would resort to old school using SQL. Well, the manager doesn't know C# either, but his philosophy was "we all need to be able to support each other's applications" and we need to keep it simple enough to that if you get hit by a bus... I call this the least common denominator mode of team programming.
>>
>>But, I truly believe that old school "SQL" with command objects, datasets, datatables and datarows and all that code is way more difficult than EF and LINQ. In EF you set your new values and then call SaveChanges. I don't know what's easier than that.
>>
>>Opinions?
>
>I've read a lot of the responses. I may have missed a few messages but based on what I've read so far, what strikes me most in your specific situation is:
>
>1) multiple inexperienced programmers (weak on current dev tool and totally lacking knowledge of .net)
>2) Short time period for re-write in C# (you wrote ASAP)
>
>Is your company going to foot the bill for training at least? Are they expecting to write all apps quickly and accurately and have inexperienced programmers support them? How soon is ASAP? Do you have a deadline? Is someone planning a release schedule? Do some apps rely on others or call others and can you do the re-writes in a logical progression or perhaps change out the UI and leave some VFP data crunching in there for a while until the entire pack is rewritten? Ideally do it right from the ground up entirely in .net. What are your options for delivery?
>
>Your comments about do...while and scan...endscan and linqpad being frightening worry me. Based on your responses I've read so far (not the recommendations by others because I've read a lot of good ones but those may not be options for you), you may only have a couple of viable options if you have a deadline less than 1 year or 2 years (better). A good foundation and approach will serve the company best for all apps and future apps. Future apps will go much faster after everything is in place. That means design and layers be handled correctly up front and the time taken to do that. The first app will go slow, but the rest should go quickly. Otherwise your options are:
>
>1) You need AT LEAST one experienced developer in the route you choose and time to train. Buy a GOOD RAD tool/framework and train developers on it and let go of the rest who can't learn and hire more experienced developers when budget allows.
>2) Contract it out (at least the layers and architecture to get you started) to an EXPERIENCED AND PROVEN group and support the finished product after training or at a minimum pay for some mentors (there are a couple good ones here on the UT and elsewhere who work as contractors and who have real well designed working business apps out there now) to assist you in the design and development. That doesn't mean hire a MSFT employee (been there and done that) but someone who has well-designed and written business apps IN USE IN THE REAL WORLD with HAPPY CUSTOMERS. Get customer referral lists!!!!! (and look at their apps in use - go to a customer's site - if they have happy customers, those customers will be willing to do an on-site referral)
>
>Be very careful when hiring experienced developers. .net developers are like all developers in that they know what they know and maybe not a lot about all of the options and methodologies out there. I helped one developer write one line of code using BINDEVENT in VFP in less than 5 minutes after they spent 2 days trying to do it and failing because they didn't know about BINDEVENT(). I recently looked at an entire page of sql syntax to fit all of the querying that needs to be done into one statement because the developer decided one single statement is always better and client's dba would not allow a stored proc. I asked him who was going to support it (modify it later if necessary) and would he still understand it in 6 months? The same holds true for .net. You can find a really good developer who knows a lot about the tools or methodologies they have used. Sometimes they will argue for that specific route because that is what they know. Others will vote for a new route if training is provided in order to take advantage of training and increase their skill set. What is the long-term goal of your company regarding these apps? You've seen in the past few years how .net has changed drastically from one thing to another. A loyal and honest employee will honestly push for what is in the best interests of the company, not what is in their own best interest. You don't want someone fighting the company's direction every step of the way. How much time does your company really have with their existing developers? Every developer should be capable of learning or out the door they go. Maybe it's time to clean house? You'll want to keep a couple of GOOD VFP developers around to assist with explaining the function and behavior of the VFP code. Sadly, I have met a LOT of .net developers who cannot read VFP code! Amazing! You can hold on to the existing developers who cannot learn .net (after honest efforts to do so and the training as well) and the new methodologies to support the existing apps (and free the others up for .net coding) but if they do not grow with the company, when the new apps are done and the older apps no longer supported, let them go. Harsh, but a business reality.
>
>Is someone assigned to track all ongoing modifications/bug fixes/new design in the existing apps while the .net coding is going on so all of that can be also be tasked into the new .net apps? If you support and update the existing apps while recoding in .net you have to ensure all of that gets into the .net apps as well. Do you have any tools at your disposal for that? Do you have TFS? Have you looked at SCRUM and sprint planning (Agile development)?
>
>Who is going to do code review?

Brava!