MS expects vNext of VSTA will ship around the time Visual Studio 'Orcas' ships.
If this proxygen problem is a blocking issue, I would again recommend taking the minimal/simple proxy layer approach.
1. The a project template would include a reference to your host OM (for COM, probably a strong-named Primary Interop Assembly (PIA), registered in the GAC) so that the addin project will already have a reference when it is loaded. This will expose the types in your OM (eg: ApplicationObject as the root class of your OM).
2. Create a minimal proxy layer: The VSTA proxy layer exposes a single method from the host app to pass an instance of your OM root, for example, GetApplicationObject(). Hidden in the addin's startup code, the addin calls GetApplicationObject().
...
#region VSTA-generated startup code
public sealed partial class TheApplication : Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.Application {
HostApplicationObject hostApplicationObject;
public ApplicationObj ApplicationObj
{
get
{
if (hostApplicationObject == null)
//for COM, get host OM via IDispatch*, for .Net, get host OM as System.Object
hostApplicationObject =
this.GetHostApplicationObject() as hostApplicationObject;
return hostApplicationObject;
}
}
#endregion
...in response,
(for COM -- 3. the host app returns an IUnknown* through the proxy layer, )
(for COM -- 4. next, the proxy QI's the IUnknown* for an IDispatch*, and passes the IDispatch* to the addin as a 'System.Object')
5. this line:
hostApplicationObject = this.GetApplicationObject() as HostApplicationObject;
casts the System.Object returned by this.GetApplicationObject() to a strong type. This will give the script author strong-type, intellisense access to your complete OM (assuming the object returned is the root of your OM).
Not too hard, right?
For COM applications there is a sample showing how to pass IDispatch of OM to addin :
http://www.summsoft.com/files/folders/vsta_samples/entry247.aspx
-G