VsixUtil errore VsixFeed0001: “This VSIX does not apply to any product installed on this machine. The problem could be that the VSIX manifest’s format is not recognized, or that the manifest has been corrupted.”

Avendo realizzato alcune extension per Visual Studio e volendo condividerle con gli altri sviluppatori, stavo tentando di pubblicarle tramite una Private Gallery sulla intranet aziendale. In breve, la procedura consiste nella creazione di un feed Atom contenente link alle varie extension che si vogliono pubblicare e i metadati delle stesse. Successivamente, ciascun utente può configurare all’interno della propria istanza di Visual Studio l’URL del feed Atom.

Per la creazione del feed, si può utilizzare l’utility a riga di comando VsixUtil, fornita con Visual Studio SDK. Tuttavia, nonostante le mie extension fossero create correttamente e regolarmente installate in Visual Studio, l’esecuzione di VsixUtil falliva con il seguente errore:

VSSDK: error VsixFeed0001 :  'MyExtension.vsix' - This VSIX does not apply to any product installed on this machine. The problem could be that the VSIX manifest's format is not recognized, or that the manifest has been corrupted.
VSSDK: error VsixFeed0002 : Could not create a VSIX feed file because of error '1'

Anche il workaround suggerito nelle FAQ (utilizzare l’argomento -ignoreErrors) non si è rivelato utile nel mio caso.

Se sei di fretta, puoi andare direttamente alla soluzione; altrimenti puoi continuare a leggere.

Dopo un’infruttuosa ricerca sul web, ho deciso di provare a debuggare il programma VsxUtil per carcare di capire cosa fallisse nella validazione del manifest della mia extension. Non avendo trovato il codice sorgente del SDK, ho disassemblato il programma VsixUtil.exe (installato in: C:\Program Files\Microsoft Visual Studio\2022\Professional\VSSDK\VisualStudioIntegration\Tools\Bin) con la preziosa utility ILSpy, avendo cura di caricare anche gli assembly Newtonsoft.Json.dll, Microsoft.VisualStudio.ExtensionEngineContract.dll e Microsoft.VisualStudio.ExtensionEngine.dll, presenti nella sottocartella lib. Ho quindi esportato il progetto (“File” → “Save Code…”) e l’ho aperto con Visual Studio 2022.

Dopo aver aggiunto i riferimenti ai suddetti assembly, ho riscontrato che il progetto non veniva compilato a causa ell’errore “CS0220 The operation overflows at compile time in checked mode” relativo al seguente codice in NgenData.GetHashCode():

return (int)((678645121 * -1521134295 + StringComparer.OrdinalIgnoreCase.GetHashCode(NgenApplication)) * -1521134295 + NgenArchitecture) * -1521134295 + NgenPriority;

Per tagliar corto, ho semplicemente sostituito il codice incriminato con: return base.GetHashCode();

Dopo questa modifica sono finalmente riuscito a compilare il progetto, ma all’esecuzione, nonostante avessi compilato senza ottimizzazioni e avviato in configurazione “Debug”, Visual Studio mi informava che stavo comunque cercando di eseguire una build con la configurazione “Release” e che pertanto i breakpoint non sarebbero stati efficaci.

Popup "Just My Code Warning" di Visual Studio.

Dopo alcune verifiche, ho riscontrato che il responsabile era l’attributo DebuggableAttribute, specificato nel file AssemblyInfo.cs:

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Finalmente, dopo aver commentato l’attributo e ricompilato, sono riuscito ad avviare una sessione di debug.

Come sospettavo, l’errore restituito dal tool, che ho osservato essere un’eccezione Microsoft.VisualStudio.ExtensionManager.InvalidExtensionManifestException, nasconde il vero problema, che è indicato dalla inner exception:

FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.Validation, Version=17.6.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified
Dettagli dell'eccezione in Visual Studio

A questo punto la soluzione al problema è stata chiara: ho cercato sulla mia macchina il file Microsoft.VisualStudio.Validation.dll (trovato in varie cartelle, tra cui: C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\VSSDK) e l’ho copiato nella cartella in cui è presente VsixUtil.exe (C:\Program Files\Microsoft Visual Studio\2022\Professional\VSSDK\VisualStudioIntegration\Tools\Bin).

Se solo il messaggio di errore restituito da VsixUtil.exe fosse stato più chiaro, penso che avrei individuato il problema molto più velocemente, magari utilizzando Fusion Log. L’errore, invece, mi ha fatto pensare a un problema di validazione dell’extension, mandandomi completamente fuori strada.

TL;DR: La soluzione, in breve.

Copiare il file: Microsoft.VisualStudio.Validation.dll
da: C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\VSSDK
a: C:\Program Files\Microsoft Visual Studio\2022\Professional\VSSDK\VisualStudioIntegration\Tools\Bin.

La soluzione è semplice, ma che fatica per arrivarci! 😓

L’integrazione di Source Code Control in Visual Studio Shell 2008 Isolated non funziona!

