package uninstall when it contains content that has to exist in a x-project vstudio shared location

Sep 1, 2011 at 5:03 PM

This post [ ] outlines install.ps1/uninstall.ps1 routines for deploying and removing code snippets as part of a package.

On a given dev wks if you have multiple projects using the same package, that includes code snippets, if you then uninstall that package from one project because you no longer need it you are going to uninstall the code snippets that were still relevant and needed by the projects still using that package.

Is there an overall nuget packages strategy for this kind of scenario, i.e. where packages have to deploy content that has to exist in a x-project vstudio shared location?


Sep 1, 2011 at 8:22 PM

There is no 'official' support for this, as NuGet was not really designed to do machine level things like this. I can think of two strategies here:

  1. Don't uninstall them
  2. Do some kind of ref counting in the registry and only uninstall when it goes to 0

#2 may seem tempting, but I don't think it would work well. The problem is that in a team environment, only one person installs the package, and the others just get it already installed, so we can't trust the ref counting. More generally, even without using either of those options, the coworkers won't have the snippets unless they go and install the package themselves somewhere.

So I'd say the whole lifecycle of the snippets is pretty busted.

Ideally, the way it should work is that the snippets should exist only while the project is up. I wonder if moving the logic to init.ps1 instead of install.ps1 could work better (though not sure about uninstall).

Sep 2, 2011 at 12:39 AM

Thanks for the background on what does or does not exist on this front and suggestions for how to handle this.

The option 2 the ref counting approach i think may send us down the same path as "dll hell".  the option 1 approach of just leaving them in place i'm thinking is reasonable given they don't harm anything being left around and any future package update by any project using the associated package will make sure they get rev'd.  

So the trick i'm thinking is perhaps to ensure that you put all per package code snippets per pacakge in a single "Code Snippets\Visual C#\My Code Snippets" and "Code Snippets\XML\My Xml Snippets" snippet file that uses the package name so its self describing if the user opens these folders and sees it. 

Sep 2, 2011 at 10:53 AM

Ok, but I think the problem I described would remain. e.g.

  • User A installs the package into a project. The snippets get installed on User A's dev machine.
  • User A commits changes to team repository
  • User B clones the repo to work on the project. Here Users B doesn't have the snippet installed because they never installed the package themselves.

Do you agree? That's why I was tentatively suggesting looking at using init.ps1 instead of install,ps1.

Sep 2, 2011 at 5:26 PM

i wouldn't see that as a problem see maintaining $(SolutionDir)packages binaries and content into the source control tree as desirable for the reason you mention and for the fact that the desire is to not have the source control tree littered with duplicate binaries being stored in all the solution folders that happen to use the same packages.   I also strive to keep source control sync as fast and as small as possible as this makes dev wks operation of several enlistments less owners and tfs continuous integration build definition processing faster as well.

I just submitted this issue that outlines how i configure projects so that new dev wks enlistments and tfs build processing can pull the packages as needed and the associated feature ask to make that an approach that doesn't require the dev to have to unwind pending changes that get created every time a package is added or updated.   If you buy that a large portion of the NuGet community would be going this route over time then we'd be covered in terms of user b always having the vstudio shared location package content right?

Sep 2, 2011 at 7:18 PM

Not sure I'm following you here. We have good workflows for not committing packages to source control (e.g. see my post), but that is mostly orthogonal to the issue we're discussing here. When user B gets his packages 'restored', install.ps1 does not run. So whatever it would have done on dev A's machine (like registering machine level snippets) will not happen on dev B's machine.

Sep 2, 2011 at 8:48 PM

I see it appears i was missing the subtlety you were trying to point out.   What i hear you saying is that the nuget.exe install $(ProjectDir)\pacakges.xml processing doesn't in fact run install.ps1 scripts it just pulls the packages down into $(SolutionDir)\packages folder correct?

If that is the case then you are sying that there is a story for having Tools\init.ps1 scripts defined that do in fact run when nuget.exe install command executes?

Looking at your post(s) covering committing packages to source control i like the vsix solution but is there any way that the nuget.exe can get shoved into a vstudio shared path so that you don't have every project consuming nuget packages containing a source control maintained copy of nuget.exe?

Sep 2, 2011 at 9:00 PM

nuget.exe doesn't run any scripts. But init.ps1 gets run each time the solution is open, so code in there would run for everyone.

As for having nuget.exe globally on the machine, it's certainly possible, but then things wouldn't build on machines that don't have it in the expected location. Maybe there are some smart ways to bootstrap it by downloading the exe on the fly, but we haven't not really looked at that. It's kind if a chicken and egg thing since you need a tool to download packages, and nuget.exe is itself a package.

Sep 2, 2011 at 10:18 PM

i see that helps.  So if i place my snippets install routine in a Tools\init.ps1 it'll force it to redeploy snippets files on clean enlstments but the packages won't be there until the user builds because i have the nuget install command in the pre build event.   Even if i switch to the nuget power tool that won't pull the bits until i'd have to author the pre-build event process to run Tools\init.ps1 if i didn't want the dev/test user to have to open clean enlistment sync + build + close & reopen solution.

The power tools option is close but the fact that i end up with nuget.exe copies all over source tree versus just a single copy stuck in %windir% on dev/test wks and tfs build machines makes me like pre build event model better for now especially if it gives me a way to trigger execution of tools\init.ps1 writtent to look for and if not present deploy shared content like snippets during build.   Perhaps the power tools will evolve to address these two matters.