Vsix support?

Oct 6, 2010 at 8:42 PM

This post is not related to the Visual Studio integration of NuPack itself. That's very cool.

My open-source libraries don't just provide binaries. They also provide Visual Studio extensions. I have a keyboard shortcut for transforming code, a T4 template that uses a custom DLL (which I GAC), and several project templates.

I currently ship MSI installers to set up these features. I haven't made the vsix switch yet, though that is my intention. If I adopt NuPack, will I be able to install these VS extensions?

Oct 6, 2010 at 8:57 PM

That's something on our roadmap, but we don't provide that ability straight away. You could include PS scripts in your package that perhaps try and launch the vsix, but it's not a mainline scenario that we've tested.

Oct 6, 2010 at 11:33 PM

Typically, NuPack packages only affect the solution in which you install them, so that they can be source controlled, etc...  I think installing VSIX is better served by the VS Extension Manager.  Maybe at some point we'll find a good way to converge those two concepts.

Oct 6, 2010 at 11:35 PM

Agreed. In fact, in fact, I have some specs around here somewhere where I propose how we might do that. I’ll post to the wiki sometime later.

Oct 7, 2010 at 5:33 AM

(raising hand) I agree, being able to deploy add-ins this way would be really cool. Ideally if it could be done so nupack will download and run a .msi... :)

Oct 7, 2010 at 3:10 PM
I wondered how long it would be until the ugly demon that is MSI was brought up again.


On Wed, Oct 6, 2010 at 11:33 PM, KristoferA <notifications@codeplex.com> wrote:

From: KristoferA

(raising hand) I agree, being able to deploy add-ins this way would be really cool. Ideally if it could be done so nupack will download and run a .msi... :)

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

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

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

Oct 7, 2010 at 10:53 PM
MSI may be more for CoApp than for NuPack. http://coapp.org/
Oct 12, 2010 at 6:01 PM

Hi All, I posted a spec for what this might look like in the future. This would be a post-v1 feature though.

Oct 15, 2010 at 1:25 PM

I got to thinking about this in terms of what I'll need for a project, and I think maybe this discussion is looking at things backwards :). At least, maybe it's backwards for at least some things. I'm thinking specifically about project templates. Maybe it's not a good idea for a nupack package to install a project template. Maybe it would be better if the project template could use the nupack APIs to add the packages necessary for the project type? Would there be a way to access the nupack APIs from a project template assembly? I'm not (necessarily) suggesting that nupack shouldn't be able to install msi/msix packages, but I do think that in terms of usability it might often make more sense to go the other direction at this problem.

Oct 15, 2010 at 3:03 PM
VSIXes (except for templates-only ones, which are typically quite useless) require a VS restart, so this is tricky to use.

I'd say if a nupack "includes" a vsix, it should just open up Extension Manager with the pre-selected online vsix from the gallery for the user to install. That would already go a long way, I think, without reinventing a lot of VSIX uex metaphors...
Oct 15, 2010 at 4:38 PM

I'm not sure if that reply was directed at me or not, but that's precisely why I think they were looking at the "problem" backwards. The original proposal was something along the lines of:

1. I Add-Package NUnit.

2. This prompts the user asking them if they want to install the VSIX. If they do, this will cause a reboot in your scenario. I'm also not sure how this could avoid the prompt if the VSIX is already installed. Then there's versioning questions.

What I'm suggesting is this.

1. The user installs my VSIX. Of course this will require the reboot, but that's normal and harmless.

2. The user creates a project (item, etc.) using my VSIX.

3. My VSIX uses nupack to ensure the necessary packages are added to the project.

This seems more natural for most things, and will have fewer management issues with versions, etc.

Jan 12, 2011 at 2:01 PM

I definitely agree that NuGet should be able to install vsix!

I'd like to use nuget in my company to distribute our internal libraries/tools/frameworks. And installing vsix's separatly from binaries makes nuget useless.  So we have to stay with shared network folders :((

I believe nuget could at least run automatically vsix's in "tools" package's folder. Actually vsix's are just kind of tools, aren't them?



Jan 14, 2011 at 3:50 PM

Something occurred to me related to this topic. NuGet adds dependent packages to a project; VSIX adds extensions to an environment. The two ideas are incompatible for two reasons:

  • One developer can have many projects, each with their own dependencies. But no matter what project he's using, his environment always has the same extensions.
  • Many developers can work on the same project. While the dependent packages are shared via source control, extensions are not.

So the original problem is that I want to ship an extension for use with a package. That extension is only useful within projects that depend upon this package. And I want all developers that open the project to have that extension.

The solution, I think, is to modify the Visual Studio extensibility model. Visual Studio should load extensions from the project folder. Then those extensions could be checked into source control, and NuGet could distribute them.

Jan 14, 2011 at 3:54 PM

MichaelLPerry1971, bright idea! Then it'd be possible to work with a solution whithout installing anything (just get latest version and compile).