>Did you ask?

No. I think I'll first try to get as far as I can by reading and by other means. We have some guys that have read books and stuff on .NET, but not a "certified" guru.

I'll probably hit a ceiling where I can't advance anymore and will ask for some formal tutoring.



>
>
>>He didn't say anything about sending me to a class. The company did send me to Oracle PL/SQL/DBA classes when I switched from VFP to DBA.
>>
>>
>>>Is your boss offering any .NET training as well? I took two .NET courses, one amounted to a run through of the features of .NET (very poor), but in the other we actually created a working .NET application. The system had to have both an ASP.NET front end and a Winforms frontend. Very eye opening.
>>>
>>>>Evan. You're talking a little over my head, but I'll keep you points in mind.
>>>>And yes I suspect that I'll be calling on the gurus at UT for advise as I go.
>>>>
>>>>Thanks.
>>>>
>>>>
>>>>>>Hello. This is actually a serious question. I was just told that I will start converting some of my VFP screens to .NET starting next year, which to me is a big task. I need to convert a "simple" VFP application, that is in production, by July of 2007 and demo it. If there are any expert .NETers logged in, I ask you, where do I start? Any suggestion for a starting point will be helpful.
>>>>>
>>>>>Hey Sam. In addition to what others have said, here is something that I've found useful.
>>>>>
>>>>>If the VFP app isn't already broken into UI, business and data then if you have time rewrite so that it is... Then my suggestion is to then convert the application to .NET layer by layer. This way you will know that the layers work and how to call them from VFP. In otherwords the VFP parts will be debugged and working, so that if it doesn't work when you call it from .NET code, then it has something to do with how .NET works.
>>>>>
>>>>>As well this will allow you to focus different aspects of .NET at different times, rather than trying to learn the whole thing at once. Learning how to create .NET Winforms that are empty skins, that read and write data to VFP COM components is a far more focused activity. As well, when are just writing C# or VB.NET business classes, you are once again dealing with a subset of .NET. Same goes for database or data classes. The .NET framework is huge and can't be groked as a whole like the VFP programming language.
>>>>>
>>>>>I find that the .NET world is really short of good books, samples and experts that show how to build proper multi-tier apps. Just as with the VB6/SQL folks, they are obsessed with examples of UI components (grids, drop downs) that get data directly from a SQL database. Because of this, the UT .NET forum is extremely valuable since it is populated with former VFP gurus, that are now .NET gurus. These people (Bonnie, Kevin and others) know how to build solid multi-tier apps.
>>>>>
>>>>>I think you will be impressed with .NET, FUD aside, it is a rich, stable platform with a great IDE. You'll be frustrated a bit by how easy something were in VFP and are now more difficult in .NET, but once you build up some global classes, these begin to melt away.
>>>>>
>>>>>You might even want to sell the .NET conversion for the bigger apps in the same way. Do it in tiers. I was able to do this with our main application. It turned a potentially very long project (3 years?) into several micro projects. This helps to mitigate risk and gives you time to learn.