You can mix managed and unmanaged C++ in the same module, so you could leave most of the code alone and just provide a managed interface class (or classes, depending on what functionality you need to expose).
But I don't get the comment about COM. If you've implemented a .Net interface for your dll, you can use .Net's standard assembly-based mechanism.
COM would be relevant if you want to leave the dll as unmanaged C++ and provide a COM interface. The .Net application could then access it's functionality via .Net's COM interop mechanism.
Is it that you are you wondering about which of these approaches to use?
"You can mix managed and unmanaged C++ in the same module, so you could leave most of the code alone and just provide a managed interface class (or classes, depending on what functionality you need to expose)."
How can this be done ? If i will do so , will i be able to add reference to this managed class from a .net project ?
When it's build with /clr, you will be able to access the managed class. But if it's an exe, written in WIN32/MFC, and you're talking about migrating to use WinForms/..., I think it's quite a different matter.
What is the reason for the migration? To access some functionality? Or??
Write a managed interface class which calls through to the unmanaged code.
If you are unsure of how to do this, the first thing you should do is read some of various forum's discussions about the subject. Tru ggogling for "managed wrapper for unmanaged c++"