Création d'une fenêtre d'outils Visual Studio - VsAddin ou VsPackage

Question

Question simple - J'ai trouvé deux façons d'ajouter une fenêtre d'outil à Visual Studio (2008): créer un complément ou créer un package.

(Addin: http://www.codeproject.com/KB/dotnet/ vstoolwindow.aspx )
(Package: http://msdn.microsoft.com/en-us/library /bb165051.aspx )

Quel est le "droit"? chemin?

Answer 1

Vous pouvez faire l'un ou l'autre, et j'ai fait les deux. À certains égards, les compléments sont un peu plus faciles, mais ils présentent des inconvénients gênants.

Complément:

• + Aucune installation requise du SDK de Visual Studio
• + Aucune obligation d'utiliser une clé de chargement (PLK) ou de signer vos fichiers binaires distribués
• + Processus de développement plus simple lorsque vous utilisez l'API d'extensibilité (code simplifié à bien des égards)
• + Processus d'installation simplifié (pas de trucs de registre farfelus)
• - ne le fait pas semblent se comporter aussi bien que les volets d’outil basés sur VSPackage
• -J'ai rencontré des problèmes de performances qui m'ont amené à utiliser les interfaces COM du SDK VS à la place des interfaces Extensibility, ce qui a entraîné une baisse significative des performances. En d'autres termes, mon & add; add-in " est maintenant basé sur le SDK VS et n’est en réalité qu’un complément, car il se charge via un fichier XML au lieu du registre. (En outre, d'après tout ce que je peux dire, les interfaces d'extensibilité ne sont qu'un grand utilitaire pour le SDK.)

VSPackages:

• + Vous pouvez exploiter toute la puissance du kit de développement logiciel (VSK), à la fois son ensemble de fonctionnalités et (potentiellement, lorsqu'il est utilisé avec précaution) un avantage en termes de performances
• + semble se comporter de manière plus fiable que les compléments
• - Requiert des fichiers binaires signés, un kit PLK et une procédure d'installation complexe
• -La courbe d’apprentissage est lente et de nombreuses actions apparemment simples sont méchantes / compliquées. J'ai maintenant un assemblage fournissant des méthodes d'extension pour effectuer des tâches "évidentes (pour moi)". actions sur les interfaces COM. Entre cela et l'expérience, les choses se sont améliorées avec le temps. Il existe des options disponibles pour la communauté similaires, que vous devriez sérieusement envisager si vous choisissez cette voie.

Answer 2

Je pense que 280Z28 était parfaitement correct avant VS2010. Mais maintenant, VS2010 et VS012:

• Ne pas exiger de packages signés officiellement (seuls ceux qui se rendent dans la Gallery doivent le faire);
• Grâce à VSIX, il est très facile d'installer des VSPackages qui peuvent également être déployés dans la Galerie.

De plus, VS2010 prend en charge un autre type d’extensibilité: il s’agit d’extensions MEF, qui sont des plug-ins légers qui ne se déclenchent que lors d'événements spécifiques de l'EDI, comme les événements d'éditeur de texte. Un exemple est l'extension FixMixedTabs .

Il suffit de créer un package vide VSPackage (pas de menus, de commandes, ...) et de le copier dans la classe principale pour créer un VSPackage qui se charge lorsqu'il existe une solution active et obtient simplement une référence au DTE2 . De cette façon, vous pouvez simplement l'utiliser comme complément.

// This attribute tells the PkgDef creation utility (CreatePkgDef.exe) that this class is
// a package.
[PackageRegistration(UseManagedResourcesOnly = true)]
// This attribute is used to register the informations needed to show the this package
// in the Help/About dialog of Visual Studio.
[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
[Guid(GuidList.guidVSPackage1PkgString)]
// Load this package when a solution is loaded (VSConstants.UICONTEXT_SolutionExists)
[ProvideAutoLoad("{f1536ef8-92ec-443c-9ed7-fdadf150da82}")]
public sealed class VSPackage1Package : Package
{
    /// <summary>
    /// Default constructor of the package.
    /// Inside this method you can place any initialization code that does not require 
    /// any Visual Studio service because at this point the package object is created but 
    /// not sited yet inside Visual Studio environment. The place to do all the other 
    /// initialization is the Initialize method.
    /// </summary>
    public VSPackage1Package()
    {
        Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering constructor for: {0}", this.ToString()));
    }

    /// <summary>
    /// Initialization of the package; this method is called right after the package is sited, so this is the place
    /// where you can put all the initilaization code that rely on services provided by VisualStudio.
    /// </summary>
    protected override void Initialize()
    {
        Trace.WriteLine (string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
        base.Initialize();

        IVsExtensibility extensibility =
            GetService(typeof(EnvDTE.IVsExtensibility)) as
            IVsExtensibility;
        DTE2 dte = extensibility.GetGlobalsObject(null).DTE as DTE2;
    }
}

Answer 3

Si vous créez simplement une fenêtre d’outil, je vous suggère d’utiliser la route des compléments.

Les packages et les compléments permettent d'étendre Visual Studio. De manière générale, ils ont les mêmes fonctionnalités. Les packages sont un peu plus puissants et permettent une intégration plus profonde dans Visual Studio. Mais cette intégration plus profonde a un coût, notamment des temps de montée en puissance et des procédures d'installation plus longs.

Les compléments sont conçus pour être un mécanisme d’extension plus léger. Temps de montée en puissance réduit et installation plus facile.

Si tout ce que vous faites est une fenêtre d’outil avec interaction de base de l’éditeur, notre modèle de code, alors le complément est le meilleur chemin.