Creating and deploying Managed COM add-ins with VB.NET 2005 – Part X
You can find the earlier post on the subject at the following links:
Part I – Introduction
Part II – Connection
Part III – Notes Tool – Workbooks
Part IV – Notes Tool – Worksheets
Part V – Notes Tool – Main functions
Part VI – COM Shim Wizard
Part VII – Strong Name & Digital codesign
Part VIII – Deployment
Part IX – Troubleshooting
About the walkthrough
I have had two aims with the walkthrough:
– show how we can create managed COM add-ins and the terms for it,
– show how we can deploy managed COM add-ins and how to troubleshoot them
in order to evaluate VB.NET.
Why use COM add-ins?
In my experience it’s not explicit required by the clients but in order to meet specific functional needs from the clients COM add-ins can be one technical platform to use.
For me the following aspects can be the driving forces to use COM add-ins:
– To use third part’s ActiveX controls
– To obtain a better performance (compared with VBA)
– To protect my intellectual property
– To apply a functional licensing model
Creating and deploying COM add-ins with VB.NET or with classic VB 6.0?
For many technical reasons I prefer the .NET platform and Visual Studio.NET but that’s not the subject here. Instead the question is raised for what is best for the clients and in view of their IT-platforms.
The .NET Framework is still under rapid developing and the same is indeed valid for the Visual Studio.NET. The rapid developing itself may be a heavy reason to simple wait with the transition, especially when it comes to managed COM add-ins. Different managed COM add-ins can actually also require different versions of the .NET Framework.
For Windows 2000 and Windows XP the .NET Framework is not available unless it’s installed as an upgrade. As a consequence it will be some additional costs to calculate with in order to use managed COM add-ins if not the correct version of .NET Framework is installed. (At present version 1.1 and 2.0 of .NET Framework can coexist on the same computers.)
The same scenario as above is applicable when it comes to the PIA. However, the version for Excel 2003 cannot coexist with the version for Excel 2002 on the same computers. As long as the PIAs are version specific we cannot use early binding when several versions of Excel are involved.
For me, as a micro consultant, it will never be possible to suggest a worldwide company that they need to upgrade about 3000 computers globally in order to use my managed COM add-ins.
In my opinion it’s at present not an easy task to achieve and maintain a 100 % controlled .NET environment.
(In my opinion the above also explain to a high degree why we not yet have seen any commercial managed COM add-ins.)
From a strictly technical point of view it can be concluded that as long as Excel only communicate via a COM-interface it will be necessary to add an extra ‘layer’ (loader) between Excel and the managed COM add-ins. After all, we cheat on Excel that it ‘talks’ to another COM source and at the same time we cheat on .NET that it actually ‘talks’ with another NET source. Per design it exist a performance penalty which cannot be disregarded.
From my professional point of view the following summarize my recommendation:
As long as Windows operating systems still support classic VB 6.0 solutions and as long as Excel only offer a COM-interface to communicate via then it’s advisable to create COM add-ins with classic VB 6.0.
My recommendation should not prevent anyone from exploring and learning about the .NET platform. After all, in the long run it’s not a question if we should use it or not, it’s only a question of when as .NET is here to stay.
At present I’ve got two managed COM add-ins ‘up & running’. In both cases it’s only for testing purpose (and the projects are considered as ‘mutual benefit’ projects between me and the clients).
– A more advanced version of the presented Notes Tool (runs on two computers)
– A tool that feed Excel 2003 with data from a SQL Server 2005 (runs on three computers)
For those of You who don’t have the option to use classic VB 6.0 the case here together with my good friend, Mike Rosenblum, excellent VB.NET Office Automation FAQ hopefully can give You some input for VB.NET & Excel.