Visual Studio VSIX Package Not Loading in Experimental Instance (`/rootsuffix Exp`)

동우 정 0 Reputation points
2025-04-23T07:50:31.44+00:00

Summary

A previously working VSIX extension no longer loads in the Visual Studio Experimental Instance.

  • The .vsix package builds and installs successfully.
  • InitializeAsync() on the AsyncPackage is never called.
  • No ActivityLog.xml is generated.
  • All package registration appears correct (.pkgdef, .vsixmanifest, GUID, etc.).
  • No error in the Output window — only the generic “package did not load” warning.

Development Environment

  • Visual Studio 2022 Community (v17.x, latest updates applied)
  • Target Framework: .NET Framework 4.8
  • VS SDK Packages:
    • Microsoft.VisualStudio.SDK version 17.0.32112.339
    • Microsoft.VSSDK.BuildTools version 17.13.2126
  • Launch command:

devenv.exe /rootsuffix Exp /log

Project Structure

  • Standard VSIX containing:
  • AsyncPackage-derived class
  • [ProvideAutoLoad], [ProvideMenuResource] attributes
  • Proper source.extension.vsixmanifest, .pkgdef, .resx, .vsct, .bmp/.png assets
  • All GUIDs and namespaces are aligned
  • Output includes:
  • FolderCsFileOpener.dll
  • FolderCsFileOpener.pkgdef
  • source.extension.vsixmanifest

Issue Description

Despite successful build and installation:

  • FolderCsFileOpenerPackage.InitializeAsync() is never triggered
  • ActivityLog.xml is not generated, even with /log
  • Menu commands do not appear
  • It appears that the extension is completely skipped during Visual Studio load

.pkgdef content sample:


[$RootKey$\Packages\{c9c3d4e5-384e-447a-9791-eb2d8649b7fe}]

@="FolderCsFileOpenerPackage"

"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"

"Class"="FolderCsFileOpener.FolderCsFileOpenerPackage"

"Assembly"="FolderCsFileOpener, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"

"AllowsBackgroundLoad"=dword:00000001


What Has Been Verified

GUIDs match between .pkgdef, .vsixmanifest, and AsyncPackage class

InitializeAsync() includes Debug.WriteLine logging, but they are never executed

.dll file contains correct class (confirmed via ILSpy)

AssemblyInfo.cs and metadata are aligned

All local caches were deleted (bin/, obj/, %LocalAppData%\Microsoft\VisualStudio\17.0_Exp)

Reinstalled and repaired Visual Studio — no improvement

Copied code to fresh project → same result

Suspected Root Causes

  • Visual Studio skips loading the package at startup
  • Exp instance registry or state corruption
  • ProvideAutoLoad silently failing due to internal change or misregistration
  • ActivityLog.xml fails to initialize due to deeper initialization error
  • Possibly caused by a recent Visual Studio update
  • GitHub source for reproducible issue: 🔗 https://github.com/srtdog64/FolderCsFileOpener/tree/master

Request for Help

Is there any way to force-load the extension or trace why it's being skipped silently?

Can Microsoft confirm if recent versions of Visual Studio introduced changes that affect VSIX auto-loading, ProvideAutoLoad, or experimental instance behavior?

Are there known cases where ActivityLog.xml is not generated even with /log, or the package system is partially disabled?

Visual Studio Extensions
Visual Studio Extensions
Visual Studio: A family of Microsoft suites of integrated development tools for building applications for Windows, the web and mobile devices.Extensions: A program or program module that adds functionality to or extends the effectiveness of a program.
274 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. gekka 11,776 Reputation points MVP
    2025-04-24T09:31:08.7633333+00:00

    I tried comparing it with a new visx project, your project file is missing UseCodebase, so the location of the DLL written to pkgdef is incorrect.

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    	<PropertyGroup>
    		<UseCodebase>true</UseCodebase>
    	</PropertyGroup>
    

    If it's using Assembly instead of CodeBase, perhaps Visual Studio is searching for the DLL in the GAC.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.