Gary Depue's VSTA Blog

64-bit setup script for ShapeAppMacroRecordingCSHarp sample

2010-01-06T15:10:00Z

With 64-bit Windows, vsta registry entries must be changed from

32-bit registry: HKLM\\SOFTWARE\\

64-bit registry: HKLM\\SOFTWARE\\Wow6432Node\\

I've attached SetupShapeAppMacroRecordingCSharp64.js to demonstrate these changes.

Since setup scripts write to the registry, remember to run the setup scripts as administrator in Windows Vista and Windows 7. "run as administrator" can be accomplished by running CMD (commandline window) as adminstrator or by right-clicking on an executable and selecting run as administrator.

How to add a global variable to your AddIn project (VB)

2009-04-24T19:06:00Z

It's simple for your Visual Basic add-in projects/project template to provide a global variable, like 'ThisApplication'. This kind of variable gives the end user convenient, VBA-like access to your host application's object model.

To define a project-wide global variable, you can declare a Friend or Public variable inside a Module:

Module globalsMod

Friend ThisApplication As ApplicationObject

End Module

We've declared a global variable ThisApplication as an instance of the host application's object model, the type 'ApplicationObject'.

When declared as a Friend or Public variable, ThisApplication can be used by any class or module in the project.

Notice below, that the global variable ThisApplication is assigned in MacroAddIn_Startup() in the entrypoint class

Notice the assignment of ThisApplication in MacroAddIn class and its use in both MacroAddIn.Macro1() and Module1.TestModule():

Module Module1

Sub TestModule()

MsgBox(ThisApplication.Caption)

End Sub

End Module

<System.AddIn.AddIn("AppAddIn", Version:="1.0", Publisher:="", Description:="")> _

Partial Class MacroAddIn

Public Sub Macro1()

MsgBox(ThisApplication.Caption)

End Sub

#Region "Startup Code"

Private Sub MacroAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

ThisApplication = CType(Me.GetOM(), ApplicationObject)

End Sub

Private Sub MacroAddIn_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown

End Sub

#End Region

End Class

The variable declaration and hookup code should be concealed from the end user by hiding them in a hidden file (see Adding a Hidden File to a Project Template)

Since our global ThisApplication is a reference to the host application's object model, it should never be assigned by the end user. A better and safer approach would be to expose the global variable as a ReadOnly Property like this:

Module globalModule

Private _thisApplication As ApplicationObject

Public ReadOnly Property ThisApplication() As ApplicationObject

Get

Return _thisApplication

End Get

End Property

Sub _AssignApplicationObject(ByVal thisApplication As ApplicationObject)

_thisApplication = thisApplication

End Sub

End Module

<System.AddIn.AddIn("AppAddIn", Version:="1.0", Publisher:="", Description:="")> _

Partial Class MacroAddIn

Public Sub Macro1()

MsgBox(ThisApplication.Caption)

End Sub

#Region "Startup Code"

Private Sub MacroAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

_AssignApplicationObject(CType(Me.GetOM(), ApplicationObject))

End Sub

Private Sub MacroAddIn_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown

End Sub

#End Region

End Class

Improvements to IPHTerminateOrphanedVSTA sample

2009-04-10T20:57:00Z

Below are significant improvements to the IPH sample posted here through the use of global mutexes for cross-process synchronization.

Question: What does the IPHTerminateOrphanedVSTA sample do?

Answer: You may have noticed that the IDE process (vsta.exe) may be orphaned if the host application crashes or abnormally terminates. The IPHTerminateOrphanedVSTA sample uses an in-process host to watch for an orphaned vsta process (its own process) and terminates it. It does not interfere when VSTA projects are opened with the standalone VSTA IDE (no host application process).

After you have installed the original IPH sample, the following improvements can be applied to that sample:

VstaRuntimeIntegration.cs :

Connect() creates a global mutex named after the host app PID, owned by the host process, and stored as VSTAMutex.

When application Disconnect()s VSTA (when host app exits), it releases the mutex properly.

VstaRuntimeIntegration.cs :

private Mutex VSTAMutex;

internal void Connect(Application hostApplication)

