Gary Depue's VSTA Blog

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

Gary — Wed, 22 Oct 2008 20:00:00 GMT

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

Gary — Fri, 26 Sep 2008 18:43:00 GMT

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

Gary — Fri, 04 Apr 2008 13:49:00 GMT

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

Gary — Fri, 28 Mar 2008 14:02:00 GMT

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

Gary — Thu, 13 Mar 2008 22:29:00 GMT

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

InvalidOperationException: Cross-thread operation not valid: Control 'ShapeAppForm' accessed from a thread other than the thread it was created on.

Gary — Fri, 07 Mar 2008 15:17:00 GMT

I created this macro in SDK sample Shapeappmacrorecordingcsharp and built it:

       public void Macro3()
        {
            this.Visible = false;//<=set break point here
            this.Visible = true;
        }

1 Launch the IDE (out of process) from ShapeApp
2 Set breakpoint at this.Visible = false;
3 'Start Debugging' the macro project
4 Open the application's MacroManager
5 Run Macro3 and hit breakpoint at this.Visible = false;
6 F10 or Run produces this error:

"InvalidOperationException: Cross-thread operation not valid: Control 'ShapeAppForm' accessed from a thread other than the thread it was created on."

To 'fix' this, I set a property on ShapeAppForm: CheckForIllegalCrossThreadCalls = false;

         /// <summary>
        /// Internal constructor for this form.
        /// </summary>
        /// <param name="application">The active ShapeApp application instance.</param>
        internal ShapeAppForm(Application application)
        {
            CheckForIllegalCrossThreadCalls = false;
            InitializeComponent();
            this.application = application;

            sizeDialog = new SizeDialog();
            locationDialog = new LocationDialog();
        }

Re-build shapeappmacrorecordingcsharp, run and repeat steps 1-6
And there's no error.

But cross thread calls to winform UI "often leads to unpredictable results"
This means that when ISVs want to support robust OOP debugging, they need to use thread safe calls on their UI, which is demonstrated with the MacroDialog, but not in the rest of the UI that can be called from an Add-in.

For this one case, adding the asynch/thread safe Invoke to the Application Form did not work :

public new bool Visible

