Enhance VS Extension (Proposal 3)

Dec 22, 2011 at 6:55 AM

Please also see Enhance VS Extension (Proposal 1) and Enhance VS Extension (Proposal 2).

Issue: When you have a series of NuGets which are each dependent on each other, rebuilding them automatically when a change is made to a base NuGet is really, really painful and requires lots of PowerShell script writing, etc. that makes it beyond the pain threshold of most devs.

Proposal: Add a "Publish Manager" dialog via the VS Extensions with a menu item to access it from the Tools menu of VS.

This dialog would allow a top level directory to be specified, below which it will scan for solutions & projects that have publish settings for NuGets (or have associated NuSpec files).

It will then create a dependency tree of projects, showing which projects are dependent on NuGets created by other projects within the file structure, it will also keep track of which projects are 'out of date' etc.

Right clicking on projects will open the following context menu:

These will also be available from a toolbar.

 

For now this system will be limited to monitoring source code on your file system, which means that dependent NuGets will all have to be 'checked out' to local working copies.

Please Note: I have already implemented the vast majority of this code (without publish settings support) as part of a very fast and efficient class library that I use from a PowerShell library to calculate NuGet dependencies using a topological sort algorithm, so I would be happy to take it to the next step if there is a likelihood of a pull request being accepted.

Regardless, it should be possible for a lot of the functionality to be available from the NuGet command line using a shared class library - which would be useful for CI servers.  I wouldn't embed in the command line as the command line wouldn't easily support folder wathcing with realtime updating which is possible (and desirous) for this functionality.

Dec 22, 2011 at 5:07 PM

Thanks a lot for your proposals. We will definitely study your proposals and respond to you after the holiday season. Most of the team members are on vacation at the moment. :)

Coordinator
Dec 22, 2011 at 11:21 PM

Why wouldn't this this just be automatic for all projects in the solution. I'm wary of adding a lot of configuration knobs and switches to NuGet. I don't see why you'd have to choose a top-level folder. The location of the .sln file should be that folder.

Dec 23, 2011 at 12:36 PM

That would be great in the scenario where all your NuGets were in a single solution.  We have 10s of solutions already that are interdependent (see other posts).  This suggestion is designed as a tool that allows monitoring of interdependencies across solutions.  It isn't a configuration setting, it may store the MRU directories in the VS settings for convenience, but effectively you'd point the dialog at a folder and have it scan the folder structure for projects that may be in a number of solutions (of course it could default to the currently open solution folder to start with and only show the projects in that solution).

It needs to be a VS plugin as the workflow of building interdependent solutions requires updates to occur within VS (so powershell scripts, etc. can run).

I think you've slightly missed the point of what is actually being suggested, hopefully this clarifies it.

Coordinator
Dec 23, 2011 at 6:07 PM

So this isn't just about building all the packages, this is also about turning around and then updating every corresponding package in every solution? That's quite  a task considering, as you said, it needs to happen in Visual Studio. Chances are, most of those solutions won't be open at the time so this add-in would need to scan these directories, open up all the relevant solutions, and then update them all.

I'm not sure yet that this is a good fit for the NuGet dialog just yet. It might make sense as a separate VS Extension first. We've had a similar request to this from many people, but they want it to happen outside of VS as part of their build process. That would require that we implement http://nuget.codeplex.com/workitem/818 which would allow updating the projects outside of VS.

We don't have plans to implement that any time soon, but we did think it's feasible if we put a constraint that it only works for packages without PS scripts. 

Dec 26, 2011 at 8:09 AM
Edited Dec 26, 2011 at 8:12 AM

As I mentioned I already have code that can very efficiently monitor a folder structure and track dependencies, etc.  I had to write it as it didn't look like 818 would be implemented any time soon (as you allude to), so I saw it as an interim solution for those of us who are using multiple interdependent NuGets.  It isn't great for CI servers, but it at least allows individual developers to solve this huge maintenance issue.

I accept your point however that this is probably done as an independent VS extension for now.  I flagged it here to see if there will be any interest in me releasing this as an extension, otherwise we'll just keep it internal for our own processes.