Vsix support?

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?

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.

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.

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.

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...

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.

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?

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.