{

get

{

return this.Visible;

}

set

{

SetVisibleTS(value);

}

public delegate void VisibleDelegate(bool isVisible);

public void SetVisibleTS(bool isVisible)

{

if (InvokeRequired)

{

VisibleDelegate d = new VisibleDelegate(SetVisibleTS);

Invoke(d, new object[] { true });//Nope, this just hangs

}

else this.Visible = true;

}

so I'll have to look further and find something that does work:

ObjectModel Documentation

Gary — Thu, 07 Feb 2008 22:47:00 GMT

You've commented your ObjectModel thoroughly and now found out, that the Intellisens in the VSTA add-in doesn't show it.

Is there a way to make the Object Model comments of each class and member available into the proxy?

Answer: /doc (Process Documentation Comments) (C# Compiler Options)

This approach won’t require you to duplicate the comments in the proxy source. Which is nice.

For the ShapeAppCSharp sample, I 'checked' the ‘XML documentation file’ output property of the ShapeAppBasicCSharp (host application) project which contains the sample’s object model (open the project properties, select the Build tab, and select the checkbox for ‘XML documentation file’ -- the last entry under the 'Output' category).

This setting generates an xml file during build time that can be used for intellisense and object browser documentation.

Now we’ll play a trick and use this file for the proxy assembly:

1. I changed the name of this file to ‘ShapeAppCSharpProxy.XML’ and edited the contents to rename the ‘assembly’name attribute to match the file name: ‘ShapeAppCSharpProxy’ as shown here:

<?xml version="1.0"?>

<doc>

<name>ShapeAppCSharpProxy</name>

</assembly>

2. Then I copied this XML documentation file into the same folder as the registered proxy assembly: \Proxy\bin\Debug\ShapeAppCSharpProxy.dll

3. Now, if I reset a reference to the proxy assembly in my addin project (ShapeAppCSharpProxy.dll), this XML file will be used for intellisense and object browser documentation. You can also edit the documentation file to match the proxy source more closely.

Watch out, though. If you rebuild the proxy asssembly, the documentation file will be erased, so you should keep te master copy in another place and copy the file into the proxy assembly folder as a post build step.

How to Integrate VSTA 2.0 (01/23/08 MSDN Webcast)

Gary — Tue, 29 Jan 2008 14:56:00 GMT

MSDN Webcast: How to Integrate Visual Studio Tools for Applications 2.0 (Level 200)
Event ID: 1032362710

Webcast: here

Slides (with presenter's notes): here

Demo Source:

WPF Addin - here

Integration Walkthrough - here

Work around for event-related bugs we noticed in ShapeAppAdvancedMFC Sample

Gary — Thu, 30 Aug 2007 18:24:00 GMT

Bugs we noticed in ShapeAppAdvancedMFC Sample

1. When I File | Open an already created and saved doc from hard drive, it opens once but if I open it again after closing it once, it throws a Debug Assertion Failed error message.

2. If I open a document through File | Open, then close it and again try to open it from the History list that is there in the File menu, the document does not open.

Observation: Problems 2 and 3 can be solved by removing the event handler from the AppAddIns and DocAddIns. i.e., commenting the event handler for the messagebox and the code for the messagebox itself.

Specifically: If we comment the following line in the function "public void AppAddIn_Startup(object sender, EventArgs e)" from the file ‘AppAddIn.cs’:

this.CreatedDrawing += new CreatedDrawingEventHandler(ShapeApp_CreatedDrawing);

If we comment the line from function "public void DocAddIn_Startup(object sender, EventArgs e)" in the file ‘DocAddIn.cs’:

this.ShapeAdded += new ShapeAddedEventHandler(DocAddIn_ShapeAdded);

Without the event handler hookup, the documents open properly.

So it may be that the MFC connection points for events are not releasing properly and that the associated MFC document is not completely released when it is closed by user. When user tries to open the document the second time, it fails with Debug Assert (#1) or silently (#2).

Possible workarounds:

The issue seems to be that the COM adapter is not freeing its native resources on Add In Unload. The best way to verify the same is to make the application sleep after Unload on In Proc addins and before loading the addins in external proc. This does the Revoke on the COM adapter finally releasing the resources and thereafter the event hook up in the modified app seems to work.

1. Have the hook done in the unmanaged way as we do in the C# advanced MFC sample.

2. Increasing time span (sleep) between the unload and load in the external process (not a clean soultion).

Evaluating VSTA Chapter 2

Gary — Wed, 16 May 2007 13:11:00 GMT

(Further observations by our Summer Intern, Harish):

The blog by MSDN for VSTA is a good source for moving ahead with VSTA understanding... http://blogs.msdn.com/VSTA/

After the initial steps we should look at the zipped samples in the VSTA SDK.

The initial two applications (ShapeAppCSharp, ShapeAppMFC) do not integrate VSTA and do not require registration (Registring an applicaiton helps to build and debug the sample add-in, and to use the project templates included with ShapeAppBasicMFC to create our own add-ins.)

To get our hands on it we just need to unzip it and open the Project/Solution, Run the application through F5...

The Basic and Advanced samples integrate VSTA. So we need to register the other sample applications in order to use the add-ins in them. For registering we need to run a java script that is located in the unzipped folder. The steps and commands for executing the script are:

in the command prompt navigate to the unzipped folder where the script is located and then execute
```
cscript SetupShapeAppBasicMFC.js
```
each sample application has a similarly named .js script.

Evaluating VSTA Chapter 1

Gary — Wed, 09 May 2007 18:52:00 GMT

Here are some of the important steps to consider while installing VSTA SDK (as observed by our Summer Intern, Harish):

The initial step is to watch the Intro video http://go.microsoft.com/?linkid=6676089, which gives a quick overview of the basics of VSTA. But does not provide us with enough information about setting up VSTA with pre-installed VS 2005.

After downloading and running 'vsta_sdk.msi', the steps for setting up VSTA with VS 2005 are in a ReadMe file located in a folder :"%SYSTEMDRIVE%\Program Files\Visual Studio 2005 Tools for Applications SDK\2007.02\VisualStudioToolsForApplications".

The two steps described are quite straight forward. But these are the most important steps... especially running the installer file 'vsta_aide.msi' with the command-line parameters "VSTAINVS = 1". This parameter is very important for the VSTA installation and setting up VSTA with VS 2005.

To verify, open the IDE for VS 2005 -> go to "Help" menu and click "About Microsoft Visual Studio". There should be an entry of VSTA as "Microsoft Visual Studio 2005 Tools for Applications" under 'Installed Products'. If that entry is not there then uninstall the SDK and reinstall OR Repair the installation by running "vsta_sdk.msi" again. And then repeat the step of running installer file 'vsta_aide.msi' with command-line parameters "VSTAINVS = 1".

Above all, the best location to start with VSTA (after the SDK installation) is to refer VS 2005 IDE's "Help" menu -> click Contents -> then go down to "Visual Studio 2005 Tools for Applications SDK" in the left pane. It's the most helpful resource (from those I have used) for any VSTA Beginner-level programmer...

Summit has created some excellent micro-sample integrations that are smaller and as such easier to understand than the SDK samples.

For C# managed applications: TestCon - Minimal sample VSTA integration

For C++ COM applications (MFC, ATL): COMClient easy integration - using generic COMProxy and VAO. This sample's approach is also compatible for VBA side-by-side integrations.

For VB6 applications: VB6 COMClient Easy Integration. This sample's approach is also compatible for VBA side-by-side integrations.

All of these samples show VSTA integrations using Summit's assembly/sample code, VSTA Access Objects (VAO) Source

VAO contains similar integration source to the SDK samples, but it is consolidated into one place for ease of use. VAO also implements VBA-Style "seamless, non-destructive debugging.

Improvements to COMClient Easy Integration Sample

Gary — Mon, 30 Apr 2007 21:20:00 GMT

The COMClient easy integration sample is a simple approach to bypassing the proxygen/proxy layer for COM object models. It was recently improved (see description and helps appended below) These improvements are available in the updated sample for download:

======

COMClient easy integration - using generic COMProxy and VAO

This example shows how simple it is to integrate VSTA into a COM application using a generic proxy and VAO (src included). The generic proxy can be used to expose any COM object model (type library) to VSTA without using proxygen. VAO is used to simplify the integration process, and it implements Non-Destructive Debugging.

Synopsis: The COMClient passes an IUnknown ptr to an instance of its COM object directly to the VSTA Addin via a Connector object:

pConnector->AssignHostObject(pDispMyCOMServer);

The VSTA Addin obtains the same instance of the COM Object as a System.__ComObject.

object obj = this.GetHostObject();

The VSTA Addin uses a reference to the COMInterop assembly (created with tlbimp MSDNCOMServer.dll ) to provide strong type information for the COM Object .

MSDNCOMServerLib.IMyCOMServer myOM = obj as MSDNCOMServerLib.IMyCOMServer;

myOM.MySimpleCOMServerMethod();

This approach uses a generic proxy layer (no need to run proxygen) that exposes one method to the Addin author.

System.Object Connector.GetHostObject()

Although the sample macro does not demonstrate it, this hookup method can easily be hidden in a global property like 'Application' so that the Addin author can use normal syntax to access the Application object model:

Application.MySimpleCOMServerMethod();

This sample was recently updated…

Updated with revised VAO source and a revised COMClient sample that properly manages messageloop and the ComConnector ref count:

The change in VAO is in VSTAHookup.cs, StopVSTA() method’s last few lines, which causes the connector object to be released immediately:

[

mHostItemProvider = null;

GC.Collect();

GC.WaitForPendingFinalizers();

]

public void StopVSTA()

{

// Safely exit debug mode in the VSTA IDE before shutting VSTA down

if (mDTE != null)

{

StopDebugging();

mDTE.Quit();

}

try

{

ExternalDebugging.UnregisterExternalDebugHost(mHostDebugUri);

}

catch

{

// Ignore the exception

}

UnloadAppAddIns();

UnloadMacros();

try

{

if (mAddInProcess != null)

{

mAddInProcess.AddInProcessExited -= new EventHandler(AddInProcess_AddInProcessExitedMacro);

mAddInProcess.Dispose();

mAddInProcess = null;

}

catch

{

// Ignore the exception

}

mHostItemProvider = null;

GC.Collect();

GC.WaitForPendingFinalizers();

}

=============

The other changes – in COMClient.cpp and COMConnector, ConnectorClass.cpp

properly manages the messageloop and the Connector ref count for proper shut down.

=============

Incidentally, if necessary, your COM application can force the CLR to release all its references to interface ptrs inside RCWs (ie: like VSTA’s reference to CLSID_COMConnector instance) by calling CoEEShutDownCOM() as follows:

#include "cor.h"

…

CoEEShutDownCOM();

This was not necessary in the sample, and usually should not be necessary.

Also, your unmanaged application can instruct the CLR to shutdown in an orderly way (includes CLR calling finalization of all unfinalized .NET objects) and exit process by calling CorExitProcess() with passed in error code. This may be needed by pre-VC++7 COM clients to assure that finalization occurs at shutdown as expected:

#include "mscoree.h"

…

CorExitProcess(0);

==========

Expanding or Collapsing all nodes in the Solution Explorer

Gary — Wed, 18 Apr 2007 20:42:00 GMT

Here's a post showing how to collapse and expand all of the items in the Solution Explorer.

Your hosting application can provide similar features for the VSTA DTE to make things easier for your VSTA authors.

Get underlying DTE object from VSTADTEProviderClass

IDTEProvider dteProvider = (IDTEProvider)new VSTADTEProviderClass();

mDTE = (EnvDTE.DTE)dteProvider.GetDTE(mHostID, 0);

and then your application can alter and manipulate the VSTA IDE to your end user's advantage.