In the first three parts of my post series about two major extensibility options in Visual Studio, add-in and integration package, I gave an introduction, discussed the technical structure of an add-in with its applications, and talked about the integrated package and its applications as well.
In this fourth part I’m going to cover the differences between an add-in and an integration package, and highlight these points that are a vital part of making your decision to choose one of them to implement your extensions.
Differences Between Add-ins and VSPackages
From this point, we can move to the main topic of this series about the differences between add-ins and VSPackages.
Previous parts gave you some basic information about add-ins and VSPackages. Many of the differences between add-ins and VSPackages can be discovered from these definitions and information.
The first and obvious difference between add-ins and VSPackages is in the way that add-ins use higher level APIs while VSPackages use lower level APIs. This is a very important difference.
Add-in has access to the APIs that are designed specifically for the extensibility and the automation system (Development Tools Extensibility) so development of add-in is easier and faster than VSPackages. In turn these APIs are apparently limited in scope and do not provide all the functionality that you may need for some cases. Of course, there will be lots of the common scenarios considered to build these APIs but you’re not always dealing with common stuff.
VSPackages, on the other hand, have access to lower level APIs that are just the fundamental of Visual Studio, so they’re not limited in scope and you can freely work with them in order to build enterprise integrated features and extensions. Unlike add-ins, VSPackage development takes more effort because Visual Studio APIs are a little harder in comparison with the DTE APIs that add-ins use. The nice point to mention is that add-ins actually use VSPackage APIs themselves to simplify a common part of package API features.
There is also a difference in the development languages that you can use to build add-ins and VSPackages. Visual Studio has a built-in support to build add-ins with Visual C#, Visual Basic, Visual C++ / CLR and Visual C++ / ATL. To build VSPackages, you need to install Visual Studio SDK in order to enable project templates that work with Visual C++ or C#. Of course it’s possible to use other development languages but it needs a hard process of writing all code templates by hand and referencing appropriate APIs.
As you see, you can achieve add-in development faster, easier and with more options.
Level of Integration
One of the biggest differences between an add-in and a VSPackages is the level of integration that you can achieve with them.
Generally, you can have a much better integration with integration packages in comparison with add-ins. Whatever you do, add-ins are an external thing for Visual Studio while VSPackages are a completely integrated part of the IDE.
Of course, this integration level depends on several parameters and one of them is the effort that a developer puts into his or her work. For instance, a developer may put a good effort to write an excellent add-in that has a better integration than a VSPackage that is not written very well. So here development skills and effort are two important points as well.
One of the other differences that both software vendors and developers would care about is the development process and cost of development for each option regarding all the other differences and features that they provide.
Sometimes you may not be sure between add-ins and VSPackages and knowing the development process/cost can help you decide to go with a faster and easier option.
Generally, the development process for add-in is easier than VSPackage for some common and very well-known reasons that we outline:
- Add-ins are optimized for common scenarios during the time while VSPackages are comparatively newer and don’t have such goals. So with add-ins you can achieve some common goals faster and easier.
- For VSPackage development you need to know more concepts and have a deeper knowledge in Visual Studio Extensibility while for add-ins you don’t need such an in-depth knowledge.
- The time of development process for add-ins is less than VSPackages, hence its cost. This is due to the abovementioned nature of add-ins that are easier to develop.
- Debugging, testing, and deployment of add-ins is easier than VSPackages as well.
Of course, again this is a general comparison for same levels of skills and experiences. Someone with better skills would be able to do things in less time than someone who lacks these skills.