NuGet.Tools.vsix install location

Jan 7, 2011 at 2:58 PM
Hey guys,
I'd like to understand the reasoning behind moving the VSIX install path to C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions, instead of having it under the user's profile path as most other extensions do (including the Productivity Power Tools, EF POCO generator, etc, etc.

This is the side-effect of the AllUsers manifest setting, which will seldom benefit developers, as we typically don't share our machines/laptops (in my experience, at least).

This does make it hard on contributors, which must uninstall the extension from the normal hive in order to develop and debug the tools :(, as explained in:


Make sure that the NuGet Extension is UNINSTALLED from your primary instance of VS so your newly compiled one can load into the experimental instance.

That warning wouldn't be needed, and the current approach gain doesn't seem to justify losing NuGet on the normal hive, IMHO.

Thoughts?

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471
Coordinator
Jan 7, 2011 at 3:29 PM

As far as I know, it’s probably because we didn’t know better. Would there be any side effects if we change it now for instances that are already installed? Such a change would only go into v1.1 so there will already be users with 1.0 installed.

Jan 7, 2011 at 4:05 PM

No, it's actually intentional. The reason is that NuGet is bundled into MVC Msi installer, which installs for all users. Hence we also decided to make NuGet install for all users to support update scenario and also avoid unpredictable situations. It's painful I know, but we have no other choice.

Jan 7, 2011 at 4:15 PM

What is the dependency between MVC and NuGet? I thought there was none.

Deploying them together in an MSI might be OK to get a wider audience, but the serviceability of per-user VSIXes vs AllUsers is exactly the same (so, not sure about what you mean by "support update scenario").

You will probably end up updating NuGet itself at a much faster pace than MVC (RTM) itself, so I'd say this is even detrimental for servicing. Leaving them separate (location-wise) clearly indicates they evolve independently and the MSI bundling being just a convenience.

Not sure what you mean by "unpredictable situations" either :(. If there is MVC design-time that depends on NuGet being installed, you will still have to check for its presence in the system, as the VSIX can be uninstalled/disabled anyway. 

Coordinator
Jan 7, 2011 at 4:22 PM

When you run the MVC MSI, it installs the NuGet vsix for you via a custom action. That’s equivalent to simply shelling out to the VSIX installer. That’s the extent of that dependency.

I’m not sure I understand why it would be a problem to have the NuGet VSIX installed as a per user VSIX since the MVC MSI has no dependency on the NuGet VSIX from an installation standpoint.

Jan 7, 2011 at 4:52 PM
Haacked wrote:

 

I’m not sure I understand why it would be a problem to have the NuGet VSIX installed as a per user VSIX since the MVC MSI has no dependency on the NuGet VSIX from an installation standpoint.

 It goes like this:

  1. User installs Nuget Vsix from Extension gallery. It gets installed only for this user.
  2. A few months later, we release a new MVC Msi installer, which includes a newer version of Nuget. This times it runs as Admin, so it doesn't know the user already installed the Vsix before. The user ends up having two separate versions of Nuget.
  3. When user tries to use Nuget, it's unpredictable. I'm not sure which version will be loaded by Visual Studio.
Coordinator
Jan 7, 2011 at 5:00 PM

Shoot. That’s right. It’s too late to change the version that’s in MVC. L

Jan 7, 2011 at 5:11 PM
The user ends up having two separate versions of Nuget

That will never happen. VS does not allow two vsixes with the same ID to be installed, regardless of location and version.

They will get asked to uninstall the previous one if the want the new one (or older one).

Jan 7, 2011 at 5:23 PM

OK, assume that's the case, isn't that undesirable? If user A installs the Vsix as normal user, and then a user B (who is admin) runs the Msi, B will override A's vsix without A's knowledge.

Note that it also applies the other way around:

  1. User B (admin) installs the Msi.
  2. A few months later, we release a newer version of Nuget on Extensions gallery.
  3. If user A (not an admin) wants to install from the gallery, he can't.

 

Jan 7, 2011 at 5:27 PM

I think any scenario that involves two distinct developers using the same machine is moot. I've never seen that in real life.

Running an MSI with admin permissions (UAC) != installing on another (admin) user profile.

Coordinator
Jan 7, 2011 at 5:36 PM

I agree with Kzu on this point. I think it’s very very rare for developers to share a development machine. We shouldn’t optimize for that scenario. However, if there are other problems that would be raised by making this change, it’s good to hash them out first and see if they’re acceptable.

What I don’t want to see is this.

1. User installs NuGet from MVC MSI.

2. New version is available in the VS Extension Gallery

a. Expected: User sees update

b. Bad: User is not notified of the update.

3. User upgrades from the VS Extension gallery

a. Expected: The VSIX is upgraded.

b. Bad: VSIX upgrade fails.

Regarding 3b. If upgrading fails because the current VSIX is installed by MVC, that’s not the end of the world if the fix is to uninstall the current one and then install from the VS Extension gallery. Because from then on, it should just work as we put out more updates.

Phil

Jan 7, 2011 at 5:39 PM
on 3b: but then the "other developers using the machine" would not have it anymore ;)

all that remains to be tested IMHO is whether an "AllUsers" vsix can be upgraded to a "normal" VSIX unattended from within VS via the regular update process for extensions via the EM.

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Fri, Jan 7, 2011 at 15:36, Haacked <notifications@codeplex.com> wrote:

From: Haacked

I agree with Kzu on this point. I think it’s very very rare for developers to share a development machine. We shouldn’t optimize for that scenario. However, if there are other problems that would be raised by making this change, it’s good to hash them out first and see if they’re acceptable.

What I don’t want to see is this.

1. User installs NuGet from MVC MSI.

2. New version is available in the VS Extension Gallery

a. Expected: User sees update

b. Bad: User is not notified of the update.

3. User upgrades from the VS Extension gallery

a. Expected: The VSIX is upgraded.

b. Bad: VSIX upgrade fails.

Regarding 3b. If upgrading fails because the current VSIX is installed by MVC, that’s not the end of the world if the fix is to uninstall the current one and then install from the VS Extension gallery. Because from then on, it should just work as we put out more updates.

Phil

Read the full discussion online.

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

To start a new discussion for this project, email nuget@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


Coordinator
Jan 7, 2011 at 5:42 PM

We don’t care about other users on the machine, remember? I’m just focused on the single user scenario. And yes, can a VSIX installed for AllUsers be upgraded to a normal VSIX via VS Extension manager? That’s the question we need to answer before we would make such a change.

Are you interested in trying that out? J

Phil

Jan 7, 2011 at 6:22 PM

Just tried:

- current user vsix -> allusers: works just fine

- allusers -> current user vsix: starts to uninstall, presents eula, etc., but fails to install with a file not found exception (that is looking at the Program Files folder previous location). But the allusers extension is properly uninstalled. It's just VS that doesn't seem to take notice, and requires a VS restart. When you're back, you install the vsix like any other as if it was the first time.

 

So the guidance could be to uninstall the MSI-provided one first (if there's no chance to make it per-user already) before updating. But worst case, a simple VS restart fixes everything.

Developer
Jan 7, 2011 at 11:25 PM

Another user posted an issue similar to what Luan experienced. Itd be great if installing from the vs gallery and the msi did the same thing.

Jan 8, 2011 at 1:02 AM

Our current behavior is a compromise we settled on based on recommendation from VS Gallery team.

As all setup issues, there are lots of convoluted cases that can affect user experience. This is especially true for case when an extension is installed both through MSI and Gallery. We should sync with Jacques and VS team again if we think we need to change current behavior. Even if we can’t change it, it could be useful to post reasons that led us to this situation.

Thanks,

Sonja