{

this.application = hostApplication;

// Get the current process.

Process currentProcess = Process.GetCurrentProcess();

try

{

Mutex.OpenExisting(@"Global\"+ "Visual Studio Tools for Applications Host Process" + currentProcess.Id.ToString());

}

catch (Exception ex)

{

// Create a global mutex with a unique name based on the application’s processID.

VSTAMutex = new Mutex(true, @"Global\" + "Visual Studio Tools for Applications Host Process" + currentProcess.Id.ToString());

}

// Create a Service Provider.

InstantiateServiceProvider();

// Load Application Level AddIns.

LoadAppLevelAddIns();

// Load Macros In-Process.

LoadMacrosInProcess();

}

internal void Disconnect()

{

try

{

VSTAMutex.ReleaseMutex();

VSTAMutex.Close();

}

catch (Exception ex)

{

}

IPH.cs :

Notice that the polling loop has been replaced with two global mutexes (or system mutexes).

The IPH looks through all processes for the host application process with a unique global mutex name originating with the host application:

@"Global\" + "Visual Studio Tools for Applications Host Process" + hostproc.Id.ToString()

When this process is found the IPH creates a unique global mutex (VSTAHostMonitorMutex) with the name:

@"Global\" + "Visual Studio Tools for Applications Host Monitor" + hostProc.Id.ToString());

and creates a monitor thread. The monitor thread will open the existing host mutex (VSTAHostMutex) and block or ‘wait’ for the host process to release its mutex (when the host closes or crashes). If the VSTA IDE process (vsta.exe) is orphaned, the thread will terminate its process, vsta.exe (the IDE).

VSTAHostMonitorMutex is assigned when the IPH is loaded for the first time only because OpenExisting() fails with an exception this first time:

Mutex.OpenExisting(@"Global\" + "Visual Studio Tools for Applications Host Monitor" + vstaHostProc.Id.ToString());

When the IPH is loaded additional times, OpenExisting() of the host monitor mutex does not fail, which means that no duplicate monitor threads are created.

IPH.cs :

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using Microsoft.VisualStudio.Tools.Applications.DesignTime;

using Microsoft.VisualStudio.Tools.Applications.DesignTime.Interop;

using System.Diagnostics;

using System.Threading;

//IPHTerminateOrphanedVSTA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5993c97a24fb6aa3, processorArchitecture=MSIL

//{2CD68381-5859-4afe-88AC-42D13CD4B335}

namespace IPHTerminateOrphanedVSTA

{

public class IPH : IInProcessHost

{

//To debug this IPH follow this sequence:

//1. start ShapeAppMacroRecordingCSharp sample directly from .exe or select 'Debug | Start Without Debugging' in VS

//2. Launch VSTA IDE (Alt + F11), should load a macro project with no IPH

// (if macro project has IPH, just remove entry <InProcHost>{2CD68381-5859-4afe-88AC-42D13CD4B335}</InProcHost> from ShapeAppMacros.csproj before 'Tools | ShowIDE' opens it).

//3. In VS, 'Debug | Attach To Process...' select vsta.exe

//4. In VSTA IDE, 'File | New Project', select CSharp template, discard open project and this IPH (IPHTerminateOrphanedVSTA.IPH.SetAdapter() should be called.

//5. From 'Task Manager', kill ShapeAppCSharp.exe and the CheckForHostObserverThread.CheckforHostProcess should drop into section where this call is made:

// System.Diagnostics.Process vstaProc = System.Diagnostics.Process.GetCurrentProcess(); so that vsta.exe can be terminated.

//mutex is used to block monitor thread executing shutdown until host closes or crashes

static Mutex VSTAHostMutex;

static Process vstaHostProc;

//mutex is used create single monitor thread (thread ensures vsta.exe is always terminated when host terminates)

static Mutex VSTAHostMonitorMutex;

#region IInProcessHost Members

public void SetAdapter(IVstaHostAdapter newHostAdapter)

{

//get vstaHostProc from globalMutex created by host

Process[] procs = System.Diagnostics.Process.GetProcesses();

foreach (Process proc in procs)

{

try

{

Mutex.OpenExisting(@"Global\" + "Visual Studio Tools for Applications Host Process" + proc.Id.ToString());

//we identified host application process via the global mutex it created with its own procid

vstaHostProc = proc;

break;

}

catch (Exception)

{

//if no mutex, then try the next proc

}

if (vstaHostProc != null)

{

//create an exclusive VSTAHostMonitorMutex, based on unique PID, to assure that only one monitor thread exists

try

{

Mutex.OpenExisting(@"Global\" + "Visual Studio Tools for Applications Host Monitor" + vstaHostProc.Id.ToString());

}

catch (Exception)

{

//first instance creating this unique mutex, so create monitor thread

VSTAHostMonitorMutex = new Mutex(true, @"Global\" + vstaHostProc.Id.ToString());

//thread will wait on host mutex for host to terminiate terminate vsta.exe (IDE) if needed

ThreadStart MonitorThread = new ThreadStart(MonitorThreadMethod);

Thread t = new Thread(MonitorThread);

t.Start();

}

#endregion IInProcessHost Members

#region MonitorThread

public static void MonitorThreadMethod()

{

//Console.WriteLine("VSTA.exe Monitor thread - Started");

{

//monitoring thread opens the first global mutex, named after the vstaHostProcID, and waits for it

try

{

VSTAHostMutex = Mutex.OpenExisting(@"Global\" + "Visual Studio Tools for Applications Host Process" + vstaHostProc.Id.ToString());

VSTAHostMutex.WaitOne();

//proper shutdown does not require call to

//TerminateVSTA();

}

catch (AbandonedMutexException)

{

//If I get an Abandoned mutex exception, it means that the host app has crashed without releasing properly the global mutex.

//Hence I quit the DTE. . . . .

TerminateVSTA();

}

catch (Exception)

{

//If it cannot be opened (exception), it is a fatal error. . . . .

TerminateVSTA();

}

finally

{

//Otherwise, my host's mutex was released properly at the end of life of the host app,

//I release it too properly and exit my thread. . . . .

VSTAHostMutex.ReleaseMutex();

VSTAHostMutex.Close();

}

//Console.WriteLine("VSTA.exe Monitor thread - Returned");

}

private static void TerminateVSTA()

{

// ...time to close vsta.exe and wind down this thread.

System.Diagnostics.Process vstaProc = System.Diagnostics.Process.GetCurrentProcess();

try

{

if (!vstaProc.HasExited)

{

vstaProc.Kill();

}

else

{

//safety check:

//if no vsta.exe -- vstaProc.HasExited, and somehow this thread is still running, then abort this thread

System.Threading.Thread.CurrentThread.Abort();

}

catch

{

}

#endregion MonitorThread

}

Plain speak on VSTA add-in versioning and compatibility

2009-03-20T15:47:00Z

Recent discussions have helped me clarify this confusing topic of versioning and compatibility. Maybe this will help you too.

VSTA add-ins assemblies are created by building a VSTA add-in project. Add-in assemblies and add-in projects are seperate, but related entities.

1) VSTA Project backwards compatibility – i.e. add-in projects created in older versions of VSTA will open in future version of the VSTA.

§ Supported

2) VSTA Project forwards compatibility – i.e. add-in projects created in newer version of VSTA will open in older versions of the VSTA.

§ Not supported

3) Round-trip compatibility of an project – i.e., a project can open in any version of a VSTA, older or newer.

§ Not supported

4) Binary backwards compatibility of add-in assembly – i.e. add-ins created in older version of VSTA-enabled application can still run without recompilation in future versions of the VSTA-enabled application.

§ Supported

5) Source level, backwards compatibility of add-in assembly (whenever binary compatibility is not required or not an option) – i.e. add-ins created in an older version of VSTA-enabled application must be recompiled to run in a newer version, but no source code needs to change.

§ Supported

6) Binary forwards compatibility where an add-in assembly created in a newer version of VSTA-enabled application can still run against an older version of the app without recompilation, provided that its code logic is aware of the older app’s functional limitations.

§ Supported

7) Round-trip compatibility of an add-in – i.e., an add-in assembly can run in any version of a VSTA-enabled application, older or newer.

§ Supported

Nullable types: Reflection doesn't determine a Nullable type, overloadng is cool solution, but using inferred types is better!

2009-03-05T16:45:00Z

To get the type of a variable, we can usually use instance.GetType(); But for Nullable<T> types, GetType reflection returns the returns the underlying type .

That is:

int i = 0;

isInteger = i.GetType().Equals(typeof(int)); //isInteger == true

but reflection on a Nullable<T> varaible returns the underlying type

Nullable<int> iNullable = 0;

isNullable = iNullable.GetType().Equals(typeof(Nullable<>)); //isNullable == false; GetType returns int32

Overloading is cool way to test for Nullable<T> variable instance, but inferred typing is even better!

//Using overloading, you can determine if a varaible is a nullable type, but you must know all possible test types:

///<summary>Identify a Nullable Type</summary>

public static bool IsNullableType(Nullable<int> n)

{

return true;

}

public static bool IsNullableType(int i)

{

return false;

}

//Using an inferred TypeParam, you can determine if a varaible is a nullable type for any variable type!:

///<summary>Identify a Nullable Type</summary>

public static bool NullableType<T>(T value)

{ var type = typeof(T); return (type.IsGenericType && type.GetGenericTypeDefinition() == typeof (Nullable<>));

}

static void Main()

{

bool isNullable;

int i = 0;

bool isInteger = i.GetType().Equals(typeof(int)); //isInteger == false;

isNullable = IsNullableType(i); //isNullable == false;

isNullable = NullableType(i); //isNullable == false;

Nullable<int> iNullable = 0;

isNullable = iNullable.GetType().Equals(typeof(Nullable<>)); //isNullable == false;

isNullable = IsNullableType(iNullable); //isNullable == true;

isNullable = NullableType(iNullable); //isNullable == true;

Nullable<double> d = 0;

isNullable = d.GetType().Equals(typeof(Nullable<>)); //isNullable == false;

isNullable = IsNullableType(d); //Compiler Error 1 The best overloaded method match for xxx.Program.IsNullableType(int?)' has some invalid arguments

isNullable = NullableType(d); //isNullable == true;

}

Preserving 'hidden' elements in a COM interop assembly

2009-02-06T20:42:00Z

If you are shipping interop assemblies or PIAs of COM type libraries, you may have some elements in your type library marked as hidden. But, C# and VB Intellisense show these hidden elements anyway. This problem can be fixed with some low level work. This information may help you with the task.

To create interop assemblies, Tlbimp.exe takes as input your COM type libraries. Tlbimp.exe does preserve the "hidden" flag in the interop assembly it generates, in fact, the VS 2008 Object Browser correctly interprets the flag but C# and VB Intellisense doesn't.

To fix this problem we must add an attribute to any members in the interop assembly that shouldn’t appear in IntelliSense. Here is the attribute: [System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Never)].

By modifying the interop assembly, we can add this attribute to the interop assembly. Editing an interop assembly is called ‘round-tripping’ the Interop assembly.

‘Round-tripping’ the Interop assembly is accomplished by modifying the IL code of your interop assembly. The IL is generated by feeding ILDASM the interop assembly. Next, add the EditorBrowsable attribute on hidden members in the IL code. Finally re-assemble the IL code into the Interop assembly again. This is quickly described by the authority, Adam Nathan, in this blog, Tricks for Modifying Interop Assemblies and described in detail in the book .NET and COM: The Complete Interoperability Guide by Adam Nathan.

The hidden flag is manifested in interop assembly metadata as a System.Runtime.InteropServices.TypeLibFuncAttribute(64)]where 64 == FUNCFLAGS Enumeration value of FUNCFLAG_FHIDDEN

Like this:

[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType=MethodCodeType.Runtime), DispId(6), TypeLibFunc((short) 0x40)]

void Draw([In] IntPtr hdc);

Here's what I've discovered with my own investigation using the ShapeAppMFC sample:

[Note: the source files -- ShapeAppMFC.idl, ShapeAppMFC.tlb, ShapeAppMFC.interop.dll are all available in the VSTA 2.0 SDK]

1. The ShapeAppMFC sample in the VSTA SDK includes a COM typelibrarywith an interface that has a hidden method marked in the ShapeAppMFC.idl file:

[id(6), helpstring("method Draw"), hidden] HRESULT Draw([in] PVOID hdc);

This method is defined in IDL interface IShape : IDispatch{

[
    object,
    uuid(AA4B9334-63A0-4C8B-AEE1-A759C0E66209),
    dual,
    nonextensible,
    helpstring("IShape Interface"),
    pointer_default(unique)
]
interface IShape : IDispatch{
    [propget, id(1), helpstring("property Color")] HRESULT Color([out, retval] IColorInfo** pVal);
    [propput, id(1), helpstring("property Color")] HRESULT Color([in] IColorInfo* newVal);
    [propget, id(2), helpstring("property Size")] HRESULT Size([out, retval] ISizeInfo** pVal);
    [propput, id(2), helpstring("property Size")] HRESULT Size([in] ISizeInfo* newVal);
    [propget, id(3), helpstring("property Location")] HRESULT Location([out, retval] IPointInfo** pVal);
    [propput, id(3), helpstring("property Location")] HRESULT Location([in] IPointInfo* newVal);
    [propget, id(4), helpstring("property Name")] HRESULT Name([out, retval] BSTR* pVal);
    [id(5), helpstring("method ContainsPoint")] HRESULT ContainsPoint([in] IPointInfo* p, [out,retval] VARIANT_BOOL* retVal);
    [id(6), helpstring("method Draw"), hidden] HRESULT Draw([in] PVOID hdc);
    [id(7), helpstring("method Load")] HRESULT Load(SAFEARRAY(BYTE) savedState);
    [id(8), helpstring("method Save")] HRESULT Save([out, retval] SAFEARRAY(BYTE) *savedState);
    [id(9), helpstring("method Clone")] HRESULT Clone([out, retval] IShape **ppNewShape);
};

2. ShapeAppMFC.idl is used to generate the typelibrary, "ShapeAppMFC.tlb" which I've also attached.

3. ShapeAppMFC.tlb is consumed by tlbimp to generate a PIA, ShapeAppMFC.interop.dll :

call "%WindowsSDKPath%bin\tlbimp" "%ShapeAppDir%\ShapeAppMFC.exe" /out:"%PIADir%\ShapeAppMFC.interop.dll" /keyfile:"%KeyPath%" /primaryI

4. Using .Net Reflector, I open ShapeAppMFC.interop.dll and disassemble the method IShape.Draw, Tools

[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType=MethodCodeType.Runtime), DispId(6), TypeLibFunc((short) 0x40)]

void Draw([In] IntPtr hdc);

5. I noticed that there was a unique TypeLibFunc((short)0x40) in the .NET Reflector dissassembly for ISharp.Draw.

6. This typlibfunc attribute also shows up in VS2008 Object Browser:

void Draw(IntPtr hdc)

Member of ShapeApp.Proxy.IShape

Summary:

method Draw

Attributes:

[System.Runtime.InteropServices.DispIdAttribute(6),

System.Runtime.InteropServices.TypeLibFuncAttribute(64)]

Notice that VS 2008 Object Browser correctly interprets System.Runtime.InteropServices.TypeLibFuncAttribute(64) as a hidden member, and hides the 'Draw()' method unless 'Show Hidden Types and Members' is switched on in the Object Browser Settings. When the 'Draw()' method is shown, it is gray colored

7. MSDN (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.funcflags(VS.71).aspx)

documents the FUNCFLAGS Enumeration value of '60' as the FUNCFLAG_FHIDDEN

Using custom adapters with VSTA 2.0 pipeline - Part 3, the ShapeAppBasicCSharpGenericCollectionIndexAdapter sample

2009-01-26T21:16:00Z

ShapeAppBasicCSharpGenericCollectionIndexAdapter sample

We’ll assume that you’ve looked over the previous sample from part 2

This sample will demonstrate how to pass a System.Collections.Generic.IList<ShapeAppCSharp. Document > instance, as a ‘by reference’ parameter, from an AddIn to ShapeAppBasicCSharp host application. This is accomplished by extending the VSTA pipeline with generic list adapters and converters that provide Host application with a (cross-AppDomain) reference to a generic collection passed from a VSTA AddIn. The host application will, in-turn, populate the AddIn collection parameter with host-side Document objects (as RemoteObject instances).

To illustrate, here's an add-in example calling this[typeof(Document), doctypedocs];:

private void AppAddIn_Startup(object sender, EventArgs e)

{

IList<Document> doctypedocs = new List<Document>();

int count = this[typeof(Document), doctypedocs];

testdoc = doctypedocs[0];

string dwgName2 = doctypedocs[0].Drawings[0].Name;

}

Our design goal is for the Add-in author to pass a generic collection parameter to the host application and receive it back populated with host elements. In this case, we’re using the generic collection ( System.Collections.Generic.IList<Document>) as the parameter passed to the host.

To accomplish this we’ll add a new property to the host class ‘Application’ in the sample’s Application.cs (which contains the main object model class’ source code):

public partial class Application : System.Windows.Forms.IWin32Window

{

public int this[System.Type type, IList<Document> documents]

{

get

{

if (type.FullName.Contains("Document"))

{

// Create a test collection of documents.

IList<Document> tempdocs = new List<Document>();

tempdocs.Add(this.document);

// add test collection of documents to (byref) document collection parameter.

foreach (Document doc in tempdocs)

{

documents.Add(doc);

}

return documents.Count;

}

}. . .

Then we add the host method’s complement into the proxy object model assembly source in the sample’s proxy.cs class, ApplicationEntryPoint:

[global::System.AddIn.Pipeline.AddInBaseAttribute(ActivatableAs = new global::System.Type[] { typeof(ShapeAppCSharp.IShapeAppEntryPoint) })]

public partial class ApplicationEntryPoint : global::ShapeAppCSharp.IShapeAppEntryPoint

{

/*uses Custom Adapter for System.Collections.Generic.IList*/

public int this[System.Type type, System.Collections.Generic.IList<Document> documents]

{

get

{

//IList<Document> adapter returns a RemoteObjectContract-to-Document converter, so we'll get list

System.Collections.Generic.IList<Document> tempdocs = new System.Collections.Generic.List<Document>();

int count = this.RemoteObject[type, tempdocs];

foreach (Document doc in tempdocs)

{

ShapeAppCSharp.AddInSideAdapters.IRemoteObjectContractToViewAddInAdapter adapter = tempdocs[0] as ShapeAppCSharp.AddInSideAdapters.IRemoteObjectContractToViewAddInAdapter;

documents.Add(adapter.GetView());

}

return documents.Count;

//return this.RemoteObject[type, documents];

}

}. . .

Notice that fix-up code replaces the expected return this.RemoteObject[type, documents];

The meta OM method description is included in the abstract proxy class Application:

[global::Microsoft.VisualStudio.Tools.Applications.Runtime.HostTypeAttribute("ShapeAppCSharp, Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.Applic" +

"ation")]

public abstract partial class Application : global::System.MarshalByRefObject, global::System.Windows.Forms.IWin32Window

{

/*uses Custom Adapter for System.Collections.Generic.IList*/

public virtual int this[System.Type type, System.Collections.Generic.IList<Document> documents]

{

[global::Microsoft.VisualStudio.Tools.Applications.Runtime.HostMemberAttribute("Item", BindingFlags = global::System.Reflection.BindingFlags.Instance | global::System.Reflection.BindingFlags.Public | global::System.Reflection.BindingFlags.GetProperty)]

get { throw new global::System.NotImplementedException(); }

}

. . .

Adding IList<Document> to the VSTA Pipeline – bi-directional support

We must use custom adapters to pass the System.Collections.Generic.IList<Document> type through the VSTA pipeline from addIn to host as a reference parameter. The host must be able to alter the collection’s contents. This is accomplished by overriding, or hooking into the standard VSTA pipeline’s view, host adapter, and addin adapter assemblies.

To do this, I revised the pipeline segment assemblies created previously in my part 2 sample.

Let’s watch it all go…

We’ll look at these interesting snippets in the sequence called by from the AddIn code:

int count = this[typeof(Document), doctypedocs];

HostTypeMapProvider’s GetTypeForCanonicalName:

In the HostTypeMapProvider’s GetTypeForCanonicalName(), we add the VSTA generated -canonical name mapping for IList<Document> , the type our addIn passes as parameter. This causes, ProxyResolve, and AdapterResolve to be fired when passing parameter types with a canonical name that does not exist in the host type map.

public System.Type GetTypeForCanonicalName(string canonicalName)

{

if (canonicalName == "Microsoft.VisualStudio.Tools.Applications.Adapter.v9.0, Microsoft.VisualStudio.Tools.Applications.DynamicProxy`1[[System.Collections.Generic.IList`1[[Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.Document, ShapeAppCSharpProxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c3c0c46dd27dbcf]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]")

{

return typeof(System.Collections.Generic.IList<Document>);

}

//default fetch from the dictionary

if (canonicalToTypeName.ContainsKey(canonicalName))

{

return canonicalToTypeName[canonicalName];

}

return null;

}

AddIn-side AdapterResolve:

When the AddIn passes a generic collection parameter to the host for its use, the VSTA pipeline calls TypeInfrastructureManager_AdapterResolve to explicitly resolve the IList<Document> type, and pass a collection contract adapter to the host AppDomain.

void TypeInfrastructureManager_AdapterResolve(object sender, AdapterResolveEventArgs e)

{

if (typeof(System.Collections.Generic.IList<Document>).IsAssignableFrom(e.ExpectedType))

{

e.AdapterToReturn = System.AddIn.Pipeline.CollectionAdapters.ToIListContract<Document, RemoteObjectAdapter>(e.ObjectToPack as System.Collections.Generic.IList<Document>, DocumentAddInAdapter.ViewToContractAdapter, DocumentAddInAdapter.ContractToViewAdapter);

}

Host-side ProxyResolve:

When the host receives the IListContract from the AddIn-side adapter, the VSTA pipeline calls TypeInfrastructureManager_ProxyResolve to resolve AddIn’s IListContract to a Document List passed to the host application.

[Find in ShapeAppCSharp.HostSideAdapters.IShapeAppEntryPointHostAdapter. TypeInfrastructureManager_AdapterResolve()]

void TypeInfrastructureManager_ProxyResolve(object sender, ProxyResolveEventArgs e)

{

if (e.Adapter is System.AddIn.Contract.IListContract<RemoteObjectAdapter>)

{

e.ProxyToReturn = System.AddIn.Pipeline.CollectionAdapters.ToIList<RemoteObjectAdapter, Document>(e.Adapter as System.AddIn.Contract.IListContract<RemoteObjectAdapter>, DocumentHostAdapter.ContractToViewAdapter, DocumentHostAdapter.ViewToContractAdapter);

}

DocumentHostAdapter:

The host application populates the generic document list, via ContractListAdapter. When populated, System.AddIn.Pipeline.ListContractAdapter, in turn, hooks up Document pipeline segments to make host documents added into the document list available to the AddIn via a DocumentViewToContractHostAdapter.

[Find in ShapeAppCSharp.HostSideAdapters]

public class DocumentHostAdapter

{

internal static RemoteObjectAdapter ViewToContractAdapter(Document view)

{

if (view.GetType().Equals(typeof(IRemoteObjectContractToViewHostAdapter)))

{

return ((IRemoteObjectContractToViewHostAdapter)(view)).GetSourceContract();

}

else

{

return new DocumentViewToContractHostAdapter(view);

}

DocumentAddInAdapter:

Next, the System.AddIn.Pipeline.ListContractAdapter passes the RemoteObjectAdapter contract to the AddIn-side Document adapter which holds the contract until the Addin uses one of the Document elements in the generic collection.

public class DocumentAddInAdapter

{

internal static Document ContractToViewAdapter(RemoteObjectAdapter contract)

{

if (((System.Runtime.Remoting.RemotingServices.IsObjectOutOfAppDomain(contract) != true)

&& contract.GetType().Equals(typeof(DocumentViewToContractAddInAdapter))))

{

return ((DocumentViewToContractAddInAdapter)(contract)).GetSourceView();

}

else

{

return new IRemoteObjectContractToViewAddInAdapter(contract);

}

IRemoteObjectContractToViewAddInAdapter

To use the Documents in its generic Document collection, the Addin calls the contract to view converter: IRemoteObjectContractToViewAddInAdapter. This code converts the RemoteObjectAdapter contract to a Document proxy object. It is called from the addIn’s proxy class ApplicationEntryPoint.

public class IRemoteObjectContractToViewAddInAdapter : Document

{

private RemoteObjectAdapter _contract;

private System.AddIn.Pipeline.ContractHandle _handle;

static IRemoteObjectContractToViewAddInAdapter()

{

}

public IRemoteObjectContractToViewAddInAdapter(RemoteObjectAdapter contract)

{

_contract = contract;

_handle = new System.AddIn.Pipeline.ContractHandle(contract);

}

// convert RemoteObjectAdapter contract list element to a Document instance

public Document GetView()

{

System.AddIn.Contract.IContract roc = _contract.QueryContract(typeof(System.AddIn.Contract.Automation.IRemoteObjectContract).AssemblyQualifiedName);

return TypeServices.ObjectFromContract(roc, typeof(Document), IShapeAppEntryPointAddInAdapter.tim) as Document;

}

In conclusion

ShapeAppBasicCSharpGenericCollectionIndexAdapter shows the use of custom adapters, tightly integrated with the ShapeAppBasicCSharp object model types and the VSTA pipeline, to pass a custom type (generic Document list) as a parameter from the addIn to the host. By hooking System.AddIn.Pipeline.CollectionAdapters and converters into the VSTA pipeline, and using RemoteObjectAdapters to marshal Document instances across the AppDomain as list elements, the VSTA pipeline is extended, making it possible for the AddIn to create a generic Document list, pass the Document list to the host application and receive it back, populated with host documents. By testing, we demonstrated that bi-directional support for IList<Document>, is available to the VSTA Add-In author.

Sequential Description of Host Automation via System.AddIn

2009-01-20T02:54:00Z

Add-in activation

Host app calls System.AddIn.Hosting.AddInToken.Activate.

System.AddIn Activate, loads the Add-in.dll creating addin instance that implements the Add-In (entrypoint) interface.

Next, System.AddIn loads AddInSideAdapter.dll creating Add-In side Automation Adapter and passes it the AddIn instance to hold as the view.

Add-In side Automation Adapter implements the Automation (entrypoint) contract.

Next, System.AddIn creates a Host-side automation adapter and passes it the AddIn-side adapter instance to hold as the add-in-side contract.

Host-side Automation Adapter implements the Automation view.

Add-in initialization

Host app calls Automation initialize method of Host-side adapter (view), passing host object model (view) instance as parameter.

Host-side automation adapter converts host objectmodel view to objectmodel contract by creating instance of Object model host adapter contract.

Object model host adapter contract holds host Object model view instance.

Host-side adapter (view) calls AddIn side automation adapter (contract) initialize method, passing object model host adapter contract instance as parameter.

Add-in side automation adapter contract Initialize converts Objectmodel host adapter contract to add-in adapter view by creating instance of Object model addin adapter contract.

Object model AddIn adapter view holds host-side adapter object model contract.

AddIn side automation adapter calls Add-in (view) Initialize method, passing object model addIn adapter (view) instance.

Host Automation via method call

Add-in automates host by calling method on object model addin adapter (view).

Add-in side object model adapter (view) method calls host-side adapter object model contract instance method.

Host-side adapter object model contract method calls host app object model (view) method.

Host Automation via method call with parameter

Add-in automates host by calling method on object model addin adapter (view) with custom type parameter view.

Add-in side object model adapter (view) method converts custom type view to add-in side custom type contract parameter.

Add-in side object model adapter (view) method calls host-side adapter object model contract instance method with add-in side custom type contract parameter.

Host-side adapter object model contract method converts add-in side custom type contract parameter to host-side adapter view type parameter.

Host-side adapter object model contract method calls host app object model (view) method with host-side adapter view type parameter.

Using custom adapters with VSTA 2.0 pipeline - Part 2, the ShapeAppBasicCSharpGenericCollectionAdapter sample

2009-01-19T19:44:00Z

ShapeAppBasicCSharpGenericCollectionAdapter sample

This sample shows how to pass a System.Collections.Generic.IList<ShapeAppCSharp. Document > instance from the ShapeAppBasicCSharp host application to its add-in by extending the VSTA pipeline with adapters The list provided to the add-in is a generic, non-serialized list of Document objects that actually exist in the host application.

To illustrate, here's an add-in example calling this.GetDocuments();:

private void AppAddIn_Startup(object sender, EventArgs e)

{

// get list of documents from the host

System.Collections.Generic.IList<Document> documents = this.GetDocuments();

Document document = documents[0];

string dwgName1 = document.Drawings[0].Name;

}

Adding IList<Document> to the ShapeAppCSharp object model

In the ShapeAppBasicCSharp SDK sample, the type Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp. Document is already represented on the proxy side with this type definition (generated by proxygen):

[assembly: global::Microsoft.VisualStudio.Tools.Applications.Runtime.HostAssemblyAttribute()]

namespace Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp

{

[global::Microsoft.VisualStudio.Tools.Applications.Runtime.HostTypeAttribute("ShapeAppCSharp, Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.Docume" +

"nt")]

public abstract partial class Document : global::System.MarshalByRefObject

{...}

}

Our design goal is for the Add-in author to pass instances of ShapeApp's host-side Document type (via add-in side proxy Document type) from host to add-in, within a generic collection: System.Collections.Generic.IList<Document>

To accomplish this we’ll add a new GetDocuments() method to the host class ‘Application’ in the sample’s Application.cs (which contains the main object model class’ source code):

public partial class Application : System.Windows.Forms.IWin32Window

{

IList<Document> docs = null;

public IList<Document> GetDocuments()

{

// for simplicity, we’ll return the default document in the IList

if (docs == null)

{

docs = new List<Document>();

docs.Add(this.document);

}

return docs;

}

. . .

Then we add the host method’s complement into the proxy object model assembly source in the sample’s proxy.cs class, ApplicationEntryPoint:

[global::System.AddIn.Pipeline.AddInBaseAttribute(ActivatableAs = new global::System.Type[] { typeof(ShapeAppCSharp.IShapeAppEntryPoint) })]

public partial class ApplicationEntryPoint : global::ShapeAppCSharp.IShapeAppEntryPoint

{

/*uses Custom Adapter for System.Collections.Generic.IList*/

public System.Collections.Generic.IList<Document> GetDocuments()

{

return this.RemoteObject.GetDocuments();

}

. . .

Notice a new entry point interface: global::ShapeAppCSharp.IShapeAppEntryPoint (which we’ll define later), is implemented by ApplicationEntryPoint.

The meta OM method description is included in the abstract proxy class Application:

[global::Microsoft.VisualStudio.Tools.Applications.Runtime.HostTypeAttribute("ShapeAppCSharp, Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.Applic" +

"ation")]

public abstract partial class Application : global::System.MarshalByRefObject, global::System.Windows.Forms.IWin32Window

{

/*uses Custom Adapter for System.Collections.Generic.IList*/

[global::Microsoft.VisualStudio.Tools.Applications.Runtime.HostMemberAttribute("GetDocuments", BindingFlags = global::System.Reflection.BindingFlags.Instance | global::System.Reflection.BindingFlags.Public | global::System.Reflection.BindingFlags.InvokeMethod)]

public virtual System.Collections.Generic.IList<Document> GetDocuments() { throw new global::System.NotImplementedException(); }

. . .

Adding IList<Document> to the VSTA Pipeline

Since generic collections are not supported with the VSTA proxy/runtime, we cannot simply add the type System.Collections.Generic.IList<Document> into the HostTypeMapProvider as one would normally do to support a new type in their object model.

Instead, we must use custom adapters to pass the System.Collections.Generic.IList<Document> type through the VSTA pipeline from host to addIn. This is accomplished by overriding, or hooking into the standard VSTA pipeline’s view, host adapter, and addin adapter assemblies.

How the VSTA pipeline segments work together

VSTA 2.0 add-ins are System.AddIn add-in assemblies. System.AddIn add-in assemblies are discovered and activated (loaded) by the host application using a special protocol contained in System.AddIn.AddInToken.Activate, which is called by the host application to initialize the pipeline: First, System.AddIn loads the add-in, which in turn, loads its ‘view’ pipeline segment (aka: the ‘proxy’ assembly); System.AddIn creates the addIn-side adapter ‘contract’ pipeline segment, passing an instance of the add-in’s view segment; System.AddIn creates the host-side adapter ‘view’ pipeline segment, passing a remote instance of the addIn-side adapter contract; Finally, System.AddIn’s AddInToken Activate<IShapeAppEntryPoint> method returns the host-side adapter ‘view’ to the host as an IShapeAppEntryPoint instance, which the host considers to be the add-in it loaded. This completes the pipeline initialization, with all pipeline segments holding its neighbor segment, linked from addin back to the host. When the host releases the host-side adapter instance, the pipeline segments are disposed of in reverse sequence and the add-in unloads from memory.

I created the pipeline segment assemblies using the System.AddIn Tools and Samples pipeline generator utility, which is fed this contract definition to create the rest of the pipeline segments:

namespace ShapeAppCSharp.Contracts

{

[AddInContract]

public interface IShapeAppEntryPointContract : IContract

{

void HookCustomAdapter();

}

After the bare bones pipeline is generated, we edit all the segments to implement the standard VSTA pipeline IEntryPointContract2.

Contract:

namespace ShapeAppCSharp.Contracts

{

[AddInContract]

public interface IShapeAppEntryPointContract : IEntryPointContract2

{

void HookCustomAdapter();

}

Notice that the contract segment now implements IEntryPointContract2

View:

namespace ShapeAppCSharp

{

[System.AddIn.Pipeline.AddInBaseAttribute()]

public interface IShapeAppEntryPoint : IExtendedEntryPoint

{

void HookCustomAdapters();

}

IShapeAppEntryPoint interface type is the view of the pipeline ‘seen’ by both the host and add-in.

Host-side Adapter:

namespace ShapeAppCSharp.HostSideAdapters

{

[System.AddIn.Pipeline.HostAdapterAttribute()]

public class IShapeAppEntryPointHostAdapter : Microsoft.VisualStudio.Tools.Applications.EntryPointHostAdapter, ShapeAppCSharp.IShapeAppEntryPoint

{

//Implement view: IShapeAppEntryPoint

public void HookCustomAdapters()

{

if (this.TypeInfrastructureManager != null)

{

this.TypeInfrastructureManager.AdapterResolve += new EventHandler<AdapterResolveEventArgs>(TypeInfrastructureManager_AdapterResolve);

}

_contract.HookCustomAdapter();

}

Notice that the Host-side adapter is a view that derives from VSTA’s EntryPointHostAdapter and implements a view IShapeAppEntryPoint . This is the face of the VSTA pipeline seen by the host.

AddIn-Side Adapter:

namespace ShapeAppCSharp.AddInSideAdapters

{

[System.AddIn.Pipeline.AddInAdapterAttribute()]

public class IShapeAppEntryPointAddInAdapter : Microsoft.VisualStudio.Tools.Applications.AddInAdapter, ShapeAppCSharp.Contracts.IShapeAppEntryPointContract

{

public virtual void HookCustomAdapter()

{

if (this.TypeInfrastructureManager != null)

{

this.TypeInfrastructureManager.ProxyResolve += new EventHandler<ProxyResolveEventArgs>(TypeInfrastructureManager_ProxyResolve);

}

Notice that the AddIn-side adapter is a contract that derives from VSTA’s AddInAdapter and implements a contract IShapeAppEntryPointContract. This contract is the segment of the VSTA pipeline seen by the addIn’s view (the ShapeAppCSharp proxy, in proxy.cs).

AddIn-side View (proxy.cs)

public partial class ApplicationEntryPoint : global::ShapeAppCSharp.IShapeAppEntryPoint

Notice that the proxy assembly implements the view IShapeAppEntryPoint

AddIn Entry Point (.designer.cs)

namespace ShapeAppCSharpAppAddIn {

[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Tools.Applications.ProgrammingModel.dll", "9.0.0.0")]

public sealed partial class AppAddIn : Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.ApplicationEntryPoint, ShapeAppCSharp.IShapeAppEntryPoint

{

Notice that the AddIn entrypoint class derives from ApplicationEntryPoint , as expected, and as implemented in the proxy assembly (the pipeline view segment with new GetDocuments() method described above), and explicitly implements the new view ShapeAppCSharp.IShapeAppEntryPoint.

**Note: Each of these assemblies are completely implemented in the sample.

To load an add-in that implements the ShapeAppCSharp.IShapeAppEntryPoint , the host application must discover and activate (load) those kinds of AddIns:

Host application (VstaRuntimeIntegration.cs)

private bool LoadAddIn(string addInPath, string startUpClass)

{

// Update VSTA pipeline.

string[] warnings2 = AddInStore.Update(AddInStoreExtensions.DefaultPipelinePath);

if (warnings2.Length > 0)

{

foreach (string one in warnings2)

{

Console.WriteLine(one);

}

try

{

Collection<AddInToken> addInToken = AddInStore.FindAddIn(typeof(IShapeAppEntryPoint), AddInStoreExtensions.DefaultPipelinePath, addInPath, startUpClass);

. . .

IShapeAppEntryPoint addIn = addInToken[0].Activate<IShapeAppEntryPoint>(AddInSecurityLevel.FullTrust);

// Initialize AddIn by calling into functions of the AddIn EntryPoint instance.

addIn.Initialize(this.serviceProvider);

addIn.HookCustomAdapters();

Notice that the VSTA pipeline is updated by calling AddInStore.Update, to include the new segments copied into the appropriate VSTA pipeline subdirectories.

Notice that the kind of Add-ins to be found and activated must connect with the host application via a host view adapter that implements: typeof(IShapeAppEntryPoint). Earlier we noticed that IShapeAppEntryPoint view is implemented by our host-side adapter pipeline segment.

Notice that after the normal addIn.Initialize(), the host calls addIn.HookCustomAdapters, which calls similar methods from host-side adapter to addIn-side adapter, hooking up the VSTA runtime’s TypeInfrastructureManager events needed to move the document list (System.Collections.Generic.IList<Document>) from host to add-in.

Execution of this.GetDocuments();

Let’s watch it all go…

When, the host application calls addIn.FinishInitialization();, the add-in’s AppAddIn_Startup() event is fired and this.GetDocuments(); executes. This results in a remoteObject. GetDocuments() call to the host Application. GetDocuments() method.

AddIn code execution:

private void AppAddIn_Startup(object sender, EventArgs e)

{

System.Collections.Generic.IList<Document> documents = this.GetDocuments();

Document document = documents[0];

string dwgName1 = document.Drawings[0].Name;

}

Host-side AdapterResolve:

When the host application passes a type back to the Add-in, the VSTA pipeline calls TypeInfrastructureManager_AdapterResolve to resolve Host-Side types that are not in the HostTypeMap and pass their host adapters across the AppDomain boundary to the Add-In. In this example, the type that is resolved and passed is System.Collections.Generic.IList<Document>. The generic Document list elements are enumerated, wrapped in a list of RemoteObjectAdapter, and passed across the AppDomain boundary via System.AddIn.Pipeline.CollectionAdapters.ToIListContract.

void TypeInfrastructureManager_AdapterResolve(object sender, AdapterResolveEventArgs e)

{

if (typeof(System.Collections.Generic.IList<Document>).IsAssignableFrom(e.ExpectedType))

{

IRemoteObjectContract[] remoteObjectContractArray = null;

List<System.AddIn.Contract.Automation.IRemoteObjectContract> remoteObjectContractList = new List<System.AddIn.Contract.Automation.IRemoteObjectContract>();

//create list of contracts from objects

foreach (object obj in (System.Collections.Generic.IList<Document>)e.ObjectToPack)

{

remoteObjectContractList.Add(new RemoteObjectAdapter(obj.GetType(), obj, this.TypeInfrastructureManager));

}

remoteObjectContractArray = remoteObjectContractList.ToArray();

e.AdapterToReturn = System.AddIn.Pipeline.CollectionAdapters.ToIListContract<IRemoteObjectContract>

((List < System.AddIn.Contract.Automation.IRemoteObjectContract >) remoteObjectContractList);

}

AddIn-side ProxyResolve:

When the host-side add-in adapter’s TypeInfrastructureManager_AdapterResolve event handler completes, the VSTA pipeline calls TypeInfrastructureManager_ ProxyResolve to explicitly resolve host Adapter contracts to Add-in Side adapters, which yield types defined in the Add-in proxy (also called the AddIn-Side ‘View’). Then the proxy can pass them to the Add-in.

In this contract the type resolved and passed is System.AddIn.Contract.IListContract<System.AddIn.Contract.Automation.IRemoteObjectContract>. The generic IListContract is converted to IList of RemoteObjectAdapters, each containing a document element references connected to the host side . The RemoteObjectAdapters yield their Document objects, which populate a new IList<Document> which the proxy passes to the Add-In, completing this.GetDocuments();.

void TypeInfrastructureManager_ProxyResolve(object sender, ProxyResolveEventArgs e)

{

if (e.Adapter is System.AddIn.Contract.IListContract<System.AddIn.Contract.Automation.IRemoteObjectContract>)

{

IList < System.AddIn.Contract.Automation.IRemoteObjectContract > remoteObjectContractList =

System.AddIn.Pipeline.CollectionAdapters.ToIList<IRemoteObjectContract>(e.Adapter as System.AddIn.Contract.IListContract<IRemoteObjectContract>);

IList<Document> docs = new List<Document>();

//create list of objects from adapters

foreach (RemoteObjectAdapter roa in remoteObjectContractList)

{

System.AddIn.Contract.IContract roc = roa.QueryContract(typeof(System.AddIn.Contract.Automation.IRemoteObjectContract).AssemblyQualifiedName);

Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.Document doc = TypeServices.ObjectFromContract(roc, typeof(Document), this.TypeInfrastructureManager) as Document;

docs.Add(doc);

}

e.ProxyToReturn = docs;

}

In conclusion

ShapeAppBasicCSharpGenericListAdapter shows the use of custom adapters, tightly integrated with the ShapeAppBasicCSharp object model types and the VSTA pipeline, to pass a custom type (generic Document list) across the host/add-in appdomain boundary. By hooking System.AddIn.Pipeline.CollectionAdapters into the VSTA pipeline, and using RemoteObjectAdapters to marshal Document instances across the AppDomain as list elements, the VSTA pipeline is extended, making it possible for the AddIn to automate a generic collection of non-serializable Document objects on the host-side. By testing, we confirmed that a new Host API type, IList<Document>, is available to the VSTA Add-In author.

In the my next post (part 3) we'll demonstrate passing Generic collections from the AddIn to the Host application by reference.

Using custom adapters with VSTA 2.0 pipeline - Part 1

2009-01-19T19:39:00Z

The VSTA team provides an overview on how to hook custom adapters with VSTA pipeline here

After ~5 minutes of idle time debugging macro projects fails with an IPC Port error.

2008-10-22T20:00:00Z

After ~5 minutes of idle time, VSTA macro projects are unable to debug and VSTA IDE displays a “Failed to write to an IPC Port: The pipe is being closed” or similar. Second attempt produces this error message “Requested Service not found” error message dialog. Loaded add-ins do not timeout (that was fixed in .Net 3.5 SP1).

Periodically ‘Start Debugging’ manually or programmatically (DTE.Debugger.Go()) debugging the open project prevents this problem from occurring, but this not an acceptable workaround .

Steps to repro:

1) Build the ShapeAppMacroRecordingCSharp sample.

2) Run the associated setup .js file.

3) Run the ShapeAppMacroRecordingCSharp sample.

4) Launch the IDE.

5) Set a break point in the OnStartup method of the ide.

6) Debug from the IDE and confirm the break point is hit when debugging.

7) Leave the host application and IDE idle for 5 minutes or more.

8) ‘Start’ Debug from the IDE: “Failed to write to an IPC Port: The pipe is being closed” message will appear.

9) ‘Start’ Debug from the IDE again: “Requested Service not found” message will appear.

Solution:

This is a bug in the sample. The ShapeAppMacroRecordingCSharp sample should add InitializeLifetimeService() method with infinite timeout to the class VstaDesignTimeIntegration as shown below

/// <summary>

/// Provides Designtime VSTA Integration for ShapeAppCSharp.

/// </summary>

internal sealed class VstaDesignTimeIntegration : MarshalByRefObject, IExternalDebugHost

{

#region MarshalByRefObject

public override object InitializeLifetimeService()

{

return null; // Allows remoting from VS as long as we live.

}

#endregion MarshalByRefObject public override object InitializeLifetimeService()

. . .

Sample: Watchdog to terminate orphaned VSTA process

2008-09-26T18:43:00Z

This is an IPH sample, IPHTerminateOrphanedVSTA. It uses a global mutext to start one, and only one, simple observer thread. The observer thread continues to execute while the vsta process is alive, whether or not a project is open.. The observer thread periodically checks for existence of the hostProcess. If there is no hostProcess running, and there is an orphaned vsta.exe, the observer thread shuts down the orphan vsta process before exiting. The IPH allows opening the VSTA as a standlone IDE (observer thread is not started).

Add your proxy assemblies to .NET Add Reference tab in Visual Studio/VSTA IDE

2008-04-04T13:49:00Z

Your VSTA Project template includes a reference to your proxy assembly. If the end user manually deletes the proxy assembly reference, they will not find the proxy assembly listed under the .NET tab.

To add your own assemblies to the .NET tab

Create a new registry key (for example, one called ProxyAssembly) beneath either of the following registry keys:
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\AssemblyFolders
HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\AssemblyFolders

Set the new key's default value to point to the folder that contains your assemblies.

For instance:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyProxy]
@="C:\\Documents and Settings\\gdepue\\Desktop\\VSTA2.0Samples\\ShapeAppBasicMFC\\Proxy\\bin\\Debug"

If you have Visual Studio/VSTA IDE open, you must close it and then launch it again for the change to take effect.

VSTO/VSTA Power Tools v1.0

2008-03-28T14:02:00Z

Andrew Whitechapel announces VSTO/VSTA Power Tools for developers working with VSTA which includes the Pipeline Verifier.

VSTO/VSTA Pipeline Verifier

A GUI tool that reflects over custom pipeline assemblies to validate the complete VSTA pipeline.

Standalone Windows Forms application.

Download the Power Tools here

ISV's proxy assemblies and references to proxy assemblies in add-in project templates and projects require unique version information

2008-03-13T22:29:00Z

Description of the problem:

On a machine with VSTA v1 and VSTA v2 installed, compile the v2 ShapeAppCSharpAppAddIn project in the basic shapes sample. You'll get this error:

Error 1 The type or namespace name 'ApplicationEntryPoint' does not exist in the namespace 'Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp' (are you missing an assembly reference?) C:\ShapeAppSamples\ShapeAppBasicCSharp\sample addIns\CSharp\AppLevel\SampleAppAddIn.Designer.cs 16 103 ShapeAppCSharpAppAddIn

There is similar problem in other samples, ie: Dynamic shapes sample ('DocumentEntryPoint')

Repro Steps:

1. Create machine with VSTA 1.0 and VSTA 2.0 installed side by side.

2. Install VSTA v 2, ShapeAppCSharp sample

3. Open v2 ShapeAppCSharp sample add-in project and build.

4. Build fails due to incorrect proxy assembly reference in the add-in project.

Why the failure?:

ProjectGen creates the project templates with an indeterminate reference to the proxy like this in shapeappcsharpappaddin.csproj:

Unfortunately, ProjectGen does not generate other the assembly attributes. It should include the version number, at the least.

This ambiguity will cause build errors or runtime errors for a VSTA add-in.

As noted: for version 2 VSTA add-in sample projects, the add-in projects incorrectly resolve the ShapeAppCSharpProxy reference to the VSTA v 1 reference if it is available.

( Even without a new version number, the ShapeAppCSharpProxy assembly reference in the shapeappcsharpappaddin.csproj in the exsiting shapeappcsharpappaddin.csproj can be made distinct enough by specifying the unique PublicKeyToken

<Reference Include="ShapeAppCSharpProxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c3c0c46dd27dbcf" /> )

Impact on ISVs integrating VSTA:

This is an important issue to resolve because ISVs must properly create vNext proxy assemblies and project templates for each version of their application.

ISVs must properly create vNext proxy assemblies and project templates so that when end users update their application, they will not encounter a problem building their add-in projects, new and existing, due to the project referencing the wrong version of a proxy assembly.

Renaming the proxy assembly for each version is not a desireable solution, from a maintenance perspective, but versioning the assembly is.

Steps to proper resolution of proxy assembly ambiguity:

1. Version your proxy assembly.

Using the SDK sample proxy and addin project shapeappcsharpappaddin.csproj as an determinate example, we should

A. update the version of the proxy assembly (ie: ShapeAppCSharpProxy, Version=2.0.0.0) and

B. include the correct version in the add-in project's reference to the ShapeAppCSharpProxy.dll:

shapeappcsharpappaddin.csproj, referencing version 1 proxy assembly:

shapeappcsharpappaddin.csproj, referencing version 2 proxy assembly

2. There are other assembly reference attributes that ISVs might use to uniquely reference proxy assembly in their projects:

A. If version-specific proxy assemblies are installed SxS in the GAC, they could use FusionName.

B. For a SxS proxy assembly installed to a known ISV/product location, they can provide a HintPath to the correct assembly location.

For example, in shapeappcsharpappaddin.csproj:

<Name>ShapeAppCSharpProxy</Name>

<Aliases>ShapeApp Automation Library</Aliases>

<FusionName>ShapeAppCSharpProxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c3c0c46dd27dbcf</FusionName>

<HintPath>C:\Program Files\ISVName\ShapeAppCSharpProxy\Common\VSTA\ShapeAppCSharpProxy.dll</HintPath>

</Reference>

3. Version information added to the project's assembly references should be included in the project template's copy of the project (.csproj or .vbproj) file. This will create new projects with non-ambiguous assembly references