Summit Software

Corel now shipping VSTA

dschneid — Tue, 09 Mar 2010 17:41:00 GMT

Summit Software is pleased to announce that Corel is now shipping VSTA in CorelDraw X5.

CorelDraw is a versatile graphic design software that provides it all - vector illustration, page layout, photo editing, tracing, Web graphics and animation - in one tightly integrated suite.

For more information and to download CorelDraw X5, visit www.corel.com/coreldraw

64-bit setup script for ShapeAppMacroRecordingCSHarp sample

Gary — Wed, 06 Jan 2010 15:10:00 GMT

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.

Chapter Six: Loading VSTA Addins with MEF

BillL — Thu, 13 Aug 2009 16:53:00 GMT

My integration journey has come to an end. For my last post, I am going to write about a new way of loading VSTA AddIns: MEF. I have talked about MEF some in my previous posts, and have successfully used both VSTA and MEF together before. This time, I have successfully used MEF to load VSTA AddIns. To do this, I had to edit part of the MEF library to prevent it from locking the .dll and .pdb files, so the debugging and rebuilding of AddIns would still be possible.

Instead of having NEF load the assembly itself, which it usually does, I had it load a byte array of the .dll and .pdb files. All that I needed to edit was part of AssemblyCatalog.cs in the MEF Preview 6 source. I changed the LoadAssembly method from this:

private static Assembly LoadAssembly(string codeBase)

{

Requires.NotNullOrEmpty(codeBase, "codeBase");

AssemblyName assemblyName;

try

{

assemblyName = AssemblyName.GetAssemblyName(codeBase);

}

catch (ArgumentException)

{

assemblyName = new AssemblyName();

assemblyName.CodeBase = codeBase;

}

return Assembly.Load(assemblyName);

}

to this:

private static Assembly LoadAssembly(string codeBase)

{

byte[] assemStream = null, pdbStream = null;

using (FileStream fs = new FileStream(codeBase, FileMode.Open))

{

assemStream = new byte[fs.Length];

fs.Read(assemStream, 0, (int)fs.Length);

}

string pdbPath = Path.Combine(Path.GetDirectoryName(codeBase), Path.GetFileNameWithoutExtension(codeBase) + ".pdb");

bool hasPdb = false;

if (File.Exists(pdbPath))

{

using (FileStream fs = new FileStream(pdbPath, FileMode.Open))

{

pdbStream = new byte[fs.Length];

fs.Read(pdbStream, 0, (int)fs.Length);

hasPdb = true;

}

else

{

Debug.WriteLine("Cannot find the pdb file: " + pdbPath);

}

if (!hasPdb)

{

return Assembly.Load(assemStream);

}

else

{

return Assembly.Load(assemStream, pdbStream);

}

Now we have the ability to load files without locking them, and also have the discoverability benefits of using MEF.

Here is part of the code from the application that allows it to load AddIns with MEF:

Public Sub Compose()

Dim Dir As [String] = Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.MyDocuments), "ContactManager\AppAddins")

Dim Dir2 As [String] = Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.MyDocuments), "ContactManager\MacroAddIns")

If Directory.Exists(Dir) And Directory.Exists(Dir2) Then

Dim Catalog As New AggregateCatalog(New DirectoryCatalog(Dir), New DirectoryCatalog(Dir2))

Dim Container As New CompositionContainer(Catalog)

Container.SatisfyImportsOnce(Me)

macroBool = True

appLevelBool = True

ElseIf Directory.Exists(Dir) Then

Dim Catalog As New DirectoryCatalog(Dir)

Dim Container As New CompositionContainer(Catalog)

Container.SatisfyImportsOnce(Me)

macroBool = False

appLevelBool = True

ElseIf Directory.Exists(Dir2) Then

Dim Catalog As New DirectoryCatalog(Dir2)

Dim Container As New CompositionContainer(Catalog)

Container.SatisfyImportsOnce(Me)

macroBool = True

appLevelBool = False

End If

End Sub

<Import(("MacroAddIn"), GetType(IAddIn))> Public myMacroAddIn As IAddIn

Private _AppAddIns As IEnumerable(Of IAddIn)

<ImportMany(("AppAddIn"), GetType(IAddIn))> _

Private Property AppAddIns() As IEnumerable(Of IAddIn)

Get

Return _AppAddIns

End Get

Set(ByVal value As IEnumerable(Of IAddIn))

_AppAddIns = value

End Set

End Property

Private Sub LoadAppLevelAddIns()

Try

Compose()

If appLevelBool = True Then

For Each appaddin As IAddIn In AppAddIns

StartAddIn(appaddin)

Me.appLevelAddIns.Add(appaddin)

End If

Catch ex As Exception

System.Diagnostics.Trace.WriteLine(ex.ToString())

End Try

End Sub

Private Function StartAddIn(ByVal myAddIn As IAddIn) As IAddIn

Try

myAddIn.Startup(Me.application)

Return myAddIn

Catch ex As Exception

System.Diagnostics.Trace.WriteLine(ex.ToString())

Return Nothing

End Try

End Function

Private Function CurrentDomain_AssemblyResolve(ByVal sender As Object, ByVal args As ResolveEventArgs) As Assembly

Return Nothing

End Function

Friend Sub LoadMacrosInProcess()

LoadMacros()

Me.m_macroAddInLoadedInProc = True

End Sub

Private Sub LoadMacros()

