VSIX Best Practices

re: VSIX Best Practices

fourpastmidnight — Wed, 16 Jan 2013 01:53:32 GMT

Actually, I just figured this out today. It is not necessary to run devenv /setup anymore. In fact, this wasn't even necessary on Visual Studio 2010. I did not have a reference to Visual Studio MPF in the VSIX manifest (I'm not sure if this is strictly required, but it's part of the default VSIX template that ships with the VSSDK). Of more importance, however, is the fact that the sub-extensions that have *.pkgdef files did not have a VsPackage element in the Content element whose inner text is the name of the *.pkgdef file. In Visual Studio 2010, apparently this was not required in order for the *.pkgdef file to be processed. It appears that this is now required for Visual Studio 2012 to process the *.pkgdef file.

Thanks for the suggestion, however.

re: VSIX Best Practices

matt kaufman[MSFT] — Tue, 15 Jan 2013 01:57:55 GMT

@fourpastmidnight:

Please run devenv /setup after your extension install. That should instantiate the entries in HKCU

Matt Kaufman

Visual Studio IDE Services Program Management

re: VSIX Best Practices

fourpastmidnight — Sun, 13 Jan 2013 04:31:42 GMT

Quick update: I tried installing the single VSIX extension in question (in this case, SettingsStore.dll -- again, shortened DLL name) that contains the *.pgkdef file with the specification of a binding path.

VSIXInstaller reported that the extension installed successfully into Visual Studio 2012 Pro, but again, no registry entry was made under HKCU\Software\Microsoft\Visual Studio\11.0_Config\BindingPaths despite the presence of the pkgdef file (after having restarted Visual Studio 2012).

Any ideas?

re: VSIX Best Practices

fourpastmidnight — Sun, 13 Jan 2013 04:20:41 GMT

I couldn't find a more appropriate place for this question. I actually obtained the source code for the AllMargins extension (posted somewhere on one of MS's old code sharing sites)--which I LOVE! I'm in the process of converting it so that it will work with VS2012. The conversion has gone well except for one last thing and I'm hoping that someone can point me in the right direction.

This extension (written by a MS employee) violates the "best practices" spelled out here, as mentioned by @efalsken by nesting multiple VSIX packages. This extension has a somewhat deep hierarchy of packages, each package having a hierarchy of assembly reference dependencies. For example: CaretMargin.dll -> OverviewMarginImpl.dll -> OverviewMargin.dll -> SettingsStoreImp.dll -> SettingStore.dll (I've shortened the DLL names).

The crucial part is that the SettingsStore.dll project contains a SettingsStore.pkgdef file that contains the following:

[$RootKey$\BindingPaths\{GUID}]

"$ProjectPath$"=""

When the extension is loaded (say by VS 2010), a registry entry is made under HKCU\Software\Microsoft\Visual Studio\10.0_Config\BindingPaths: a key of {GUID} is created and a string value of the expansion of $ProjectPath$ is also created. However, after modifying the extension manifests appropriately, Visual Studio 2012 successfully installs the extension, but the BindingPaths are not created as they were in Visual Studio 2010. In fact, no binding paths at all are created.

Is there any reason why this behavior is occurring? How can I track down what's preventing these registry entries from being created when the extension is installed (or after VS starts and loads the extension)? All I get right now is that, for example, FileNotFoundException, probing failed for SettingsStore.dll (shortened DLL name, but I think you get the picture). Probing failed because no binding paths are specified and VS2012 can't find the assembly.

re: VSIX Best Practices

lbp — Mon, 31 Jan 2011 13:23:42 GMT

I agree with efalsken. If the user can't understand how dependencies work then what are they doing installing extensions in a product like visual studio?

re: VSIX Best Practices

Visual Studio Blog — Wed, 16 Jun 2010 01:10:56 GMT

@efalskn --

Better support for dependencies, and finer-grained control over what is and is not installed/enabled are definitely things we have in mind for future enhancements to the VSIX feature. My advice to bundle everything into one VSIX is for now, when the user experience installing dependent VSIXs is not what we'd like it to be. The reason I'm suggesting that you try to distribute a single VSIX in this release is to avoid making the user have to understand how dependencies work. I know this is not ideal. It would be great to hear more about what scenarios you think are most important, as we plan for the next version.

Thanks for your feedback.

-Gary Horen

re: VSIX Best Practices

efalsken — Thu, 10 Jun 2010 16:03:26 GMT

Please, VSIX authors, please do NOT bundle many different features as a single extension. Instead, let each feature install as a separate extension and use the dependency features highlighted above so that users can turn one features on and off as separate extensions. The AllMargins extension is a great example of this. The various "Power Commands" and "Pro Power Tools" (unfortunately from Microsoft) extensions are horrible examples.