Visual Studio Tools for Applications

VSTA DTEProvider has the ability to launch Visual Studio

2009-05-18T02:24:05Z

In VSTA 2.0, you can use DTEProvider to launch Visual Studio instead of VSTA, which can be helpful for debugging or provide additional functionalities for users who already have Visual Studio installed. For example, in ShapeAppCSharpMacroRecording sample, in EnsureIDE function of VstaDesignTimeIntegration.cs you can change the code of

IDTEProvider dteProvider = 
             (IDTEProvider)new VSTADTEProviderClass();
this.dte = (EnvDTE.DTE)dteProvider.GetDTE
                                   ("ShapeAppCSharp", 0);

IDTEProvider2 dteProvider2 = 
             (IDTEProvider2)new VSTADTEProviderClass();
this.dte = (EnvDTE.DTE)dteProvider2.GetVSDTE
                                   ("ShapeAppCSharp", 0);

Now Run ShapeApp, launch IDE and Visual Studio will be launched.

Using WPF in VSTA 2.0

2009-05-10T21:02:00Z

In VSTA 2.0, you have the ability to use WPF. In this post, we will show a simple example to add video to a VSTA add-in using WPF. We will start with ShapeAppCSharpBasic Example. Launch VSTA using "vsta.exe /hostid ShapeAppCSharp", Create a new C# project choosing ShapeAppCSharp-AppLevel template, accept the default name:

Go to Project Menu, choose "Add Windows Form ..." to add a WinForm. Choose "Add User Control " to add a WPF user control:

Open Toolbox, in Controls group, drag MediaElement control onto the WPF user control. Resize and position the MediaElement properly. If you do not have a sample video file, you can download one of the Visual Studio "How Do I?" videos. Rename the video to sample.wmf and put it under "c:\temp". MediaElement requires at least Window Media Player 11. If needed, download and install Window Media Player 11.

Now in XAML view, add source attribute to the MediaElement like:

<MediaElement Margin="12,22,23,27" Name="mediaElement1"

              Source="c:\temp\sample.wmv"/>

Note for simplicity, the video file path is hardcoded and we simply play the video when the WPF user control is loaded and will not go into the rich functionality of MediaElement.

Build the project. If you get compilation error like "The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)", remove the corresponding "using System.Linq;" accordingly.

Go to the WinForm control we added, open Toolbox, in WPF interoperability group, drag ElementHost onto the WinForm, and in ElementHost Tasks pop-up window, choose the WPF user control we created: UserControl1, as the Hosted Content:

In AppAddIn.cs, add the following code to AppAddIn_Startup:

private void AppAddIn_Startup(object sender, EventArgs e)
{
    Form1 f = new Form1();
    f.ShowDialog();
}

Build again and run the project. Voila! You now have a video introduction for ShapeApp!

Enzhou Wang
Software Development Engineer

Additional information about VSTA

2009-01-16T01:59:00Z

Just providing a link to my blog here, that has some information captured about VSTA

http://blogs.msdn.com/sandeep_bhatia

Creating a Host Item Template

2008-06-06T01:55:39Z

The VSTA SDK provides samples and help topics that show you how to dynamically add host items to VSTA add-in projects. However, If you've read the topic "How to: Add and Remove Host Items in an Add-in Project", you might have been a bit confused by the following code snippet:

Where did the value of this last parameter come from? The documentation does not make this very clear, so I will quickly explain.

This parameter refers to the location of a host item template.

The host item template is just a file that contains code that want to appear inside of a host item class that you dynamically create.

The code featured in the example above refers to the host item template that ships with the samples. For your application, you must create your own host item template. Your template does not have to match the one featured in the sample. It can contain anything that you want.

However, you might want to make use of two replacement variables that are featured in the host item template of the sample: [!output SAFE_NAMESPACE_NAME] and [!output SAFE_CLASS_NAME].

VSTA will replace these variables when you create the host item. [!output SAFE_NAMESPACE_NAME] is replaced with the namespace of your add-in project and [!output SAFE_CLASS_NAME] is replaced with the name (first parameter) that you pass into the AddProjectHostItem() method.

Once you have created your host item template, you can pass the location of that template to the AddProjectHostItem method to create host item classes in your add-in project.

Norm E.

Learn about VSTA customer success stories and innovations in VSTA 2.0, tune into our webcast on Sep 27, 2007 at 9 AM PST

2007-08-27T23:37:00Z

Come join us for a webcast on September 27, 2007 at 9:00 AM PST to learn about customer success stories who are using VSTA and the innovations we have made in VSTA 2.0.

Naveen Yajaman, Program Manager on the VSTA team will be presenting.