Try

Compose()

If macroBool = True Then

StartAddIn(myMacroAddIn)

m_macroAddIn = myMacroAddIn

End If

Catch ex As Exception

System.Diagnostics.Trace.WriteLine(ex.ToString())

End Try

If Me.application.MacroManager IsNot Nothing Then

Me.application.MacroManager.CloseThreadSafe()

End If

End Sub

This allows the user to load multiple AppAddIns to be run at startup, and one Macro AddIn to be debugged and run, etc. (Of course, you can always make your Macro AddIn extensible as well, which will still work even if you load the AddIns themselves with MEF.)

I hope you have found this blog helpful in your own integration journey.

Please feel free to email me with any questions.

Chapter Five: Integrating MEF into a VSTA Add-In

BillL — Mon, 10 Aug 2009 17:36:00 GMT

This is one of my last posts in this series. If you have not yet read my previous posts, here are the links to them: Chapter One, Chapter Two, Chapter Three, Chapter Four. (I would especially read Chapter Three, as that is where I introduce MEF, and I would also read the MEF Overview and the Programming Guide, which are linked to in Chapter Three.)

If you remember from my last post, I successfully integrated the VSTA IDE into my Contact Manager application. I have now gone a step further, and integrated MEF into the AddIn itself. To do this, I have created two templates: A regular Macro AddIn template, and a MEF Extension Template.
Here is the default code for each of them.

Macro AddIn code:

Imports System.ComponentModel.Composition

Imports System.ComponentModel.Composition.Hosting

Imports System.ComponentModel.Composition.ImportAttribute

Public Class AppAddIn

Implements IAddIn

Private Application As IContactClass

Private MyContact As IContactObj

Public Sub Startup(ByRef app As IContactClass) Implements IAddIn.Startup

Application = app

MyContact = Application.CreateNewContactObj()

Compose()

End Sub

Public Sub Shutdown() Implements IAddIn.Shutdown

' do nothing

End Sub

Public Sub Compose()

Dim Dir As [String] = Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.MyDocuments), "ContactManager\Macros\Extensions")

Dim Catalog As New DirectoryCatalog(Dir)

Dim Container As New CompositionContainer(Catalog)

Container.SatisfyImportsOnce(Me)

End Sub

Private _Macros As IEnumerable(Of IMEFMacro)

<ImportMany(GetType(IMEFMacro))> _

Private Property Macros() As IEnumerable(Of IMEFMacro) Implements IAddIn.Macros

Get

Return _Macros

End Get

Set(ByVal value As IEnumerable(Of IMEFMacro))

_Macros = value

End Set

End Property

Private Sub RunMacro(ByVal MacroName As String) Implements IAddIn.RunMacro

For Each m As IMEFMacro In Macros

If m.Name = MacroName Then

m.Run(Application, MyContact)

End If

End Sub

End Class

MEF Extension code:

Imports System.ComponentModel.Composition

Imports Interfacelibrary

<Export(GetType(IMEFMacro))> _

Public Class AddJohnSmith

Implements IMEFMacro

Public ReadOnly Property Name() As String Implements IMEFMacro.Name

Get

Return "Add John Smith"

End Get

End Property

Public Sub Run(ByVal Application As IContactClass, ByVal Contact As IContactObj) Implements IMEFMacro.Run

Contact.FirstName = "John"

Contact.LastName = "Smith"

Application.AddContact(Contact)

End Sub

End Class

<Export(GetType(IMEFMacro))> _

Public Class AddJaneDoe

Implements IMEFMacro

Public ReadOnly Property Name() As String Implements IMEFMacro.Name

Get

Return "Add Jane Doe"

End Get

End Property

Public Sub Run(ByVal Application As IContactClass, ByVal Contact As IContactObj) Implements IMEFMacro.Run

Contact.FirstName = "Jane"

Contact.LastName = "Doe"

Application.AddContact(Contact)

End Sub

End Class

Now let’s walk through what this code does. When the user first builds the Macro addIn, and then after any subsequent builds, the AddIn runs the Compose method. This method looks in My Documents\ContactManager\Macros\Extensions for the MEF AddIn Extension. (When the MEF Extension template is built, it automatically installs Extension to this folder.) If an Extension is found, The Macro AddIn imports a collection of Macros from the extension. These Macros are then displayed in the Macro Manager, and can be run. This allows for AddIns themselves to be extensible. A user can import Macros from one or multiple files, and import them into the current Macro addIn project.

Here is a brief walkthrough of this process:

First, run the install file in the root folder of the source code.

Open the App, then select File then click Load IDE.

Build the Macro AddIn.

Click New Project at the top and select MEFAddIn.

Build the MEFAddIn.

Close and then Re-Open the IDE.

Rebuild the Macro AddIn.

Now select file and Click Run Macro.

You should see all the Macros specified in the Macro AddIn.

The Final Result:

I hope this journey has been beneficial in your understanding of VSTA and MEF. Please feel free to email me with any questions.

David Schneid named CEO of Summit Software

dschneid — Fri, 31 Jul 2009 18:43:00 GMT

Summit Software Company is pleased to announce that David Schneid has been promoted to Chief Executive Officer. This decision was approved by the Board of Directors of Summit Software Company. David replaces Bill Fisher, a founder of Summit, who has accepted the opportunity to become the Deputy County Executive of Onondaga County under the leadership of County Executive Joanie Mahoney. Mr. Fisher will continue to serve as the Chairman of the Board of Summit Software Company.

