NuGet Packages with "Related" VSIX packages

Feb 8, 2011 at 11:37 PM

Hi All, 

For 1.2, we plan to implement the ability for a NuGet package to specify related dependencies (see spec here:

We call this the "Spark Scenario". Say you want to install the Spark NuGet into a project. You might also want the Spark Editor enhancements to Visual Studio. However the Spark Editor isn't strictly required by the NuGet package. So if you're not in VS, the Spark package should still install fine.

I have 2 open questions I wanted to ask your feedback on within the spec.

  1. Suppose the user checks in the code and another co-worker checks it out and loads the solution. Should we perhaps run a check then for these types of dependencies and prompt the user unobtrusively to install the VSIX?
  2. This isn't strictly a dependency in that you can still install the NuGet even if the VSIX is unavailable for some reason. Should we have a new section for this, such as <relatedDependencies>, <relatedPackages> or simply <related>?


Feb 9, 2011 at 2:39 AM

for #2: can we add an "optional" attribute to the <dependency> element?

<dependency id="spark" version="1.0" optional="true" />
Feb 9, 2011 at 2:41 AM

That does raise the question of how to cleanly ask the user whether they want it or not, both from PowerShell and the dialog.

Feb 9, 2011 at 2:46 AM

This dependency isn't just optional its also a vsix dependency so we need a way to say both.

Feb 9, 2011 at 2:50 AM

I don't think it should be in the same section as NuGet dependencies. It's really a different concept.

Feb 9, 2011 at 3:03 AM

What about using a folder convention, like we do for special .ps1 files in \tools., or .dlls in \lib? We could handle anything with a .vsix extension in \tools, or have a \vsix folder. Keeps the clutter out of the spec'.

Feb 9, 2011 at 3:05 AM


/kzu from galaxy tab

On Feb 9, 2011 12:04 AM, "drewmiller" <> wrote:
> From: drewmiller
> What about using a folder convention, like we do for special .ps1 files in \tools., or .dlls in \lib? We could handle anything with a .vsix extension in \tools, or have a \vsix folder. Keeps the clutter out of the spec'.
Feb 9, 2011 at 3:16 AM

Wait a minute. We're not putting the Vsix file inside .nupkg, are we?

I think the proposal is only put the dependency in the the .nuspec file, but the actual downloading (and installing) of Vsix will be handled by the Extension Gallery component.

Feb 9, 2011 at 3:19 AM

Ah, of course, we only need the ID. I'd agree with davidebbo then, it doesn't make sense to put it in dependencies. It's not really dependency at all, but part of the payload.

(It might be nice to allow an actual VSIX to be included, but that certainly wouldn't be a primary scenario.)

Feb 9, 2011 at 3:23 AM

This is for more than just vsix, there are other tools like this that we would want to install. We are doing this now by checking in the init.ps1 and installing onload. It would be nice to have a dependentTool node. Or, whatever you would like to call it. If there is a vsix folder, I could make that work.

Feb 9, 2011 at 3:33 AM
wait.. no putting it in the gallery is a complete fail for enterprise scenerios... So, while I understand using the Gallery is good, a alternative method for locating and installing the vsix is needed.
Feb 9, 2011 at 3:56 AM

maybe we need a similar concept to package sources for vsix. Vsix sources :)

Feb 9, 2011 at 3:59 AM
this vsix source could be a property of the package source feed. So if I setup an internal feed I could have some metadata on that feed that gives a search path for the vsix feed.
Eric Hexter

blog |
info |

On Tue, Feb 8, 2011 at 9:56 PM, dotnetjunky <> wrote:

From: dotnetjunky

maybe we need a similar concept to package sources for vsix. Vsix sources :)

Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Feb 9, 2011 at 5:03 AM

There may be different scenarios here. The current thinking was to simply ask VS to install the VSIX, by calling IVsExtensionManager.Install. This just takes a VS package ID, and as far as I know it is only usable for things that live in the main VS Extension Gallery. Here, VS deals with all the details of downloading and installing the VSIX.

But maybe we need a more pluggable model for installing various things as part of a NuGet package install:

  • VSIX from the VS extension gallery (what I just described)
  • VSIX based on an arbitrary URL that points to it
  • MSI based on an arbitrary URL that points to it
  • Same for exe's?

Maybe the last three are really all the same: it's a URL that point to a resource that we can call ShellExecute on, and that does whatever it does.

So those are all external scenarios. In addition, there are potential scenarios that deal with things that are embedded in the nupkg file.

Feb 9, 2011 at 7:06 PM

For now, I’d like to tightly constrain the scope of the feature we implement for 1.2 to the first bullet point, but make sure we design it to support the others. We can tackle the others in a subsequent release.

We definitely don’t want to go down the route of creating our own concept for multiple VSIX repositories. I think that’s an issue that we need the Visual Studio team to solve. And when they do, then the enterprise can have their own VSIX repository configured and implementing our first bullet point suddenly supports these other options.