-
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.
-
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.
-
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
-
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.
-
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
-
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
-
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.
.png)
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.
-
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
-
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
-
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
-
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
-
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
-
Although there are a lot of components and features in VSTA, I think that most of us on the VSTA team tend to lump those features into three buckets: SDK tools, runtime and designtime. Today, I’ll focus on the runtime components of VSTA and the various ways to use them to load add-ins into a hosting application.
The main component of the VSTA is “The AddInManager,” which is a group of classes that are used to manage add-ins. It is an interesting aspect of the way our design evolved that there isn’t actually a type called “AddInManager.” Instead, the AddInManager consists of several discreet classes. The most basic of these are the AddIn, AddInCollection, and Context classes. All of these are packaged in an assembly named Microsoft.VisualStudio.Tools.Applications.AddInManager.dll and are in the Microsoft.VisualStudio.Tools.Applications namespace. There are many classes in the AddInManager, mostly used in more advanced scenarios that we’ll see later.
So, what are each of these classes? Basically, the AddIn class represents an assembly containing entry-points that compose a user-created add-in. In most cases, the assembly will be the output of the VSTA project that was built by the end-user in either the VSTA or VisualStudio IDE. This is probably the most important class in the Add-In Manager, at least in simple scenarios.
The AddInCollection and Context classes are basically collections that contain add-ins. The Context class is used to define behaviors that are common to all of the add-ins it contains, such as the HostItemProvider and the Evidence used if any AppDomains need to be created. The AddInCollection class is just that: a collection of add-ins. Quite honestly, we had some larger ambitions for the AddInCollection class that didn’t make it into the v1 release due to scheduling restraints, although we left the design open enough to be able to add them in future versions.
In my next post, I’ll examine these classes further and show how they can be used to customize the load an unload behavior of add-ins for different scenarios and to achieve differing levels of resiliency, security and performance.
Aaron Hare
Software Design Engineer
-
Got forms? For example, expense reports, travel requests, asset tracking forms, and status reports? Then take a look at InfoPath. As an XML-based Office application for creating and filling out electronic forms, InfoPath includes a design-mode for rapid-development and a client that includes Office features like spell-checking and rich formatting. InfoPath 2007 Beta also introduces support for filling out those same InfoPath forms in the browser, in Outlook, and on mobile devices, among other features.
Most forms use the built-in InfoPath feature-set for functionality like repeating and optional controls, data validation, web-service connections, rules and formulas for automated completion, and more. But for advanced enterprise-wide forms, some InfoPath developers want to write code for their custom needs. InfoPath 2007 Beta gives you just that. We’ve created a new managed object model (OM) that works the same way in the InfoPath client and in the browser, so you can write your code once no matter how the form is being filled out. And to make it easy to use that new OM, we’ve integrated with Visual Studio Tools for Applications.
InfoPath 2007 Beta’s integration with VSTA provides out-of-the-box managed code development. You can add events to any piece of data in the form, as well as capture other events such as the form opening, saving, or submitting. Adding an event from the InfoPath design mode will launch VSTA with the appropriate code-stub so you can write what you want using the InfoPath OM and System.Xml, complete with IntelliSense. When you’re done, you can set break points and debug your form’s code while running behind the InfoPath form, just as you’d expect.
Here are some common code tasks for InfoPath forms:
· Look up the current user’s username (InfoPath has built-in active-directory “roles” support, but does not provide direct access to the current user’s username)
· Reuse existing process libraries (for example, a mortgage quote algorithm already used in other applications)
· Complex data connections and validation (InfoPath has built in support for Access, SQL, Web Services, SharePoint and email connections, and formulas and pattern matching for validation, but some forms simply require more)
Look for this integration it the Microsoft Office InfoPath 2007 Beta!
Ned Friend
Program Manager - InfoPath
-
The VSTA CTP is now available, but how do you get it? As you can guess I wouldn't need to blog about it if it was as easy as clicking on a link. A little understanding of what VSTA is and how it is distributed will help clear up some confusion about how to get it. First VSTA allows you to create managed customizations (add-ins) for your application. It includes a runtime and a embedded IDE (light weight version of Visaul Studio). VSTA also includes tools, samples and documentation for integrating VSTA with your application. All of this functionality is delivered as a part of the Visual Studio SDK. The reason that it is distrubuted as part of the VS SDK is that VSTA is built on VS and there are many things in the VS SDK that help you with VSTA, like Help Studio lite for example. We are working together with the VS SDK team to make this process a little smoother. But until then, one other thing to understand is that the VS SDK grew from and is part of the Visual Studio Industry Partner (VSIP) program. So you may see references to the VSIP SDK, this is just the old name. You must also register as a free VSIP affiliate member and have a passport account.
How to download VSTA
1. Register / login as an VSIP affiliate member.
https://www.vsipmembers.com/
2. Click on download files link
http://affiliate.vsipmembers.com/affiliate/downloadFiles.aspx
3.Choose the version of the SDK you wish to download.
for example Visual Studio 2005 SDK - February 2006
Note
You can also just click directly on the file download link here Visual Studio 2005 SDK - February 2006 . This will either take you to the login or registration page and then download the VS SDK directly.
Getting Help and Support
If you have questions about VSTA please post them here:
Visual Studio Extensibility Forum
Discuss customization, extension, and integration with Visual Studio, including macros, add-ins, starter kits and the Visual Studio Industry Partner (VSIP) SDK.
Tip
A good tip is to prefix your forum post title with "VSTA:" for example "VSTA: How do I get started" this will help the VS SDK team forward VSTA issues more quickly to the VSTA team.
Paul Stubbs
Program Manager
