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