Using NuGet packages in Visual Studio 2012 project templates

Anyone creating Visual Studio project templates these days should be using NuGet package references for project dependencies — it saves you having to update your templates every time a dependency changes, and follows a standard & generally accepted binary dependancy approach.

If you’re distributing your project template as a VSIX package (strongly recommended) the NuGet docs here specify the preferred approach is to include the .nupkg files within the VSIX, but the instructions specify the addition of a ‘CustomExtension’ element to the .vsixmanifest file that is no longer valid in v2 of the VSIX schema (the default in Visual Studio 2012). I spent a considerable period of time attempting to work out what the v2 equivalent of CustomExtension was, but to cut a long story short, you don’t need to make any changes to the .vsixmanifest — it’s enough to include all of the packages in the VSIX under a ‘Packages’ directory.

Following are the steps I used to create a working 2012 VSIX project template:

  1. Download and install the Visual Studio 2012 SDK, if you haven’t done so already.
  2. Create a solution and add a ‘C# Project Template’ project and a ‘VSIX Project’ project (under ‘Visual C# > Extensibility’). It amuses me no end that there’s a project template project template. I am easily amused though.
  3. Set up your project template the way you want it. I find it easier to create a temporary project, use ‘File > Export Template…’ and then unzip the package and copy the relevant bits across.
  4. Update your .vstemplate with the ‘WizardExtension’ and ‘WizardData’ elements like the following:
      <WizardExtension>
        <Assembly>NuGet.VisualStudio.Interop, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly>
        <FullClassName>NuGet.VisualStudio.TemplateWizard</FullClassName>
      </WizardExtension>
      <WizardData>
        <packages repository="extension" repositoryId="<!-- your VSIX Product Id -->">
          <!-- your NuGet package dependencies go here, eg: -->
          <package id="Moq" version="4.0.10827" />
          <package id="xunit" version="1.9.1" />
          <package id="xunit.extensions" version="1.9.1" />
        </packages>
      </WizardData>
    
  5. Double-click on the source.extension.vsixmanifest to open it in the designer, and add a new Asset. Select ‘Microsoft.VisualStudio.ProjectTemplate’ as the type, “a project in the current solution” as the source, and then choose your template project. See this blog post for more info about this approach.
  6. Create a folder under your VSIX project called ‘Packages’ and drag the .nupkg files (referenced in the .vstemplate above) into this folder. Set the Build Type on the files to ‘Content’ and ‘Include in VSIX’ to ‘True’.
  7. Build the solution – it will produce a VSIX that includes the NuGet dependencies. You’re done!

It’s more correct to also add the NuGet Package Manager extension as a dependency to your VSIX, although I don’t usually bother for our internal templates.

One of the great things about VSIX distribution is that you can add multiple project & item templates to a single package as a discrete, easily distributable approach (just add more assets to the vsixmanifest).

Advertisements

Apps can’t link to the internet

Some App Store reviewers appear to be taking an extremely hard line on review guideline 11.13:

Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected

One of our apps was pinged for this despite having no purchase mechanism outside IAP, no purchase options on our website, no links to third parties like DropBox, and nothing else other than a couple of PDF download links in app. When asked for clarification, the Review Team responded with:

“remove any links that link out of the app and external links in the application description.”

Apparently linking to ‘The Internet’ might indirectly lead the user to purchase something outside of the App Store. I’d like to think that this is a single reviewer that’s received dud training; if not I expect Apple will need to update 11.13 to explicitly ban external links.

Update: An attempt to clarify whether all external links are in fact banned, or whether the reviewer felt there was an external purchase mechanism buried somewhere on our site, was rebuffed with:

“Thank you for your feedback. If you wish to appeal your review, you can submit a request to the App Review Board.”