David joined Summit Software in April 2006 as the General Manager, managing Summit’s role as Microsoft’s authorized licensing agent for both Microsoft Visual Studio Tools for Applications (VSTA) and Microsoft Visual Basic for Applications (VBA). In his new role as CEO, David will continue to manage these businesses while executing the strategic directives set forth by the Board of Directors.

Raised in Syracuse, David graduated from Cornell University and received his MBA from Columbia Business School. David returned to Syracuse in 2005 to lead the US expansion efforts for UK-based technology merchant bank Interregnum, and previously had been an Assistant Vice-President at PaineWebber (now UBS) and Director of Business Development for GeoVideo Networks (a venture backed startup).

About Summit

Founded in 1991, Summit Software’s relationship with Microsoft dates back more than 12 years, beginning as Microsoft’s authorized licensing agent for VBA. In 2006, Summit was appointed as the authorized licensing agent for VSTA, which represents Microsoft’s strategic direction for application extensibility.

VSTA IDE Hangs Up when Stepping Into Code

BillL — Fri, 31 Jul 2009 13:23:00 GMT

The VSTA IDE keeps hanging up while debugging when I try to step into code. Why is it doing this?

The IDE may be hanging because you have left PDB files in your application directory. Even if you are running the Release version, make sure that you have no PDB files in the same directory as your application.

Chapter Four: Integrating the VSTA IDE

BillL — Tue, 28 Jul 2009 14:35:00 GMT

My integration journey is taking some exciting turns. As always, I would encourage you to read the first three posts in this series (Chapter One, Chapter Two, and Chapter Three) before reading this one.

I have finally integrated the VSTA IDE into my Contact Manager program. I am going to go through how I did this, show some code, and talk about some of the problems I encountered. Here is a link to my code:

The first thing to do is to run SetupContactManager.js (Right-click it and select Open with Commmand Prompt so you will. Now look in your MyDocuments folder. There should be a new folder with the name ContactManager. This is where the application will store the add-in and macro data for the program. All the files needed for this sample are included in the ZIP file, so you should not have to download any external dependencies (You will have to have the VSTA 2.0 SDK and SQL Server 2005 Express Edition installed, however.) Make sure any dependency errors are resolved, and then build the project. Open the application and click File then click Load IDE.

The VSTA IDE should open.

Now resolve the Interface Library dependency, by pointing it to the InterfaceLibrary.dll file under the main application's Debug folder.

Now create a method called Macro1 under the Startup and Shutdown methods. Make it do whatever you want.

When you are finished programming this method, go back to the main application and select File then Run Macro:

You should see this window:

Click Run, and the code in your Macro1 method will execute.

Here is an example:

Now I will walk you through the steps I took to get this functionality.

First, let me go over the features in VSTA that made this integration possible.

As you may already know, VSTA is software that allows the user of an application to run custom code in an application while the application is running, through a Visual Studio-like IDE. These custom bits of code are called AddIns. These Add-Ins are stored in a templates folder that is in the same folder as the application. When the user runs the Install batch file, it registers the application with the VSTA runtime using a specified name for the application called the HostID, and creates a folder for its Add-Ins in the MyDocuments folder. The user can now create Macros (custom user-created methods) in his Add-In.

Now let’s dig a little deeper in to the code that makes this possible.

If you look at my code, you will notice that I have added four new files to the solution: VSTADesignTimeIntegration.vb, VSTARuntimeIntegration.vb, MacroManager.vb, and MessageFilter.vb. I am not going to get into MessageFilter.vb, but I will give a brief overview of the other three:

VSTADesignTimeIntegration.vb is in charge of showing the IDE, opening and creating Macro projects, and debugging the Add-In.

VSTARuntimeIntegration.vb is in charge of loading and unloading Add-Ins and Macros.

MacroManager.vb contains the Macro manager user interface, updates the list of Macros, and gets the Macros’ names.

I encourage you to explore these files, and see how they work in the application. Also, look over the documentation provided with the VSTA SDK, especially the part about registering your application.

I am now going to walk you through what happens behind the scenes with VSTA in my application. In the AppLoad method, when the program is not run from script, the first workings of VSTA are started. The messagefilter is instantiated first. Once the messagefilter has been instantiated, the application instantiates VSTARuntimeIntegration and VSTADesignTimeIntegration, and runs their Connect methods. Because VSTARuntimeIntegration comes first, I will walk you through what happens when the application calls its Connect method. First, the application passes an instance of the host class (ContactClass) to VSTARuntimeIntegration. Then the application finds and loads the Add-ins, and runs their Startup methods. The Macros themselves are now loaded. Now the application instantiates VSTADesignTimeIntegration and runs its Connect method. Just like in VSTARuntimeIntegration, the VSTADesignTimeIntegration‘s Connect method passes in ContactClass. The application calls the methods in VSTADesignTimeIntegration when the application loads the IDE and on other IDE events, and when debugging Add-Ins. The Macro Manager provides a dialog box for viewing the available macros in the Add-In. It finds these macros by searching for methods in the Add-In that contain the string “Macro.” It then allows the user to either edit or run a macro based on what button the user clicks.

I have used in this application a type of integration called “design-time only.” This method of integration differs from the method outlined in the VSTA SDK documentation. This integration does not have the Add-In connect to the host using a proxy object, which is the standard integration procedure. Instead, the host imports the add-in using a byte-stream, and does not utilize a proxy object. Without the use of a proxy object, the integration process becomes much simpler. The downside to this is that once the Add-In loads, the host can’t unload the Add-In. In addition, any crash of the Add-In will also crash the host, and debugging the Add-In will pause the host. These downsides, while not necessarily an issue, must be kept in mind when deciding which integration method to use.

Now I will go over some problems I had while integrating VSTA, in hopes that you will know what to do if you run across these same issues. First, make sure that your Add-In template is located in the right folder (the folder specified in the CreateNewMacroProject method in the VSTADesignTimeIntegration.vb file), and that if you are using a setup file like the one in my application, you have the paths and HostID defined correctly.

One of the specific mistakes I made was to instantiate more variables than the program required. This caused various errors in getting my application to run properly. Utilizing good programming practices in general will be immensely beneficial to you in any programming scenario. Also, be very careful in translating code from one language to another: be sure that you recognize the differences in the languages you are translating (the language’s syntax, what you must explicitly define, how the language handles variables, etc.).

One other note:

If your program crashes or closes unexpectedly, check the processes in Task Manager to make sure an orphaned vsta.exe is not running. If it is, end it, or your computer will not shut down.

One other thing you may have noticed that has changed is the lack of a message box before the program loads. To ruin the Script, now you must specify a command-line argument of -s. I have created a shortcut to do this and put it in the Debug and Release folders.

In my previous post, I discussed the Managed Extensibility Framework. However, MEF cannot be used to import VSTA Add-Ins for one reason: once MEF has loaded an Add-In, it cannot alter the Add-In, because the Add-in is locked. That is why VSTA must get a byte stream of the Add-in and work with that, instead of loading the Add-In files themselves. I have integrated MEF into an Add-in itself, however, and will talk about this in my next post.

Error loading VB add-ins - token count 0

BillL — Wed, 08 Jul 2009 20:57:00 GMT

I have a problem with loading VB add-ins.

The method call:

ObjectModel::Collection<AddInToken^>^ addInToken = AddInStore::FindAddIn(IEntryPoint::typeid, AddInStoreExtensions::DefaultPipelinePath, FilePath, TypeName);

returns an empty collection when called on a dll created using VB. The FilePath parameter points to a dll, the TypeName is an "ApplicationAddIn.ThisApplication" string where an "ApplicationAddIn" is a RootNamespace of a

VB project, and "ThisApplication" is a class defined in a VB project. The ApplicationAddIn.ThisApplication type is a VS Object Browser in a VB Add-in project.

The C#-based projects works fine, using templates created at the same time. Can you help me with loading VB-based add-ins?

VB add-ins require the proxy to be registered in the VSTA pipeline as well as the GAC; C# add-ins can function without the proxy in the VSTA pipeline. So you should confirm that the proxy is registered in the VSTA pipeline (C:\Program

Files\Common Files\Microsoft Shared\VSTA\Pipeline\AddInViews). The SDK samples register the proxy in the pipeline with the file InstallForVB.bat and a post build event which runs it. Once you have confirmed that the proxy is registered

