VSSDK/CPS/Extensibility: Image Loading in VS Extensions via .imagemanifest is Broken in VS2022

[softworkz]

[!NOTE] This is a copy of my report on developer community: https://developercommunity.visualstudio.com/t/VSSDKCPSExtensibility:-Image-Loading-i/10525678 Visibility of content from this site is somewhat limited and this repo is one of the core areas which is affected.

While starting to work on a custom VS Project-System, I had gone great lengths on trying to get custom images shown in the VS project tree.
The documentation and tooling (https://github.com/microsoft/VSProjectSystem) is outdated, haven’t seen much updates for years. Samples are still for VS 2015, the documentation wasn’t bad for the time when it was written, but now it’s unreliable in terms of what’s still valid and what not and too often, one can only speculate or research deeply like a forensic investigator.
The VSIX package with all the templates hasn’t been update either, not for 2017, not for 2019, not for 2022. I had to patch, recompile and re-pack to get it working with VS2022 https://github.com/microsoft/VSProjectSystem/issues/371.
While the Project System SDK seems to be still updated, all packages since VS 2017 are marked as “Preview”.

As I couldn’t get custom images working, I tried on different machines and eventually searched for other CPS-based project systems on GitHub. As it turned out: All of them are fighting with broken images in VS 2022.
I came across this report here: https://developercommunity.visualstudio.com/t/Extension-icons-missing-after-update/10242633

It was turned down as “Closed - Other Product” - which was incorrect. It has never been an issue with the extension’s code, it is Visual Studio 2022 which has broken images for all VS extensions (which are using imagemanifest files).

In that other report, you were stating that the Nano Framework VS extension would incorrectly specify the Resources values with the pattern

A: <String Name="Resources" Value="/$rootnamespace$;Component/" />

while the correct pattern would be:

B: <String Name="Resources" Value="/$rootnamespace$;v$assemblyversion$;$publickeytoken$;Component/" />

But upon further research, I have come to an entirely different picture:

• A search for imagemanifest on the MS site yields only 5 results. https://learn.microsoft.com/en-us/search/?terms=imagemanifest
  • 4 pages are showing Pattern A:
    • https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/image-library-viewer?view=vs-2022
    • https://learn.microsoft.com/en-us/visualstudio/extensibility/image-service-and-catalog?view=vs-2022
    • https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/manifest-from-resources?view=vs-2022
    • https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/manifest-from-resources?view=vs-2022
  • The 5th page is a report from a user with images not working
    \=> without resolution
  • No page is documenting Pattern B
• You can find countless reports and questions on stackoverflow on this subject with users getting desperate and without resolution.
• The ManifestFromResources tool in the latest version of VS 2022 is generating Pattern A
  (described here: https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/manifest-from-resources?view=vs-2022)
• The new Extensibility SDK is not addressing images at all
• Neither the VSSDK nor the VS Project System Extensibility SDK are including checks or fixes for this
• The documentation for the CPS/VSPS is showing Pattern A
  https://github.com/microsoft/VSProjectSystem/blob/master/doc/scenario/provide_custom_icons_for_the_project_or_item_type.md
• The “Custom Images” template from the “VS Project System SDK” creates an imagemanifest with Pattern A
• All imagemanifest files that can be found on GitHub are using Pattern A
  (with a single exception, which is the NuGet VS extension)
• The Micorosft Project System for C#/VB/F# has recently switched to use KnownMonikers, but before that happened, it was using Pattern A
  https://github.com/dotnet/project-system/commit/d651d878c2806b3d8e543377968dff55b581a515#diff-5a6080f86944c0185ef28d6b005c37db00075e407cb6a3e572f7ba8b0414d02bL5-L7
• When I search locally for imagemanifest files under the VS 2022 installation folders, then I see that
  • About half of the imagemanifest files are using Pattern B
  • The other half is using Pattern A
    .

Magically and interestingly, those (MS) extensions are not affected - their images are still shown, even with Pattern A. This means that there’s a mechanism to switch off the requirement for Pattern B very easily and it’s not a technical necessity.

Summary

• You have broken custom images for a majority of all those Visual Studio Extensions, which are using imagemanifest files.
• You have not documented Pattern A anywhere, nobody knows abbout it.
• You haven’t updated your tooling for this.
• The change came silently and unexpected - with a huge impact.
  .

Please remove the requirement for Pattern B. This is not to blame on developers - it’s a failure from MS product planning, causing developers turn around and give up on VS extension development, which would be sad. That’s also the reason why I’m filing this, even though I know now how to get around: the other 98% don’t.

[thedemons]

Any workarounds at the moment?