Come riportato in alcune segnalazioni su Microsoft Connect (“MS SCCI Source Control does not work in Visual Studio Shell Isolated mode” e “integrate a Source control ( Visual Source Safe ) with a Shell ( isolated mode )”) e sul forum di Visual Studio Extensibility (“VS Shell: MSSCCI source control busted?”), il supporto del Source Code Control in Visual Studio Shell 2008 Isolated Mode non funziona; il bug è stato riconosciuto da Microsoft e verrà sistemato in una release futura.

La segnalazione “VSShell: Bug – SVsQueryEditQuerySave doesn’t work w/SccProvider Package” descrive i passi da seguire per riprodurre il problema; sfortunatamente dalla risposta del team di sviluppo di Visual Studio si evince che tale problema non sarà ancora sistemato in Visual Studio 2010…

Lanciare un editor fileless

Normalmente, gli editor in Visual Studio e nelle applicazioni su di esso basate sono lanciati eseguendo doppio click del mouse sul nodo relativo al file che si vuole modificare, all’interno dell’albero del progetto corrente.

A volte però, può essere necessario aggiungere all’applicazione basata su VS Shell 2008 Isolated (o a un generico progetto di estensibilità di Visual Studio 2008) che si sta sviluppando, la possibilità di lanciare un editor “fileless”, ovvero che non è associato ad alcun file nella gerarchia di progetto. Un tale editor potrebbe infatti attingere le informazioni presentate da database, da un insieme di file non appartenenti al progetto, dalla rete, etc…

Questo articolo descrive un possibile metodo per realizzare un editor fileless; questo è l’approccio che ho “trovato” io e non è assolutamente detto che sia il metodo corretto!

In questo esempio è stato usato il wizard di Visual Studio per creare un nuovo package, contenente un editor e un comando di menù, che verrà modificato in modo da lanciare l’editor senza clickare su alcun file. Inoltre, questo package è stato creato e aggiunto a un progetto Visual Studio Shell, ma può anche essere utilizzato al di fuori di Visual Studio Shell, come package per Visual Studio.

Addentriamoci nei dettagli!

Visual Studio Shell 2008 (Isolated): risorse utili

Ecco alcuni link a risorse che ho trovato particolarmente utili per iniziare a sviluppare applicazioni basate su Visual Studio Shell 2008 (Isolated Mode).

Blog, articoli, tutorial, librerie…

DSL Tools and Visual Studio 2008 Isolated Shell (tutorial)

Un ottimo tutorial, tratto da Christian Bækdorf’s .NET Blog, che descrive tutti i passi per realizzare un’applicazione basata su Visual Studio Shell Isolated, con particolare riguardo verso i Domain-Specific Language Tools. Le tematiche trattate includono anche: la creazione di un progetto “custom” basato su MPFProj, la generazione delle “load keys” per la Shell e i Package utilizzati e infine la creazione del progetto di setup per l’applicazione. Caldamente consigliato!

How do I pick what features are included in my VS Shell (isolated) based application?

Ok, è possibile rimuovere funzionalità e componenti dalla nostra applicazione basata su Visual Studio Shell, inserendo nel file .pkgundef le chiavi di registry corrispondenti alle funzionalità da eliminare. Ma quali sono queste chiavi? Eccolo spiegato in questo articolo, tratto dal blog: James @ MS.

INFO: List of known project type Guids

La lista dei GUID dei vari tipi (e sottotipi, detti anche “flavors”) di progetti gestiti da Visual Studio, stilata da Carlos J. Quintero.

Pablo Galiano pga weblog

Un blog ricco di articoli utili e interessanti.

Visual Studio Managed Package Framework for Projects (MPFProj)

Una libreria che facilita la creazione di progetti in Visual Studio (e quindi anche Visual Studio Shell); è utilizzata in parecchi progetti e tutorial citati in questo articolo. Attenzione: attualmente è disponibile il codice sorgente sotto “Source Code”; la sezione “Downloads” non contiene alcun file!

Visual Studio Shell-Based Applications e altre risorse su MSDN

Sezione della MSDN Library dedicata allo sviluppo di applicazioni basate su Visual Studio Shell (sia Integrated che Isolated).

Gli ambienti di runtime per il deploy delle applicazioni basate su shell, come anche il Visual Studio 2008 SDK (necessario per lo sviluppo di applicazioni basate su VS Shell), possono essere scaricati dal Visual Studio Extensibility Developer Center.

Ulteriori informazioni sono disponibili anche sul VSX Team Blog.

Applicazioni basate su VS Shell

IronPython Studio

Un IDE completo e gratuito (open source) per il linguaggio di programmazione Python, basato su Visual Studio 2008 Shell e disponibile sia in modalità Isolated che in modalità Integrated. A mio avviso una delle applicazioni basate su Shell più complete.

AddOn Studio for World of Warcraft

Un ambiente open source per sviluppare AddOn per World of Warcraft.

Storyboard Designer

Un’altra applicazione open source di esempio basata su Visual Studio Shell, Isolated mode.