创建 Visual Studio 工具窗口 - VsAddin 或 VsPackage

发布于 2024-07-30 01:24:11 字数 410 浏览 3 评论 0原文

简单的问题 - 我找到了两种向 Visual Studio (2008) 添加工具窗口的方法:创建插件或创建包。

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

“正确”的方法是什么?

Simple question - I found two ways to add a tool window to Visual Studio (2008): create an addin or create a package.

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

What's the "right" way?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

末蓝 2024-08-06 01:24:11

你可以做任何一个,而我都做了。 在某些方面,插件更容易一些,但它们也有一些恼人的缺点。

插件:

  • +无需安装 Visual Studio SDK
  • +无需使用包加载密钥 (PLK) 或签署分布式二进制文件
  • +使用可扩展性 API 时开发过程更轻松(在许多方面简化了代码)
  • +更轻松的安装进程(没有古怪的注册表内容)
  • -似乎表现得不如基于 VSPackage 的工具窗格 -
  • 我遇到了性能问题,这促使我使用 VS SDK COM 接口而不是可扩展性接口,从而导致性能显着提升。 换句话说,我的“外接程序”现在基于 VS SDK,并且实际上只是一个外接程序,因为它通过 XML 文件而不是注册表加载。 (此外,据我所知,可扩展性接口只是 SDK 的一个大型实用程序包装器。)

VSPackages:

  • +您可以利用 VS SDK 的全部功能,包括其功能集和(如果仔细使用,可能会)性能优点
  • +似乎比插件表现得更可靠 -
  • 需要签名的二进制文件、PLK 和复杂的安装过程
  • -陡峭的学习曲线,许多看似简单的操作却令人讨厌/复杂。 我现在有一个程序集,提供扩展方法来在 COM 接口上执行“明显(对我来说)”的操作。 随着时间的推移,事情已经有所改善。 社区提供了类似的选项,如果您选择这条路线,您应该认真考虑这些选项。

You can do either, and I've done both. In some ways, addins are a bit easier, but they suffer from some annoying drawbacks.

Add-in:

  • +No requirement to install the Visual Studio SDK
  • +No requirement to use a Package Load Key (PLK) or sign your distributed binaries
  • +Easier development process when you use the Extensibility API (simplified code in many ways)
  • +Easier installation process (no wacky registry stuff)
  • -Doesn't seem to behave as well as VSPackage-based tool panes
  • -I've run into performance issues which prompted me to use the VS SDK COM interfaces instead of the Extensibility ones, leading to a significant performance bump. In other words, my "add-in" is now based on the VS SDK and is only really an add-in because it loads via an XML file instead of the registry. (Also, from everything I can tell, the Extensibility interfaces are just a large utility wrapper around the SDK.)

VSPackages:

  • +You can harness the full power of the VS SDK, both its feature set and (potentially, when carefully used) performance advantage
  • +Seems to behave more reliably than add-ins
  • -Requires signed binaries, a PLK, and a complicated installation procedure
  • -Steep learning curve, and many seemingly simple actions are nasty/convoluted. I now have an assembly providing extension methods to perform "obvious (to me)" actions on the COM interfaces. Between that and experience things have improved over time. There are similar options available to the community, which you should seriously consider if you go this route.
咆哮 2024-08-06 01:24:11

我认为 280Z28 在 VS2010 之前是完全正确的。 但现在 VS2010 和 VS012:

  • 不需要正式签名的软件包(可能只有那些访问 Gallery 的软件包才具有到);
  • 感谢 VSIX,它可以非常轻松地安装 VSPackages,也可以将其部署到 Gallery。

此外,VS2010 支持另一种可扩展性:这些是 MEF 扩展,它们是仅在 IDE 的特定事件(如文本编辑器事件)时触发的轻量级插件。 一个示例是 FixMixedTabs 扩展。

只需创建一个 VSPackage 空包(没有菜单、命令等)并将其复制到主类中以创建一个 VSPackage,该 VSPackage 基本上在存在活动解决方案时加载,并且只需获取对 DTE2 的引用即可>。 这样你就可以将它用作插件。

// 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;
    }
}

I think 280Z28 was perfectly correct prior VS2010. But now VS2010 and VS012:

  • Do not require officially signed packages (may only those that go to the Gallery have to);
  • Thanks to VSIX it can very easily install VSPackages that can also be deployed to the Gallery.

Moreover VS2010 supports another kind of extensibility: those are MEF extensions, that are lightweight plugins that trigger only at specific events of the IDE, like text editor events. An example is FixMixedTabs extension.

Just a create a VSPackage empty package (no menus, commands, ...) and copy this in the main class to create a VSPackage that basically loads when there's an active solution and just get a reference to the DTE2. In this way you can just use it as an Add-in.

// 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;
    }
}
茶花眉 2024-08-06 01:24:11

如果您只是创建一个简单的工具窗口,那么我建议您使用插件路线。

包和加载项都是扩展 Visual Studio 的方法。 一般来说,它们具有相同的功能。 包的功能更强大,可以更深入地集成到 Visual Studio 中。 但这种更深入的集成会带来成本,包括更长的启动时间和安装程序。

插件被设计为更轻量级的扩展机制。 更短的启动时间和更容易的安装。

如果您所做的只是工具窗口与编辑器和代码模型的基本交互,那么加载项是最佳途径。

If you are just creating a simple tool window then I suggest going the Add-in route.

Both Packages and Add-Ins are ways of extending Visual Studio. Generally speaking they have the same functionality. Packages are a bit more powerful and allow deeper integration into Visual Studio. But that deeper integration comes with a cost including bigger ramp up times and installation procedures.

Add-ins are designed to be a more light weight extension mechanism. Smaller ramp up time and easier installation.

If all you are doing is tool window with basic interaction of the editor our code model then add-in is the best route.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文