For more event details and registration: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032351235&Culture=en-US

In this session we will discuss customer success stories using VSTA v1.0. We will also have demos of the new features in VSTA v2.0 and some discussion around that. It will be a good forum to ask questions.

How to Integrate the .NET Framework SDK Documentation with VSTA

2007-05-18T05:36:59Z

The InfoPath team shows you how to integrate the .Net Framework help into the VSTA IDE for InfoPath. Make sure you follow the note about starting InfoPath as an administrator if you are using Windows Vista with UAC turned on (which you should be doing and is the default behavior)

Read more here on the InfoPath team blog.

How to Integrate the .NET Framework SDK Documentation with VSTA

This blog post greatly expands upon the MSDN online help.

http://msdn2.Microsoft.com/en-us/library/aa944989(VS.80).aspx

-Paul

VSTA Video: VSTA at a glance

2007-04-27T19:23:08Z

Harry Miller who is a documentation writer on the VSTO and VSTA team has created a short video that looks at VSTA. This video does an excellent job at explaining at a high level (manager view) what is VSTA, what are some of the features and how it is integrated.

Watch video.

ShapeApp sample application.

ShapeApp macro recording.

ShapeApp macro generated code

I also want to thank Kathleen for working with Harry to post this on her blog.

VSTA powers Solgenia customizations

2007-04-20T00:58:07Z

Solgenia is one the of first ISV customers to integrate Visual Studio Tools for Applications (VSTA) into their GeoMap software suite.

Russ Fustino will be doing a demo of Solgenia's VSTA integration at Teched 2007 in Orlando this June.

Read more about VSTA on Solgenia's site http://www.solgenia.com/include/read.asp?lang=&IdArt=5342&IdCat=426

VSTA Video: VSTA Overview

2007-03-28T19:26:38Z

By now you have seen Visual Studio Tools for Applications in Office InfoPath 2007 and have been wondering about how to integrate VSTA into your applications. Watch Eric and Naveen take you through the features and design goals of VSTA.

Watch Now

VSTA 2005 SDK Launch Announcement

2007-03-27T19:46:15Z

I am pleased to announce the release of the Visual Studio 2005 Tools for Applications Software Development Kit (SDK). VSTA allows Independent Software Vendors (ISV) and enterprises to add application customization to their applications. Microsoft InfoPath 2007 has integrated VSTA. You can see VSTA in action by designing an InfoPath form and pressing Alt-Shift-F12 to launch the VSTA development environment. Think of VSTA as the managed alternative to VBA. VSTA and VBA can also run side by side within the same application so your users can create customizations in the language that makes sense for them.

Get started today by downloading the VSTA SDK and going through the walkthrough that takes you step by step through the integration of VSTA into a sample application called ShapeApp.

Be sure to visit the VSTA Developer Center for more details.

VSTA RTM's with the 2007 Office System

2006-11-10T18:07:00Z

I am excited to announce that Visual Studio Tools for Applications (VSTA) was released as an integrated component of the 2007 Office system earlier this week and is available to both Office developers and ISVs!

As Microsoft's future direction in application extensibility, VSTA provides a powerful customization toolset for ISVs, their customers, and their partners. Leveraging Visual Studio and .NET to provide managed extensibility, VSTA enables innovative customization scenarios while offering new levels of security and control. VSTA accelerates and simplifies the development of tailored solutions, helping ISVs grow their partner ecosystems and extend their market reach. By integrating VSTA into their applications, ISVs give their customers a managed environment for tailoring applications to specific business needs. Within VSTA, multiple configuration options offer ISVs deep control over the customization experience, and new technologies make it possible to develop more reliable, version-resilient extensions. You can think of it as the modern, scalable, and more secure version of VBA.

This first release of VSTA makes numerous improvements over the VBA experience and includes many of the beloved VBA favorites. Perhaps the feature most applauded by enterprise BDMs and SI’s is that VSTA customizations are seamlessly opened by any version of Visual Studio enabling professional developers to continue to enhance applications originally created by end user developers – a feature requested by many enterprises because applications often grow in sophistication over time.

A brief rundown of this feature packed release of VSTA includes:

Leverages the innovative Visual Studio (VS) toolset

Multi-language support – VB and C#

Macro Recoding

Windows Forms designer

IntelliSense & Code Tasks

End-user debugging features: breakpoints, watch/auto/locals windows

Supports connected systems development

Web services-based development

Fully leverages the .NET Framework

Running and debugging 32-bit and 64-bit add-ins

Running partial trusted add-ins

Client and Server programming

Common VSTA/VSTO runtime architecture for seamless up-leveling of solutions

