Hi community,

I am currently in the process of migrating a substantial vb6 project towards vb.net. This project has a number of referenced dependencies, custom controls and components - essentially additional functionality found in other vb6 projects hooked up to the main project.

After having used the default migration tool in Visual Studio 2008, I’ve noticed that these are now treated as COM objects, unaltered and referenced by the converted project.

My understanding here is that Visual Studio is applying a “.net wrapper” or interpreter to these projects, under a technique known as interoperability. Interoperability allows us to integrate the old with the new in order to run external components not written in a .Net language attached as project references.

1. Am I able to thus avoid having to alter or migrate these projects in any way?
2. Are there any possible downsides to this approach? Presumably performance, first and foremost.
3. If external components can be interpreted by the CLR through Interop, why can’t the whole project, or for example classes within the project? If the only requirement is to make it work on the .Net framework. That logic doesn’t seem right to me so I would just like some clarification/confirmation concering that.

Many thanks in advance!