you can rebuild the pipeline with the code below or through the command prompt.

InstallForVB.bat:

SET TARGET=%1

SET FrameworkDir=%SystemRoot%\Microsoft.NET\Framework\v3.5

REM Copy the Proxy Assembly to AddInViews for VB and update Pipeline

copy %TARGET% "%CommonProgramFiles%\microsoft shared\VSTA\Pipeline\AddInViews\"

"%FrameworkDir%\AddInUtil" -PipelineRoot:"%CommonProgramFiles%\microsoft shared\VSTA\Pipeline" -Rebuild

Post build event:

call "$(ProjectDir)InstallForVB.bat" "$(TargetPath)"

Code to manually rebuild pipeline:

'CYA- run addinstore update for the pipeline and add-in location

'update the pipeline

Dim warnings() As String = AddInStore.Update(AddInStoreExtensions.DefaultPipelinePath)

If (warnings.Length > 0) Then

For Each warning As String In warnings

Console.WriteLine(warning)

End If

'update the add-in discovery folder

Dim warnings2() As String = AddInStore.UpdateAddIns(Path.Combine(System.Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "MyAppVB6"))

If (warnings2.Length > 0) Then

For Each warning As String In warnings2

Console.WriteLine(warning)

End If

Make sure the proxy dll is in the GAC and in the AddInViews folder (C:\Program Files\Common Files\Microsoft Shared\VSTA\Pipeline).

If the proxy dll is missing from the AddInViews folder, make sure your proxy mirrors the ShapeAppBasicCSharp sample's build events. You'll need to copy the InstalInGac.bat and InstallForVB.bat files and set up the build events like this:

call "$(ProjectDir)InstallInGac.bat" "$(TargetPath)"

call "$(ProjectDir)InstallForVB.bat" "$(TargetPath)"

The InstallForVB.bat copies the proxy dll to the pipeline folder and rebuilds the pipeline. I'm not sure what that has to do with VB but this is necessary for C# as well.

**Look in the output window during a build to see if these files have run successfully

Make sure your add-ins are setup so that there is one folder which contains a folder for each add-in, each add-in folder contains the add-in dll, and the add-in dll name matches the containing folder's name. To have your add-ins organize

