I want to convert a VB6 Application with many Forms to C# .Net 2.0. How can i do it. Is there a tool available?

Most of the so called conversion tools dont seem to work as well as anyone ever wants them to. Coupled with the fact you're converting a win32 app to a .net app in from a language which allows for insane amounts of sloppyness, to a highly structured one.

It will cost you more time converting then rebuilding it from scratch, believe me.

And the app you'd get would be worse by converting too

As others have rightly pointed out, you will find things you want to change in automated translations -- much the same as you would find things to rework during a manual rewrite. Fortunately, there are some translation tools that are designed to be customized. If you invest time designing your .NET development standards and tuning the tool to meet those standards up front, you will arrive at a configuration that strikes a good balance between what you do by tool and what you do by hand -- for typical large codes (>100K LOC) the coding work can be 90-95% automated and often higher.

There is a vendor that specializes in this type of technology. This forum does not allow mentioning specifics so you will have to search the web to find them.

That will you cost 5% of your time, the other 95% time (and more!) will be spent on getting right the 5% code that rests.
Been there, done that.

I been there, done that too and I am not trying to understate the expertise and effort needed to migrate real world VB6 codes to .NET. But let me clarify this: I am talking about large corporate or commercial business systems: dozens or hundreds of interrelated VBPs and 100s of thousands of LOC). The source codes of these systems describe literally tens of thousands of business rules and myriad other technical details about every aspect of the application: what data is in every form/page, file, and query, how is it presented and formatted, where does it come from, where does it go, what are the rules of the calculations and transformations, and what happens if there is an error. Often you will find that the programmers and users do not fully understand what the systems do in all scenarios. That is the point of software after all: to faithfully recall and execute complex data manipulation and myriad technical operations for us.

Both tool-assisted and manual migrations demand a lot of design work to define how you will effectively take advantage of .NET. The difference is in how you spend the rest of the migration project resources. With a manual rewrite from scratch, you will spend way way more resources re-gathering requirements, manually typing in code, and fixing the defects that come along with massive amounts of new manual effort. With a tool-assisted rewrite, you will spend more time tuning the translator to produce codes that faithfully reproduce the results of the original application while fitting into the new design. I am not saying this is 100%, and I am not saying that all new code should start from a translation – select parts of the system will certainly have to be redone from scratch.

Face it: The source code is the most accurate and complete specification of what the system does and how it does it, and 99% of the time it is the only specification. Doing a rewrite from scratch means ignoring the existing source and it means you will rebuild a mountain of functional and micro-level technical requirements manually. Functional requirements gathering will end up taking the majority of your resources and that is not where they should be spent: migration work must focus on researching the new platform, creating a design to take advantage of it, and upgrading your processes and code to take advantage of it all. Leveraging tools to help you do the job, particularly when the job is to migrate huge systems, allows the team to spend their resources more effectively.

Except Ive yet to see a system come out of a converter that didnt need a rewrite anyway

Yep. Converters are crap

But if you insist, i reccomend upgrading to vb.net first, then converting to c#

Conversion tools ALWAYS take with them the "bad" design from the past into the future. So you always have to take into consideration : What can be improved?