Graduated host integration capabilities – “use what you need when you need it”

Low barrier to entry – get started in about two days

Add more functionality as desired/needed over time

Runs side x side with VBA

Add-in Management

Simplifies loading and unloading of add-ins

Ability to manage application domain creation

Host defined discovery and qualification supporting repository based scenarios

VSTA SDK includes

Redistributable VS based IDE and Runtime

Integration tools

Samples and walk throughs

Help documentation

Find out more about VSTA here, including how to download the VSTA SDK and learn about the simplified and transparent ISV pricing model.

Happy Customization!

KD Hallman

General Manager

Microsoft - Developer Division

VBA and VSTA side by side

2006-08-01T00:24:00Z

One of the cool features of VSTA is that it can exist side by side with VBA in the host application. This allows hosts to slowly migrate their users to managed code over time. Summit has created a sample walkthrough showing you how to integrate VBA and VSTA into the SDK sample application, ShapeApp.

Integrating VSTA with an Unmanaged VBA-Enabled Application

Paul Stubbs
Program Manager

Unloading an Add-In

2006-07-13T23:55:00Z

It has been a while since I’ve blogged, and I still haven’t delivered on my promise that I would explain how to control the AppDomain into which an add-in will be loaded. I’m not going to deliver on that promise today, either; mostly because I think that before I can dig into some of the more advanced performance and partial-trust scenarios supported by the AddInManager, we need to talk about how to shut down add-ins that are already running.

Once the add-in is loaded, all that needs to be done is to call AddIn.Unload specifying an appropriate timeout value. Calling this method notifies the add-in that it needs to do any cleanup, and then tears down the add-ins domain.

This brings us to another one of the classes in the AIM: the AppDomainBinding. The AppDomainBinding is used to track which add-ins are loaded into which AppDomains. For example, in the event that you do not want to unload the AppDomain after the add-in unloads, you can set the AddIn.AppDomainBinding.AutoUnload property to false. In general, this is not a good practice, since unloading the AppDomain is the only means of unloading code in the CLR, but the functionality is there if you need it. The reason for auto-unloading the AppDomain by default is that since an assembly by itself cannot be unloaded, we must tear down the entire AppDomain to ensure that the user’s code has stopped executing.

Another interesting point about unloading is that it isn’t guaranteed to terminate. What if the user’s code contains an infinite loop in their OnShutdown handler? Avoiding this and other potential pitfalls caused by bugs in end-user’s code has become an entire discipline itself, so I won’t go into it here. Suffice to say there is an easy way that you can avoid the 80% case of an add-in failing to shut down: pass a timeout value to Unload. By doing so, the AIM executes the add-ins shutdown logic on another thread and waits for it to finish within the specified timeout. If it does not, the thread is aborted and the AppDomain unloaded without further delay. There are a myriad of other things that a poorly-written or malicious add-in can do to cause the hosting application to hang, but passing an appropriate timeout value should be a help in handing some of the more common errors from preventing the add-in from unloading.

Aaron Hare,

Software Developer

External Process Debugging in VSTA

2006-04-15T01:40:00Z

VSTA was faced with some interesting problems when it came to the add-in developer’s debugging experience. VSTA is built on Visual Studio 2005 and .Net Framework 2.0. The debugging model in these products is a cycle of Build-Start-Debug and eventually Stop. Each time the developer wants to debug the application, the IDE builds output if needed, launches a new instance of it under the debugger and allows the user to take control with the debugger. When debugging ends via the user hitting Stop in the IDE, the debugger terminates the application forcefully. No finalizers run, no cleanup code executes. The application simply ceases to be. This model is supported by VSTA, but many host applications are not designed to be terminated at arbitrary execution points. The host app might be in the middle of writing out to a file, or performing a normally atomic operation. Terminating the app at these locations may result in data corruption and / or very angry add-in developers. Luckily, VSTA has a solution we call External Process Debugging. There are two External Debugging scenarios in VSTA. Internally, we call these non-destructive debugging (NDD) and Alt-F11 (named after the shortcut key for launching the VBA IDE in Office).

With External Process Debugging, the add-in being debugged is executed in a process separate from the host application. It is almost entirely transparent to the add-in that it is not running within the host’s process. Furthermore, the work required for the host to support this model is fairly small and transparent. When the add-in developer wants to debug, a new instance of the external process is created. This debugging process either launches a new instance of the host application and the two are connected (NDD), or it attaches to an already existing instance of the host (Alt-F11). The add-in is then loaded in the external process and objects from the object model in the host process. When debugging ends, the IDE forcefully terminates the external process. The host application receives a notification that debugging has ended. In response, it cleans up its state and can either gracefully exit (NDD), or reload the in-process (Alt-F11).