their dll's like this automatically, use the InstallAddIn.js file and post build event (change the host name) from the ShapeApp sample add-ins.

**Changing the add-in name after creating it causes the parent folder name not to match the assembly.

If the above suggestions do not work here is a more exhaustive list from our forums:

1) Run the AddInStore update and re-build (shouldn't have to do both but better safe than sorry). You can do this programmatically by adding the lines below prior to the AddInStore.FindAddIn's line you sited above, make sure you update

the paths to the pipeline if needed.

AddInStore.Update("C:\\Program Files\\Common Files\\Microsoft Shared\\VSTA\\Pipeline");

AddInStore.Rebuild("C:\\Program Files\\Common Files\\Microsoft Shared\\VSTA\\Pipeline");

Still getting the error?

2) Use the AddInUtil to rebuild both the pipeline and the add-in root. Here are the commands from the VS Command Prompt to do this for ShapeApp (ignore the warning):

C:\WINDOWS\Microsoft.NET\Framework\v3.5>addinutil -PipelineRoot:"C:\Program Files\Common Files\Microsoft Shared\VSTA\Pipeline" -Rebuild

Warning: Add-in Adapter Microsoft.VisualStudio.Tools.Applications.AddInAdapter,

Microsoft.VisualStudio.Tools.Applications.AddInAdapter.v9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a defines a constructor that doesn't take one parameter. This constructor can't be used in the add-in model.

C:\WINDOWS\Microsoft.NET\Framework\v3.5>addinutil -AddInRoot:"C:\Documents and Settings\Melody\My Documents\ShapeAppCSharp\AppAddins" -Rebuild

Finished updating cache

Still getting the error?

3) Review or re-create the project template the add-in was based off of. Make sure everything is correct, including the add-in's dll is in the correct location, the add-in start up class matches StartUpClass variable of the

VstaRunTimeIntegration class, the add-in builds, and the add-in is looking at the most current version of the proxy.

Still getting the error?

4) If you are trying to write an add-in in VB, try doing it in CSharp 1st (make sure the VB add-in's dll is removed). This may work.

ShapeAppBasicMFC with Document Entry Point

BillL — Mon, 06 Jul 2009 16:11:00 GMT

In this sample, Melody modified the proxy to include an entry point for the CDocDrawing class (the CDocDrawing class was also modified to include events which become disassociated with ProxyGen- see this blog for related info on this bug) and the HostItemProvider to expose the CDocDrawing type. Melody also created a template for document level add-ins and used the template to create a sample add-in, ShapeAppMFCDocAddIn1. Here is a link to the sample: ShapeAppBasicMFC with DocEP

To use this sample:

1) Remove the old proxy from the GAC by deleting or uninstalling C:\Windows\assembly\Proxy

2) Remove any VSTA v 1 add-in assemblies by deleting %MyDocuments%\ShapeAppMFC

3) Run the included setup file to register the host and updated templates (SetupShapeAppAdvancedMFC.js)

4) Build the ShapeAppAdvancedMFC.sln solution, this includes the document level sample add-in. This will register the updated proxy in the GAC and build the add-in assembly.

5) Run the sample and notice the message box and shape added from the document level add-in.

Here are the changes Melody made to add this functionality:

1) HostItemProvider

Unchanged code excluded

internal class HostItemProvider : IHostItemProvider

{

public HostItemProvider(ShapeApp.Proxy.Application application)

{

//SUMMIT- add drawing level HIP

//store the active drawing

this.drawing = application.ActiveDrawing;

}

public object GetHostObject(Type primaryType, string primaryCookie)

{

//Check if primaryType is supported.

else if (primaryType == typeof(ShapeApp.Proxy.CDrawingDoc))

{

//SUMMIT- add drawing level HIP

// update the drawing to ensure the current active drawing is returned

this.drawing = application.ActiveDrawing;

return this.drawing;

}

//SUMMIT- add drawing level HIP

//store the active drawing

private ShapeApp.Proxy.CDrawingDoc drawing;

}

2) Proxy and descriptor file

Descriptor file:

Proxy File:

public partial class CDrawingDocEntryPoint : global::Microsoft.VisualStudio.Tools.Applications.Runtime.IExtendedEntryPoint

{/*entry point class code*/}

3) Template

AppAddIn.designer.xml:

hostitem:baseType="ShapeApp.Proxy.CDrawingDocEntryPoint"

misc changes to vstemplate file for updated project name and description

4) Add-in

No code changes required based on updated template, here is the code from the add-in

private void AppAddIn_Startup(object sender, EventArgs e)

{

System.Windows.Forms.MessageBox.Show("Document level add-in loaded");

this.Shapes.Add(this.Application.AvailableShapes[0].Clone());

}

Chapter Three: MEF

BillL — Thu, 02 Jul 2009 17:20:00 GMT

For chapter three, I will be introducing a framework from Microsoft called the Managed Extensibility Framework, or MEF (MEF on CodePlex, MEF on MSDN ). If you are not familiar with MEF, you will certainly get more out of this post if you read the MEF overview and programming guide (MEF Overview, MEF Guide).

Now I will give a synopsis of what has changed in my code since the last revision. If you would like to look at my code, please download the attached file: Updated Sample with MEF

First, notice the Imports statements at the top of ContactClass.vb:

Imports System.ComponentModel.Composition

Imports System.ComponentModel.Composition.Hosting

Imports System.ComponentModel.Composition.ImportAttribute

