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?
A 1000 words on VSTA
1 May 2007 by Ross McLean
If you don’t know what Visual Studio Tools for Applications is then you need to read this. If you do, I hope this might provide some more insight.
At the recent UK Office User Group meeting the topic of VSTA came up and the only real thing that came out of the ensuing discussion was that no one really knows what’s happening with it?
What is VSTA?
It’s the replacement of VBA. VBA is not going anywhere, but it’s not getting developed either that’s the facts, if you don’t like it you’ll need to get over it because MS don’t change there minds.
It will work in the same way as VB and VBA, that is to say its IDE will be like the one in VS, (VS2005), albeit a lite version. So that includes things like snippets, (yeah!) tasks, and the debug tools. But like VBA it won’t allow you to build exe’s that function independently of the application it ships with.
The VSTA IDE
Why VSTA.
I have nothing to do with MS and these arguments for VSTA are what I have learn from reading and watching what others have talked about.
Easy to move from VSTA in to VS. If I write an Excel App with VSTA, it should be easy for the IT department to take that to a distributable level application using VS Pro, VSTA and VS Pro are tightly coupled.
Security. By default the VSTA code will run in “Full Trust” (it can do anything), but the IT department should have greater control over this, so they might limit user to “Partial Trust” environments so nothing to serious can run like making reg settings changes.
IDE is scalable. Not 100% on this, but I think that during install say the admin can set the IDE to be Simple, Average or Full Power! Also seems that it is configurable by user profiles, so if I log on as a “Power User” I get a different IDE than someone who logs on as a “User”.
I’m not sure how the VBA IDE and the VSTA IDE will work in office Apps that will need to have both, maybe they will keep the 2 in there, or maybe the VBA one will get the boot and you have to load is separately?
Versioning. The way VSTA works is slightly different to VBA, I’ll explain that latter, but think of it like this for now, If you write one lot of code, then add some new code to it and save it, you will not just update the first lot of code you will get 2 lots, one called CodeLot1 and the other called CodeLot2. This is generally a good thing.
It’s in .Net. Both VB and C# flavours. Anything in .Net is 200% wonderful. But seriously it means you can use the .Net framework (well some parts of it) and that really is a good thing.
There’s macro recoding! (Phewww!)
Ok, so how does it work?
Well I’m not 100% sure, but I will tell you how I think it will work based on what I’ve seen.
In .Net code is compiled in to “Assemblies”, which are like to COM .dll’s, in that they get called by the host programme and provide units of functional code. You can see then these Assemblies do not sit “in” the Excel workbook or Word doc like VBA. Instead they must be installed somewhere on the PC. This is one of the things I don’t know much about, actually how it will work, but I guess by default it will be placed in program folder of the target Application. How this will effect portability of VSTA documents I don’t know maybe it will go in the Zip file (Office 2007 +) and get installed by VSTA on first use? This could be a big issue for Office Devs portability is one of the reasons VBA is so darn popular.
Isolation”¦
Not in the words of Ian Curtis, but in the manner of .Net is where your bit of code is shut out from all the other bits of code. The way this is done is via a technology (an approach really) called Application Domains. App doms are constructs that are loaded in to a Process. When you press Ctrl+Atl+Del you can see all the processes you have running. In the COM world each Application has it own Process, so if you start Excel, then start another Instance of Excel it will load into another Process. Say I open an Addin in the first Excel I opened it will run in that Excels Process. If my Addin errors out, I have to close that Process, (this is where you go into Ctrl+Atl+Del manic mode!) Isolation meanss that in the .Net world I could unload the Erroring Addin Via Code, thus keeping the Excel Instance open. Although what I’ve just said is not quite right it give a good illustration of how App doms work.
In practice with a COM server (Excel), and .Net code has to be interoped, which means a layer of code site in-between the COM object and the .Net code. The .Net Frame work provides a thing called MSCore which does this job. However if I have 2 .Net code assemblies working then they both go through MSCore if one crash, all of them are buggered. VSTA allows you to isolate each assembly but it interestingly also allows you to combine them this is for performance benefits. As it stands at the mo this is consider very bad practice, but maybe VSTA has a different aspect I have failed to see.
So that’s about it. If any one form the VSTA team reads this and notices errors please get in touch, or if you can spread light in the areas of dark that would be splendid too.
The observant of you will have noticed the above’s only 975 words, I’m 25 short, humm, What about
I’m not a 100% sure about VSTA,”¦Yet.
Here are some links enjoy:
What is VSTA Video?
http://www.summsoft.com/blogs/msvsta/archive/2007/03/28/vsta-video-vsta-overview.aspx
VSTA in action Video (for a ISV POV)
http://blogs.msdn.com/vsta/archive/2007/04/27/vsta-video-vsta-at-a-glance.aspx
VSTA Home Page
http://msdn2.microsoft.com/en-us/vstudio/aa700828.aspx
VSTA Blog
http://blogs.msdn.com/vsta/
More on VSTA (at Sumit Softwear????!?!)
http://www.summsoft.com/blogs/garyvsta/default.aspx
Something I’ve got to read:
http://blogs.msdn.com/tq/archive/2006/12/05/vsta-and-generics.aspx
Tags: Comment, VB.Net, VSTA, VSTO
Categories: MS, VSTA • 5 Comments »