Udostępnij za pośrednictwem


VSPackage Load Failure Analyzer

The Visual Studio VSPackage load failure analyzer captures and logs most common VSPackage load failures. The analyzer reports the reason for a failure and suggestions about how to fix it.

The VSPackage load failure analyzer is installed when the Visual Studio SDK is installed. The analyzer is available in both the main hive and the experimental hive. For computers without Visual Studio SDK installed, the analyzer can also be installed from the MSDN download center.

The load failure analyzer runs either in its own tool window or in command line mode.

Note

The analyzer consists of two assemblies: NativeDependencyResolver.dll and PackageAnalyzer.dll. These assemblies are located in <Visual Studio installation path>\Common7\IDE\PrivateAssemblies\.

Tool Window Mode

To open the VSPackage load failure analyzer, click Package Analyzer on the Tools menu. The Package List pane lists all VSPackages that are registered on the computer. You can sort this list by VSPackage name or GUID.

To analyze a VSPackage, right-click its name and then click Analyze.

The results of the analysis are shown as a tree in the Results pane. A green check icon to the left of a node means that no issues were found. A red cross means that a failure occurred.

By clicking the root node of the tree, you can read a summary of the analysis in the Details pane. You can expand the tree and see each step of the analysis as a child node. By clicking a child node, you can read the results of that step in the Details pane.

Note

If you analyze a managed VSPackage, the fusion logger runs. The first time that you turn on fusion logging, you must choose a folder to store the fusion logs and then restart Visual Studio.

Command Line Mode

The usage syntax for command line mode is as follows:

devenv /command tools.analyzepackage

    /analyzeargs <PkgGuid> [<OutputFileName>]
  • /command tools.analyzepackage
    Load the analyzer.

  • /analyzeargs
    Specify the package GUID that is to be analyzed. This switch is required. Only registry GUID format is accepted. Braces are optional. Use of multiple GUIDs is not supported.

  • <OutputFileName>
    Path to an output file. This switch is optional.

    If an output file is specified, the analysis report is generated as plain text. Otherwise, the output of the analysis is copied to the Visual Studio Output window as plain text.

Here is a typical command line:

devenv /command tools.analyzepackage 
   /analyzeargs ffd3884e-978c-4134-bd20-e69cad4c6629 test.txt

Syntax help is available from the command prompt:

devenv /?

Analysis Details

The typical reasons for a VSPackage load failure in Visual Studio are as follows:

  • PLK validation failure. The developer may have unintentionally changed any one of the following in the VSPackage registration: VSPackage GUID, Company Name, Product Name, Product Version, or Min Edition. These values should not be changed after a PLK has been associated with a VSPackage. Any change requires that you create a new PLK.

  • Dependency issues. A VSPackage may have been deployed in such a way that dependent assemblies cannot be found. To explore such dependencies, use ILDASM for managed modules, or depends.exe or dumpbin.exe for native modules.

  • Exception thrown. When a VSPackage is loaded, Visual Studio calls its SetSite method. If this method throws an exception, then the VSPackage load fails. The best way to isolate this issue is to step through the SetSite code.

  • Improper registration. You typically see this failure when you use the /assembly switch. Verify that the VSPackage is signed appropriately and that the VSPackage is registered by using the correct public key.

The analysis is conducted in the following stepwise order:

  1. Load the VSPackage.

    • Determine whether the VSPackage is managed or native.
  2. Build the Dependency Tree.

    • Validate the dependencies.
  3. Gather system registry data for the VSPackage.

    • Verify the VSPackage registration.

    • Verify the PLK against the registration.

  4. Other Checks.

    • Verify that the Crypto service is running.

    • Check whether SetSite threw an exception.

See Also

Tasks

How to: Troubleshoot a PLK Load Failure