Imports InterfaceLibrary

The top three statements import parts of the MEF library, and the bottom one is for the Interface Library, which we will get to a little later.

These next two methods are where ContactClass utilizes MEF:

'Imports the an Instance of the IAddIn interface.

<Import(AllowDefault:=True, AllowRecomposition:=True)> _

Public IContactAddIn As IAddIn

'Called by the ContactApp class's ContactApp_Load() method; asks if the user wants to run the App in script mode. The method then stores the user's response in a boolean variable,

'and, if the user's answer was yes, the method calls the Connect Method on the IContactAddIn Interface and passes in ContactClass.

Public Sub AppLoad()

UpdateDataset()

Dim MBResult = MsgBox _

("Would you like to run this program from Script?" + _ Environment.NewLine + "(If Yes, the Interface will be hidden.)", _ MsgBoxStyle.YesNo)

Select Case MBResult

Case MsgBoxResult.Yes

ScriptBool = True

Compose()

If Not IContactAddIn Is Nothing Then

IContactAddIn.Connect(Me)

Else

MessageBox.Show("No script to run.")

End If

ContactApp.Close()

Case MsgBoxResult.No

ScriptBool = False

End Select

End Sub

'Creates a Catalog from Assemblies in the AddIns directory, then creates a Container and creates a batch to add parts, and Composes these.

Public Sub Compose()

Dim Catalog As New DirectoryCatalog("AddIns")

Dim Container As New CompositionContainer(Catalog)

Dim Batch As New CompositionBatch()

Batch.AddPart(Me)

Container.Compose(Batch)

End Sub

The top <Import> statement tells MEF that ContactClass wants an IContactAddIn, and the AllowDefault parameter prevents an exception if no Add-In exists. The AllowRecomposition parameter allows MEF to look for an AddIn whenever the container is composed or refreshed.

The Appload method now calls a method called Compose. The Compose method creates a catalog, a container and a batch and composes them. (For a description of these, please see the MEF Overview and the wiki section on Composition Batch).

If MEF finds a suitable AddIn, AppLoad calls its Connect method and passes in ContactClass. If MEF doesn’t find an AddIn, the program closes without issue. Remember that the program only uses an AddIn if the user selects to run the program in script mode.

You may be wondering how the App and the AddIn communicate. The answer is found in the Interface Library:

'The Interface for ContactClass.

Public Interface IContactClass

Property ContactArray()

Delegate Sub ContactEventHandler(ByVal ca As IContactEventArgs)

Delegate Sub ActionEventHandler()

Event AddedContact As ContactEventHandler

Event DeletedContact As ContactEventHandler

Event EditedContact As ContactEventHandler

Event ContactsPrinted As ActionEventHandler

Event AddError As ContactEventHandler

Event DeleteError As ContactEventHandler

Event EditOldError As ContactEventHandler

Event EditNewError As ContactEventHandler

Event ContactsPrintedError As ActionEventHandler

Function CreateNewContactObj() As IContactObj

Sub AddContact(ByVal Contact As IContactObj)

Sub DeleteContact(ByVal Contact As IContactObj)

Sub EditContact(ByVal OldContact As IContactObj, _

ByVal NewContact As IContactObj)

Sub PrintList()

End Interface

'The interface for the ContactEventArgs in ContactClass.

Public Interface IContactEventArgs

Property Contact() As IContactObj

End Interface

'The Interface for ContactObj.

Public Interface IContactObj

Property FirstName()

Property LastName()

Property HomePhone()

Property CellPhone()

Property WorkPhone()

Property Email()

End Interface

'The Interface for the AddIn.

Public Interface IAddIn

Sub Connect(ByRef TheContact As IContactClass)

End Interface

The Interface Library provides the language with which the App and the Add-In speak to each other. It acts as a blueprint for what is contained in the App and the AddIn, and allows them both to communicate without holding design-time references to each other.

Now let’s look at the AddIn itself.

Imports System.IO

Imports System.ComponentModel.Composition

Imports InterfaceLibrary

'This class is only used when the user runs the App in script mode.

<Export(GetType(IAddIn))> Public Class ContactAuto

Implements IAddIn

Private MyContactClass As IContactClass

Private MyArray As Array

Private stwr As New StreamWriter("Log.txt", True)

Private Event AllContactsNormalized()

Private Event ContactsNormalizedError()

'Gets an instance of ContactClass and creates an instance of an array that is in that class. It also creates the log file.

Public Sub Connect(ByRef TheContact As IContactClass) Implements IAddIn.Connect

MyContactClass = TheContact

MyArray = MyContactClass.ContactArray

stwr.AutoFlush = True

Run()

End Sub

Notice the Export statement, and how its specified type matches that of the Import statement in ContactClass. When MEF looks in the AddIns folder, it will add this to the catalog, and the container will match it with the Import statement in ContactClass.

Here is a diagram of how the whole Application works:

ContactAuto references the Interface Library, as does ContactClass, but The Interface Library does not reference either of them,. If ContactAuto exists, ContactClass calls its Connect method, which it knows about through the Interface library.

This design allows the AddIn to be free of the Application, and allows a programmer to alter the AddIn without altering the main program. All any new Add-Ins would have to do is reside in the right folder, have a Connect method, and specify an export statement. MEF provides this excellent way of discovering AddIns, and allows for a great amount of Application extensibility. There is a possibility for MEF use in a VSTA integration, so I would encourage you to experiment with this new concept.

