What’s you gut answer right now; without reading the rest of this post?
In my (seemingly) never-ending quest along the path of Uncapacitated Facility Location problems, I found myself thinking if I would be better of write some core functions in C (unmanaged) and calling them in my VB.net project? I thought that it probably would be, but decided to check first. Here’s the link, you can skip to the conclusion at the end for the low-down:
http://www.grimes.demon.co.uk/dotnet/man_unman.htm
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 Excel Developers Kit has been out of print for almost a decade, sadly there has been no update, but you can find a e-copy here:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/office97/html/edkfrnt.asp
Most of the stuff is out of date now and much of the C++ stuff just wont work – I understand that some of it didn’t work when it was published! I actually have the hard copy of this is book so if you really need any of the example files I might be able to get them for you?
The second is a link to some general C++ books, not read them myself but though I would post a link as they look good (and are free :-))
http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html
Enjoy!
Mike Martin the aurthor of SpeedBasic recently contacted me about his product. It turns out that development has not in fact stopped. Mike took a look at B++ and noticed some areas he thought could be improved. He did the same with his own Speed basic. Taking all this on board and re wrote SpeedBasic to incorporate much more syntax checking prior to converting the code into C.
The latest incarnation of SpeedBasic can be found here: http://www.martinm.net/
New features include:
Although, the IDE is not quite ready yet so you will have to make do with the basic editor.
If you’re interested in getting involved with this very worthwhile project I’m sure Mike would appreciate some help. He’s especially keen to hear from anyone with a decent understanding of API’s. He can be contacted thought his web site.
