The world of managed com addins is a mess. VSTO has not been received well and the story of unmanaged code (Excel) and managed code is of deployment and stability nightmares.
There are a quite a few things right from the off that cause problems for Office devs wanting to use .Net technology:
- .Net is inherently slow, and slower still when com interop is needed
- mscorelib (hell, ;-))
- Security
- Deployment (esp. VSTO < v3)
- Framework availability
VSTO and managed com addin can over come the first 3 issues by using so called “com shims”, which are proxies sitting between the managed code and the com application (com shims themselves are unmanaged code). Although these solutions actually compound some of the other problems (i.e. speed), they generally work well and have been successful.
Deployment for managed com addins is not such an issue, as it is up to the dev to ensure the addin installs correctly. However the first two versions of VSTO tried to simplify this process, unfortunately Microsoft never “managed” to get it right. VSTO 3 seems to have cracked this particular nut, although we should wait for reports from the wild until we take this as gospel.
There is little anyone can do about framework penetration, but having to install a .Net framework to run a addin if frankly a laughable proposition and there is quite literally no way to avoid it, it’s fundamental to the concept of .Net. The problem then becomes what if users are unable to install frameworks. The thinking is that this problem will vanish with time, as windows service packs and new installs load the framework “organically”.
However, the last point may be moot because there is potentially a black cloud hang over managed code and Office!
Stephane Rodriguez of xlsgen points out that the framework version Excel (office) loads first, will be the framework versions that all subserquent managed addins will have to use. The com shim does not effect this out come as it’s controlled at the Application level, i.e. the process belones to Excel, not to your addin. This is comfirmed by Microsoft here, where the conserquencies are spelt out quite plainly!
If other managed code, such as an add-in, requires the later version of the .NET Framework, it will not run.
In the research I have briefly done of this issue there does not seem to be a solution available as of today. This seems like quite a serious shortcoming, and to me at least, hugely surprising because one would imagine that MS are aware of the implications.
It does beggar the question as to why this sort of thing should ever be an issue for devs, Microsoft trumpet long and hard about how easy MS products are to use, and often that is true, but with .Net and Com this could not be further from the truth.
This the is yet another blow for .Net and Office, it has implications for all the .Net technology, VS, VSTO, and VSTA (should VSTA ever make it in to a actually product?!), what are MS doing to us?!!?
I’m a big fan of .Net, its quick and easy, and very powerful, but is it the right tool for current office products? It’s Unlikely that MS will port Office to a .Net platform (currently no MS product of note are built using .Net odd that!)
So where does that leave us? VB6 has long departed (although is still exceedingly popular) VBA is no longer developed, MS variations of C, and their claims to nativity is up for debate and it’s hardly a tool you want to use to build true RAD solutions. So, anyone for Delphi?
