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?
…the last point may be mute because there is potentially a black…
- surely, moot?
Yes, thanks. will update.
Delphi or VS6
either VB or C/C++
It all seems to have gone a bit off track since then.
If we view .NET as an enterprise platform where the targeting enviroments are 100 % under control and unified then most issues will simple not exist.
.NET operate through at least one interop layer and therefore it can be viewed as it has poor performance compared with other development platforms. End users in enterprise do not have any option then to use the .NET based solutions.
Windows Vista is shipped with .NET Framework 3.0 and now when VS 2008 RTM is released which comes with version 3.5 I expect that in the coming SP-1 Vista will also have it.
Today Microsoft only target enterprises with their new versions and tools and nothing in the world will change their focus.
The only real issue is faced by the group of independed (Microsoft depended) developers who try to target all kind of enviroments with their solutions.
The above will be expanded in an upcoming blogpost,
Kind regards,
Dennis
[…] Ross’ work to test that […]
In Excel 2007, it will always load the latest CLR available on the machine, regardless of COM shims. In Excel 2003 it can be an isue if a COM shim locks to an older version of the .NET framework–for this reason it is advised that COM shims where they exist always load the latest framework.
Add-ins in .NET that you write will work with the version of the CLR you built them with (e.g. 2.0) and they will work on newer CLRs (e.g. 3.0).
When an add-in is installed on a box, it is assumed that the add-in installer will ensure that at least the CLR that it was built with so the add-in will run. So if an add-in was written against CLR 2.0 it should also bootstrap 2.0. That way, with 2.0 installed on the machine, Office will start loading that version (the latest version on the machine) and all add-ins written against all versions through 2.0 will load properly. The bummer for VSTO 1 and VSTO 2 developers was we didn’t make it very easy for you to write those installers–you had to figure out how to bootstrap the CLR you built the Add-in against on your own.
In VSTO 3 the good news is we make the creation of installers that bootstrap the right CLR really easy to create through our new support for ClickOnce. The bad news is that these features work for Excel 2007 and not 2003, so you still have to work through some of the same difficulties if your are doing Excel 2003 development.
Hope this helps–if you need more help or have additional questions, feel free to contact me through my contact form on my blog.
Eric