Arnaudon,

>i'm searching a quickly way to migrate an application under Visual FoxPro 6 to Visual Basic .NET.

You don't say if this is a conversion to a Windows Forms application or to an ASP.NET web application. Either one is a rewrite of all the VFP6 user interface and probably all the business logic and data access, changing from VFP's data manipulation commands like USE, SCAN, SKIP, SEEK, etc to SQL-based queries from a backend database (which can also be VFP tables via the OLE-DB driver). If your VFP app already depends mostly on SQL queries, you may be one step closer to an easy migration, but still very far away.

However, you might be able to salvage some parts of your application that have no user interface and are perhaps very complex and data-intensive, such as calculation routines, etc., by putting that code into a VFP COM MTDLL and calling it from .NET, passing the data back and forth as XML. Or, you could build VFP XML Web Services to be called from .NET.

It all depends on the specifics of your application and just what you need to accomplish. I, and many others here, have experience in extracting existing code and reusing it that way, often with good results. But most likely, you are looking at a very large learning curve and a complete rewrite if the entire application MUST be in .NET.

That includes probably a complete re-analysis, including creation of requirements documents, and so forth, unless you are fortunate to already have good system design documentation at a detailed, granular level. If your application is already designed with a logically-tiered architecture, you may be a step or two ahead in the analysis stage, but you (and the decision-makers in your company) should NOT expect this to be an easy, simple, quick, or efficient task.

A project that I recently consulted on (and will probably be consulting on again soon) had to get over the internal review committee (typical large corporation IT department) recently, including justifying why keeping it in VFP and switching from VFP tables to SQL Server was a much faster and far less expensive choice than a complete rewrite in .NET.

The fact that seemed to be overlooked by the architecture review people was that a complete rewrite of this very complicated VFP app would involve a much longer analysis, design, coding and testing cycle, including the loss of internal expertise in both the problem domain and intimate knowledge of the existing, mature, and well-debugged VFP code, a complete rewrite of all testing scripts, and on and on.

Finally, sanity entered the process when the higher-ups overruled the architecture people on the basis of being able to actually deliver what the users needed this year instead of next year and saving a large cost in the process. They saw through the bogus argument that a rewrite was the best choice just because .NET is the new company standard, and instead saw an enhanced VFP/SQL version as a logical and practical next step in the application's lifecycle.

The tipping point came when they realized that the move to SQL Server with VFP as the front end would position them better for a future move to .NET and would allow us to have more choices for accessing the data and VFP COM-based logic in some cases from ASP.NET web interfaces for parts of the system.

So, the question I would be asking in your case is WHY the move to .NET is needed and if the large amount of extra time and expense is really worth it for your application -- from a money-based business decision point of view. Bottom line, you want a fast conversion, and there is no easy or fast way to do it.