Chapter Two: Loading Add-ins

BillL — Mon, 29 Jun 2009 14:34:00 GMT

Here is the second chapter in my integration journey. If you have not looked at the first blog post, it would be a good idea to look there first, because that post will explain the application I am working with and my idea behind it.

First, let’s look at a few things that have changed since my first app. If you open the attached .zip file, you will notice that I have separated the ContactClass and ContactObj classes into their own files. The largest change to this app by far, however, is the way the script (which I will refer to as an Add-In) loads and runs. You may recall that the app formerly had the script file right in the project. For this app revision, the script runs entirely from a .dll file (VB class library). I can do this now, because the main app no longer has to reference the script file. The script file must reference the main app, but not the other way around. Let me show you how I did this:

IAddIn.vb:

'Defines an interface with which to connect to the addin.

Public Interface IAddIn

Sub Connect(ByRef TheContact As ContactClass)

End Interface

ContactClass.vb:

'Called by the ContactApp class's ContactApp_Load() method; asks if the user wants to run the app in script mode. The method then stores the user's response in a boolean variable, and, if the user's answer was yes, the method calls the LoadAddin method and passes in the name of the addin file and the name of the addin class.

Public Sub AppLoad()

UpdateDataset()

Dim MBResult = MsgBox("Would you like to run this program from Script?" + Environment.NewLine + "(If Yes, the Interface will be hidden.)", MsgBoxStyle.YesNo)

Select Case MBResult

Case MsgBoxResult.Yes

ScriptBool = True

LoadAddin("AddIns/ContactAuto.dll", "ContactAuto.ContactAuto")

ContactApp.Close()

Case MsgBoxResult.No

ScriptBool = False

End Select

End Sub

'Loads the specified addin and runs its connect method.

Private Function LoadAddin(ByVal addinPath As String, ByVal startUpClass As String) As IAddIn

Try

Dim assemStream() As Byte = Nothing, pdbStream() As Byte = Nothing

Using fs As New FileStream(addinPath, FileMode.Open)

assemStream = New Byte(fs.Length) {}

fs.Read(assemStream, 0, CType(fs.Length, Integer))

End Using

Dim pdbPath As String = Path.Combine(Path.GetDirectoryName(addinPath), Path.GetFileNameWithoutExtension(addinPath) + ".pdb")

Dim hasPdb As Boolean = False

If File.Exists(pdbPath) Then

Using fs As New FileStream(pdbPath, FileMode.Open)

pdbStream = New Byte(fs.Length) {}

fs.Read(pdbStream, 0, CType(fs.Length, Integer))

hasPdb = True

End Using

Else

Debug.WriteLine("Cannot find the pdb file: " + pdbPath)

End If

Dim assem As System.Reflection.Assembly

If Not hasPdb Then

assem = Assembly.Load(assemStream)

Else

assem = Assembly.Load(assemStream, pdbStream)

End If

Dim t As Type = assem.GetType(startUpClass)

Dim addin As IAddIn = CType((System.Activator.CreateInstance(t)), IAddIn)

addin.Connect(Me)

Return addin

Catch ex As Exception

' Do not let error of this Add-in affect others

System.Diagnostics.Trace.WriteLine(ex.ToString())

System.Diagnostics.Debug.Assert(False)

Return Nothing

End Try

End Function

Direct your attention first up to the IAddIn interface. You can see that all it references is the Connect method in ContactAuto. This interface provides a sort of bridge between the ContactAuto class library and the main application. Now look at the AppLoad method. Notice that it calls a method by the name of LoadAddIn and specifies two parameters. This LoadAddIn method is a part of a VSTA design-time-only integration and is the core to the whole scripting process in this app. All that the AppLoad method needs to do is call the LoadAddIn method and pass it the path to the .dll file (class library) and the class in the library in which to start. Once the method loads and parses the .dll file, it will call the Connect method in the IAddIn interface. The app does not need to reference the script library, it just knows how to load a certain file out of a certain directory, and call the Connect method on it through the IAddIn interface. The Add-In must still hold a reference to the main app, so it can call the app’s methods and handle the app’s events, but the Add-In can be separate from the app. The app does not have to know anything about it other than where it is, one of its classes, and that it has a Connect method. Here is a simple diagram of how ContactClass, IAddIn, and ContactAuto interact:

ContactAuto references ContactClass, but ContactClass does not reference ContactAuto. If ContactAuto exists, ContactClass calls its Connect method through the IAddIn interface.

This design allows the Add-In to be free of the application, and allows a programmer to alter the Add-In without altering the main program. All any new Add-Ins would have to do is reside in the right folder, and have a Connect method and a class that is the same name as the one specified in the start-up class parameter of LoadAddIn. This is one way of discovering and loading Add-Ins. I will be showing you a different, even more “Loosely Coupled” way in my next post.

Hang-ups during in-process debugging.

BillL — Mon, 22 Jun 2009 17:48:00 GMT

Here is Microsoft’s workaround for the problem hang-ups during in-process debugging:

“The idea is that we want to wait for the type –registering threads to finish before we call addin.FinishInitialization.

What I did is to record the number of threads in the process before we activate add-in. After addin.Initialize (when the type-registering happens), I’ll track the thread number going up and down. When the thread number is exactly 1 + pre-addin-load number, I know the type registering is done. The workaround kicks in only during debugging. With the workaround, the problem goes away as I tried (note some time you may need to wait a while, as long as several seconds, for the break point to hit.)…”