Why two models of external execution? Because some hosts want to provide add-in developers with a more integrated experience similar to that of VBA which their users are accustomed to. Alt-F11 is a much more interactive developer experience. The host application is created first. While the user is working on the host application, he/she decides a macro needs to be written or recorded. The host application opens an instance of the IDE and automates it externally. When the add-in developer decides its time to debug, they start debugging in the IDE and it appears that the addin runs in-process. When debugging ends, the host reloads the add-in in-process.

In the NDD scenario, the user model is very different than that of VBA. The user starts developing in the VSTA IDE. There is not interactive experience between the add-in developer and the host application during development. Only when a debugging session begins, is an instance of the host created.

Why an external process? The VSTA team’s first experience with this problem was in Visual Studio Tools for Office which is built on VSTA technology. In VSTO, there is a communication channel between the debugger and the host application running the add-in When debugging stops, VSTO is able to notify the app (in this case Word or Excel) and have it shutdown gracefully, even if the user has the application suspended at a breakpoint or stuck in an infinite loop. This technology was very complex, hard to implement and would only work with a few types of host applications. This led the VSTA team to search for a more general solution and this led to the external process.

Jackson Davis,
Developer

Loading an Add-In

2006-03-16T18:51:00Z

In my last entry, Using the Add-In Manager to Load and Unload Add-Ins , I mentioned the Microsoft.VisualStudio.Tools.Applications.AddInManager.dll assembly and that it contains classes that can be used to load add-ins into a hosting application. I also promised that I’d write another entry that explained how to do just that. This time around, we’ll actually get into some of the code.

By default, the classes in the Add-In Manager load add-ins into their own AppDomains, which the Add-In Manager will create automatically. This can be accomplished easily using a piece of code like this:

AddIn addIn = new AddIn("My Arbitrary AddIn Name", @"c:\myaddins\myaddin.dll");

AddInCollection addInCollection = new AddInCollection();

addInCollection.Add(addIn);

Context addInContext = new Context("My Arbitrary Context Name", myHostItemProvider);

addInContext.Add(addInCollection);

addIn.Load(@"c:\mycodebase");

Let’s examine this example in detail. First, we instantiate an AddIn that will be used to load the add-in assembly “c:\myaddins\myaddin.dll”. We give it a name to identify it later, which is also going to be used as the FriendlyName of the AppDomain that will be created for it later on. Note that at this point we haven’t loaded any code or created an AppDomain; all we’ve done is provided some data about the add-in so that we can load it later. Next the AddInCollection is instantiated and the AddIn added to the collection. As I mentioned earlier this step might seem superfluous at the moment, but for the time being it is necessary. Finally, we create the context, again with an arbitrary name for identification.

We’ll also supply our IHostItemProviderContract implementation to the Context, which will be passed into each add-in when it starts up. The IHostItemProviderContract is basically the mechanism through which the add-in bootstraps communicates with the hosting application. Details on implementing IHostItemProviderContract are provided in the VSTA SDK documentation, so I won’t go into that here.

The last method call to AddIn.Load actually does all the work. The Add-In Manager creates a new fully-trusted AppDomain with the ApplicationBase property set to “c:\ mycodebase.” Note that the ApplicationBase is passed to the Load function, the path information passed to the AddIn’s constructor is not used here. Behind the scenes, the Add-In Manager then uses a combination of Assembly.LoadFrom and Assembly.Load to load the add-in passed to the constructor into the new AppDomain. That sounds a little complicated, but it results in the behavior that one would expect: the path information specified to the constructor will be honored if no assembly with the correct name can be found in the GAC or the ApplicationBase.

Once the add-in assembly has been loaded into the target domain, the Add-In Manager invokes its constructor and starts calling various methods on it to start it up. This eventually results in a method called InternalStartup being called, and an OnStartup event being fired. These are the two main entry points to the user’s add-in code. The user’s code will most likely advise on some events of the object model in this method, or do any other necessary startup work. Once the initialization code completes, the add-in is in a state that we call “Loaded,” meaning that the AddIn.IsLoaded property will be true. For the most part, you can think of “Loaded” as meaning “Executing” when it pertains to the Add-In Manager, since there is no concept of a “The assembly is loaded but not yet executing” state.

So, that’s a simple rundown of how the Add-In Manager loads add-ins by default. Of course, we’ve designed the Add-In Manager so that it also supports loading add-ins into specific AppDomains. We’ve also built-in numerous other features to support partially-trusted add-ins. More on that later.

Aaron Hare
Software Design Engineer