Member Avatar for vb6forever

Hi experts, well, nearly 10 years after .net became the mainstream I am finally making the move to vb.net after having supported VB6 apps all this time.

I have been learning vb.net 2010 but am finding it difficult to find relevant information on the COM aspect. In VB6 COM was the dominating feature of the language, however, I can't seem to find relevant information on what has happened to COM in vb.net, does it still exist in vb.net, does it work in the same way or are apps designed in a different way in .net to do away with COM dll's?

Anyway pointers to where I can find relevant information would be greatly appreciated.

Thanks

Giz

  • 4 Contributors
  • 3 Replies
  • 224 Views
  • 9 Months Discussion Span
  • Latest Post Latest Post by oreallabac
Member Avatar for Oxiegen

Welcome to the world of .NET, friend. :)

In my personal oppinion, although COM has it's uses, it has become a thing of the past.
And unless you absolutaly need to access certain specialized code and functionality created in COM objects, you'll find almost everything you need in existing .NET objects.

And to answer some of your questions.
Yes, COM still exists and you pretty much access exposed code the same way as you did with VB6.

That said, I found a link to a tutoral about COM interoperating here.

Member Avatar for mjuras

Disclaimer: I help people migrate from VB6 to .NET for a living.

I agree with Oxiegen: in general you should consider avoiding COM components. Compared to working with managed components, COM components/controls are harder to debug, they tend to be less sophisticated/flexible, they require special security permissions to access, and worse of all they add more compexity/cost to builds, deployments, and support. Not to mention many of them are no longer supported by a vendor or the vendor has a .NET replacement they are more interested in supporting. Moving from VB6 to .NET and retaining COM defeats the purpose of upgrading or at least reduces the ROI.

I once had to migrate over 1.2M VB6/COM LOC to C# and one of the most important guiding principles was AVOID INTEROP! We did a bottom up migration so that all in-house components would be accessible as .NET assemblies and we configured the code reengineering tools to help us rework the applications so that external COM components/controls were migrated to approved .NET replacements. We used the tools from Great Migrations to automate the transformations and saved alot of time and trouble.

That said, MSFT did try very hard to make interop work -- a major task. It is not 100% but they did a good job and it looks like .NET 4.0 has a few more language changes to help clean up interop code. If yoiu really want to become an interop master look at Adam Nathan's book: .NET and COM: The Complete Interoperability Guide. It is a little dated now, but goes into deep deep interop territory.

I think one notable exception where you will be stuck with interop is MS Office which looks like it will automated via a COM API for some time. Although Microsoft has a Primary interop assembly and there are some alternatives for .NET-based integration (VSTO, VSTA) that I have heard about. MS OFfice is really a special case.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.