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

We have been planning the new release (v.1.3.20.0) 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.1.3.20.0) 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.1.2.19.0) 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.

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

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 ? :|

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.

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?

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?

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 ;)

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

EM APIs are public. Just sayin' :P