NuPattern Release Hosting Plan

Jan 29, 2013 at 1:11 AM

Just wanted to get some of this detail down, for those interested.

We have been planning the new release (v. of NuPattern to be as soon as possible. We are currently waiting to resolve one last dependency issue. After which, the release will go out, and we can then start to tackle our backlog of new features and issues in subsequent (significantly shorter) release cycles.

We will need to change how and where we host the deliverables to maximize user experience and minimize complexity and management.


Since the new release (v. includes two separate versions of the deliverables (one for VS2010 and one for VS2012) we have needed to change our strategy on where to host the releases. In the previous version of VSPAT (v. we had a VSIX for the Pattern Toolkit Builder and a VSIX for the Hands On Labs. We host all the released deliverables (VSIXes, HOL, docs) on this site ('Downloads' tab) AND the VSIXes on the VSGallery. The VSGallery provides the most integrated option for people to discover, download and install the VSIX extensions. And this codeplex site provides the best option for hosting documentation, and tracking the project.

However, in the new release we will need to host 4 separate VSIXes: NuPattern Toolkit Builder for VS2010, NuPattern Toolkit Builder for VS2012, Hands On Labs for VS2010, and Hands On Labs for VS2012. They are all separate packages.

It seems a waste to (and overly complex to manage) 4 separate pages on the VS Gallery for what amounts to two of the same deliverables (albeit targeted at different version of VS). Especially because at some point in the future we may be able to consolidate the differences between VS versions into the same deliverable that works in both versions of VS.

A different hosting strategy might now be employed that removes the immediate confusion and management complexity, but that can be improved over time should it be possible.

The VSGallery supports hosting a redirection URL instead of a VSIX binary, and that URL can redirect to the latest version of the deliverables in the 'Downloads' page on this site. And users can see the obvious distinction between which version they need to download for their version of VS.

In this way, we can maintain the current VSGallery pages (there are currently two), persist their feedback and ratings there, and consolidate the hosting to one authoratative site.

We will not lose any ability to browse, download and install the VSIXes from within Visual Studio, althought the experience is slightly different, and to be fair a bit downgraded. But still more acceptable than having 4 different sites on the VSGallery, 4 sets of feedback, confusion and complexity etc. 

The only challenge is whether we can keep the existing two VSGallery pages, and revert them back to hosting a redirection URL, since they are already configured to host a VSIX.  We are investigating that issue now with the VSGAllery owners. If we cannot revert, then we may have to abandon the existing pages, delete them and create new ones, losing our ratings, history and feedback! which is not desirable.

Jan 29, 2013 at 5:58 PM

Redirection download URLs aren't a good integrated experience on VS at all. I personally hate it when I get redirected to some webpage instead of installing right there from within VS. More so when the ultimate binary is a VSIX.

Also, feedback (especially bugs!) should mostly happen on the codeplex project, which is much easier to discuss on, track as work items, releases for fixes, etc. The feedback on the VSGallery is pretty useless, if you ask me. Especially for the runtime/authoring, which assumes the person already knows what he's looking for (i.e. it's NOT like looking for "Refactoring" or the like). People will mostly use NuPattern indirectly as part of an actual toolking.

So, I'd stick to vsix downloads and four pages. Isn't it possible to merge the HOLs into a single VSIX? Doesn't look like it would have dependencies on VS-specific versioned assemblies... 

Jan 29, 2013 at 8:06 PM
Edited Jan 29, 2013 at 8:17 PM

None of this is ideal. The options are limited, and it comes down to a tradeoff. I know the install experience is downgraded, other than going to MSI we have to compromise somehow. The root cause of this drama is the binary incompatibility between the two versions of VS, which we can cope with right now.

Ideally we would have one VSIX that would install into both versions of VS but technically not possible in this timeframe. It will take some really long hard work to say: factor all the VS dependencies out of all the assemblies we have, behind say some set of interfaces, and load the correct VS implementation at runtime (that's one technical option).

So, for now at least, we are stuck with two authoring VSIXes, and two HOL VSIXes for now. Although I think you might be right about having one HOL VSIX, nice catch.

The VSGallery also has a big constraint showstopping that is very hard to deal with in our particular case. When you upload a VSIX to the gallery, the gallery stores the VSIX ID. You cannot create more than 1 page on the gallery with the same VSIX ID. I have already tried and tested this. I also went through the activity (it took weeks of refactoring and testing) to have unique VSIX ID's but this causes huge problems downstream for toolkit builders. (I will spare you the fine details here, but it proved to be a nightmare and it just snowballs the original compatibility issues created by VS in the first place).

So effectively, to keep life simple for toolkit builders, we have to keep the same VSIX ID for both versions of the all our VSIXes, and this permits us to figure out the cross-VS dependency stuff later.

I agree with you about feedback, should be on codeplex, but I am not sure I can prevent people posting that on the gallery? I am really more concerned about keeping our download count, ratings and reviews.

So really, we have these options:

  • Unique VSIX ID's for 2x Authoring VSIX, and upload to on 2 pages in gallery - best install experience, technically possible, should not cause downstream issues for toolkit builders
  • Same VSIX ID's for 2x Authoring VSIX, and redirect with URL to codeplex - downgraded install experience, no downstream issues.
  • Explore MSI options. - have a seperate set of issues

 Geez, when I put it like this, option 1 is clearly the answer. What have I missed ? :|

Jan 29, 2013 at 8:26 PM

Oh yeah, that is what I missed.

It took so long to try and test out the multiple VSIX ID things that I it came down to an all or nothing decision about having multiple VSIX ID's which does not necessarily have to be the case, now we have laid it out and looked at it again. Thanks kzu.

In theory, we would need multiple VSIX ID's only for VSIX that are hosted on the gallery, which for us is the Authoring and HOL VSIX. But not the Runtime VSIX. It is really the Runtime VSIX with multiple VSIX ID's that causes downstream issues for toolkit builders.

So, lets say we keep the Runtime VSIX with a single VSIX ID. We have seperate VSIX ID's for the Authoring VSIX. So, that will force seperate VSIX ID's for the HOL VSIX. We are back to 4 pages on the gallery, but the best install experience, and no downstream toolkit issues.

I think that's what we need to do.

Jan 29, 2013 at 8:45 PM

Sounds good.

I'm still not sure why the HOLs would need two VSIXes. You can just document the dependency and have the user manually install the NuPattern authoring VSIX. I believe that should be the only place where you'd be referring to the VSIX ID, therefore, just removing that declarative dependency, you could end up with a single page/entry for the HOL?

Jan 29, 2013 at 8:56 PM

Yeah, we *could* just document the dependency but then people are going to just install the HOL VSIX without installing the Authoring VSIX first - no matter what we say, and I think it will generate a lot of unecessary pain, and user dissat. Remmember, from VS Extension Manager you dont get to read any installation notes. You just click the install button, and expect magic to happen. If the VSIX installer does not fail, then the user is going to think everything is fine, and wonder why it does not work, and abandon us.

Its all avoidable by putting in the VSIX dependency declaration in the HOL VSIXmanifest. And becuase the Authoring VSIX could have one of two ID's depending on your version of VS, we need two HOL VSIXes to resolve that. Does that make sense?

Jan 29, 2013 at 9:06 PM

Unless you code some "first run" code that looks for the authoring vsix, and if it doesn't find it, invokes the extension manager APIs directly to do a silent install and ask for reboot later ;)

Jan 29, 2013 at 9:51 PM

Now come on now.... Lets stick to what is supported by VSIXes for the time being.

Jan 29, 2013 at 9:53 PM

EM APIs are public. Just sayin' :P

Feb 7, 2013 at 12:04 AM
OK, I am looking at this again. And, No the answer became no evident by just sleeping on it for a while. :(

I wrote up the issue [workitem:27], with some more detail.

The latest news is that the VS Gallery owners have offered to manually change our current VS Gallery sites from VSIX to URL (manually), but that this is a one-way transaction, and no going back once manually changed without deleting and starting again. So that kind of forces the issue and requires a go/nogo commitment from us on whether to go with once and for all the URL! I dont like to have my back up against the wall by any jobs-worth MS SDE, so I am looking at other options that leave the control with us.

To me the decision comes down to one of two top options below:
Option 1: Go with what is supported by VSGallery today, and have unique VSIXID's on the two VSIXes we have for VS2010 and for VS2012. Understanding that we are creating a difficult future migration problem for authors of toolkits with different VSIX ID's.
Option 2: Create an single MSI that installs either/both versions of the VSIX on the users machine using the VSIXInstaller (sliently). No unique VSIXIDs, keep current gallery page, no redirections. In fact, a neater release package altogether.
Option 3: Use a URL redirection on the gallery, to the codeplex releases. Understanding that this seriously compromises the install experience for the user, and is irreversable.

Since, this is whole issue is a workaround for the time being, (until we get one VSIX for both versions of VS, at which point we deploy just the dual-version VSIX, and this problem goes away), I am in favor of going with MSI for the time being.
  • This MSI replaces the current VSIX on the gallery - i.e. we keep all our: Gallery URL, download count, reviews, ratings etc.
  • The MSI targets both versions of VS, no user confusion, no user awareness of version issues, "who really cares anyway - just make it work!".
  • The MSI is installed directly from the Extension Manager in VS, no redirection.
  • The MSI is smart and checks pre-requisite VSIXes, and installs both versions of the VSIX if needed on the machine, using the VSIXInstaller silently
  • To the user, it is an MSI dialog, not a VSIX installer dialog, but (a) there is no chance they will try to install the wrong version of the VSIX, (b) they wont have to install both versions of the VSIX for both versions of VS (if they have them installed side-by-side).
  • The MSI uses VSIXInstaller silently, so really its a handy shortcut for the user, and they can manage the VSIX in Extension Manager as before.
    Note: this MSI is NOT going to be using the <InstalledByMSI> setting in a vsixmanifest, because our intention is to install using the VSIXInstaller, and we dont care if the user uninstalls the VSIX manually in Extension Manager. The MSI was only going to use VSIXINstaller /u to uninstall what it already installed anyway! no net loss.
Note, we will have to trial making this kind of MSI, and ensure that there are no issues with using it to install VSIXes, but conceptually it seems like a good workaround for now.
And later, when we are in a better position, we can just replace teh MSI with the dual-version VSIX.

Anyone dissagree that this is our best option at this time? and you can put a case for the other 2 options over this one?
Need to speak up now!
Feb 8, 2013 at 3:07 PM
+1 msi (lesser evil)
Feb 8, 2013 at 8:51 PM
Just spent the last 2 days creating the proposed MSI, to see what real issues we may face with implementing this concept.

So far, I am happy to report that: while there are some interesting edge cases I have discovered along the way, I have been able to create an MSI that does the job very well, and meets all of the requirements, and deals with the discovered edge cases well enough.

The only usability issues I have found are:
  1. The MSI is about 100MB in size (because it contains all 4 VSIXes), and therefore takes some time to download from the Gallery page. But it is a nice experience to install all four VSIXes in one shot.
  2. I got some security warning from Internet Explorer that says "Normally this kind of file is not downloaded", and then you go through a windows dialog box that makes it hard for me to choose the ' Not Recommended' option of "Run Anyways". Which I actually read as "Run Away" at the time! :)
    So I am thinking that we need to sign the MSI to overcome this security un-usability, (or try going with an EXE instead - is that going to be any different?).
I'd like to get others opinions, so I will post the MSI for us to try out soon, and get some feedback on the experience.
Feb 9, 2013 at 12:22 AM
I'm pretty sure it will be the same with an exe.

Regarding size: I guess you already re-compressed with maximum compression using 7zip instead of the default VS (lack of) built in compression of the output vsixes, right?
Feb 9, 2013 at 1:33 AM
Nah, not optimized compression of vsix yet.
Can worry about that when signing happens.
Looks like the cab compression is getting us way down in size though.
Feb 9, 2013 at 10:01 AM
OK, I am quite pleased with the current result of the MSI.
You can see on teh wiki a page that documents how it works and what teh series of screeens looks like.

Please let us know if you like it.