private IEntryPoint LoadAddIn(string addInPath, string startUpClass, AddInProcess addInProcess)

{

try

{

//Start Workaround for AddIn_Startup debug hanging problem

// Used to keep track the type registering threads.

int threadCountBeforeLoadingAddIn = Process.GetCurrentProcess().Threads.Count;

// End Workaround

// Search for the AddIn at the given location and make sure that it has

// the same Startup class. Also make sure that we can load this Addin

// using the default VSTA pipeline. This function will return a token

// to the AddIn which can be later on used to actually load the AddIn.

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

// Assert the AddIn is valid.

System.Diagnostics.Debug.Assert(addInToken.Count >= 1);

// If the AddIn is not valid then return false.

if (addInToken.Count == 0)

return null;

IEntryPoint addIn = null;

// Using the Token returned above, load the AddIn. This will create an

// instance of AddIn EntryPoint class to activate the AddIn.

if (addInProcess == null)

{

// Load the AddIn in the same process as the host.

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

}

else

{

// Load the AddIn in external process.

addIn = addInToken[0].Activate<IEntryPoint>(addInProcess, AddInSecurityLevel.FullTrust);

}

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

addIn.Initialize(this.serviceProvider);

//Start Workaround for AddIn_Startup debug hanging problem

// Make sure the type-registering thread is started.

int timesToTry = 50; // 5 seconds;

bool typeRegisteringThreadStarted = false;

while ((timesToTry--) > 0 && System.Diagnostics.Debugger.IsAttached)

{

int count = Process.GetCurrentProcess().Threads.Count;

if (count >= threadCountBeforeLoadingAddIn + 2)

{

typeRegisteringThreadStarted = true;

Debug.WriteLine("typeRegisteringThreadStartedt: true");

break;

}

Thread.Sleep(100);

}

//End Workaround

addIn.InitializeDataBindings();

//Start Workaround for AddIn_Startup debug hanging problem

timesToTry = 50;

while ((timesToTry--) > 0 && System.Diagnostics.Debugger.IsAttached)

{

// assume the addin startup does not create new threads.

int count = Process.GetCurrentProcess().Threads.Count;

if (count == threadCountBeforeLoadingAddIn + 1 && typeRegisteringThreadStarted)

{

break;

}

else if (count > threadCountBeforeLoadingAddIn + 1)

{

typeRegisteringThreadStarted = true;

}

Debug.WriteLine("thread count: " + count);

Thread.Sleep(100);

}

// End Workaround

addIn.FinishInitialization();

// Return the loaded AddIn.

return addIn;

}

catch (Exception ex)

{

// Do not let error of this AddIn affect others

System.Diagnostics.Trace.WriteLine(ex.ToString());

System.Diagnostics.Debug.Assert(false);

return null;

}

Building and deploying a product that uses PIAs.

BillL — Mon, 22 Jun 2009 17:17:00 GMT

My program uses about a dozen PIAs with built with tlbimp and needs about half of them installed with gacutil. Is the following usage scenario correct?

1. My colleagues who build my product would only need to do the tlbimp steps in order to generate a build.

2. On our customer machines, we'd install the various PIA DLLs (built in #1) in the setup process and run gacutil to register them.

Correct on both counts.

ProxyGen has an inheritance issue with COM hosts.

BillL — Mon, 22 Jun 2009 15:05:00 GMT

When working with a COM host, such as the ShapeAppMFC sample included in the SDK, ProxyGen creates descriptor and proxy files which do not expose events due to the inheritance structure. Three types are generated for a class: the classType, IClassType, and _IClassTypeEvents. The classType implements both IClassType and _IClassTypeEvents. IClassType is the type passed between the proxy and host; however, IClassType does not implement _IClassTypeEvents- therefore the events are not accessible to VSTA add-ins. How can I make them accessible?

With COM hosts, descriptor or proxy files must be manually modified to add the inheritance of the _IClassTypeEvents to the IClassType to expose events to VSTA add-ins.

(Also see this blog post)

Included in AutoProxyGen is a VSTA addin AutoProxyGen_ShapeAppMFC_InheritenceFix that can help you with this, or you can follow these steps:

1) Add the inheritance of the _IDrawingEvents to the IDrawing type in the proxy

Alternative: Use ProxyGen to create the descriptor file and add the inheritance of the _IDrawingEvents to the IDrawing type prior to using ProxyGen to create the proxy file.

2) Rebuild the sample host.

You can now hook into an event of the active drawing because the events are exposed through the IDrawing type.

Proxy file w/ inheritance added:

Alternative- descriptor file w/ inheritance added:

Sample add-in w/ events for drawing accessible:

Custom Editors in VSTA

BillL — Fri, 19 Jun 2009 20:09:00 GMT

Would it be possible for me to create a Custom Editor using VSPackage and then use it with VSTA?

>> Would it be possible for me to create a Custom Editor using VSPackage

Yes.

>>and then use it with VSTA?

No.

However, you should be able to create ToolWindows in VSTA using an In-Process Host and 'CreateToolWindow' off the DTE.

Also, with VSTA, you could create a custom editor in a host application and use VSTA's DTE to generate (DOM or CodeModel), compile, and run VB or C# code hidden behind the host application or alongside it.