1

Closed

VS2012 does not load <WizardExtension> elements with partial assembly names

description

Issue
In VS2010, in a pattern toolkit project, an author may have one or more *.vstemplate files that contain their project and item templates. In those templates, at least two <WizardExtension> elements are defined, as such:
  <WizardExtension>
    <Assembly>NuPattern.Library, PublicKeyToken=ecdd31353928a4a5</Assembly>
    <FullClassName>NuPattern.Library.Automation.InstantiationTemplateWizard</FullClassName>
  </WizardExtension>
  <WizardExtension>
    <Assembly>NuPattern.Library, PublicKeyToken=ecdd31353928a4a5</Assembly>
    <FullClassName>NuPattern.Library.Automation.ElementReplacementsWizard</FullClassName>
  </WizardExtension>
The assembly names do not include the Version or Culture attributes, becuase this makes upgrading to new version of NuPattern much harder for the toolkit builder, and is currently a manual process.

In VS2012 however, the partial assembly names will not be loaded by VS. This is a change in behavior in VS2012, over what VS2010 did. Only fully qualified names will work, and so the assembly names need to include the Version and Culture attributes, viz:
 <WizardExtension>
    <Assembly>NuPattern.Library, Version=1.3.20.0, Culture=neutral, PublicKeyToken=ecdd31353928a4a5</Assembly>
    <FullClassName>NuPattern.Library.Automation.InstantiationTemplateWizard</FullClassName>
  </WizardExtension>
  <WizardExtension>
    <Assembly>NuPattern.Library, Version=1.3.20.0, Culture=neutral, PublicKeyToken=ecdd31353928a4a5</Assembly>
    <FullClassName>NuPattern.Library.Automation.ElementReplacementsWizard</FullClassName>
  </WizardExtension>
Resolution
The goal has always been to minimize manual changes in toolkit projects and their assets when new versions of NuPattern are released. For VSTemplates, this now seems unavoidable, where once the strategy was to avoid it.

At this time, there does not seem to be a hook into VS that can be intercepted to automatically interpret a partial name to a fully qualified name for VSTemplates.
Either a manual migraton process will be required when upgrading versions of NuPattern, or an automated process needs to be employed to upgrade existing pattern toolkit projects automatically when new versions of NuPattern are deployed.
Closed Apr 27 at 2:04 AM by jezzsa

comments

jezzsa wrote Feb 10 at 9:08 PM

For the 1.3.20.0 release, I believe there is not much we can do about this issue, as we have very little understanding (or confirmation from Microsoft) of why this issue has been introduced in VS2012.

At this time, we may have to proceed with this issue in this release (1.3.20.0), recognizing that it generates a necessary manual migration issue for the next release.

Perhaps, we can envison an auto-migration tool (or update feature in the pattern model) that can tackle this issue, as well as other minor ones with versioining in the next release. (post 1,3,20,0).

jezzsa wrote Apr 10 at 9:56 PM

I have a new idea, one that resolves the issue for a long time in both VS2010 and VS2012, that does not rely on partial assembly loading, and avoids the need to migrate existing templates (at least for a long time to come).

Let's build a new assembly in the code, say called: NuPattern.VisualStudio.Interop or some such name.
We fix the version number of this assembly to 1.0.0.0 or some such low version number that is unlikely to change until a major new release of NuPattern (NuPattern is at version 1.3.20.0 at present). We would only expect the version of NP.VS.Interop to change when we went to NuPattern 2.*.*.0.

We don't rev the version of this assembly like we rev the version of other assemblies on every release. This aligns with our versioning strategy for other things like schema files (whic I must also document).

This new assembly simply defines all the TemplateWizards types we have today (in both NP.VS and NP.Library), and derives from those types directly. In this sense, all the TemplateWizards in this assembly are version independent proxies to others. The interface we present to toolkit builders is stable, but the implementation is free to change as we evolve the code. New TemplateWizards can be added also.

We do however need a trick in the source code that uses the fixed version number of this new assembly without hardcoding that (as a string) in code that writes these TemplateWizards into existing templates, like the TemplateUriEditor does. Once we have this trick the assembly can be created and maintained independent of the versioned code.

Sign in to add a comment