http://blogs.clariusconsulting.net/kzu

Daniel Cazzulino's Blog

Go Back to
kzu′s Latest post

Building NuGet extensions in 10 minutes, or how to contribute to NETFx

From the documentation:

How to contribute

NETFx relies on the CodePlex mercurial fork/pull process for contributions. The explanation on how to contribute to NuGet applies roughly in its entirety to NETFx.

Install the NETFx Contributor VSIX from the Extension Manager.

Restart VS, and now you’ll get the NETFx Extension template:

netfx-new

Things to note:

  • The Location MUST be under the netfx\Extensions folder
  • The directory structure following Extensions is used to make up your extension id, in the above case, it will be “netfx-System.Net.Http.HttpResponseExtensions”
  • UNCHECK the “Create directory for solution” option, or otherwise you’ll end up with a duplicate name in the package ID and the folder structure. If you make this mistake (I do it all the time Smile), the easiest is to just kill the folder and start again.
  • Pick a name that is very specific to the helper/extension method you’re creating. For example, instead of “StringExtensions”, create a “StringNamedFormatExtension” if you’re creating an extension to System.String that allows named parameters to be passed. (that one already exists, it’s netfx-System.StringFormatWith Winking smile).
    This rule minimizes the chances of a single extension becoming too big and evolving into its own Common.cs hell.

 

The resulting structure is as follows:

netfx-source

 

The Package.tt is important. Here’s how the one for HttpClientQuery looks like:

netfx-packagett

Note that the version is dynamic, and every time you build or save the manifest, you get the build version incremented. So you never forget to push new versions Winking smile. If you want to make your package version 2.0.*, just open the dependent .nuspec file, make the major version 2.0, and let the .tt regenerate again. It will now increment the build of the version you specified, i.e. 2.0.0.1.

After you’ve gone through the red/green/refactor and you’re happy with your extension, building the Build project results in something like:

------ Build started: Project: Build, Configuration: Debug Any CPU ------
  Transforming template NuGet\Package.tt...
  Transforming template Pack.tt...
  Transforming template Push.tt...
  Attempting to build package from 'Package.nuspec'.
  Successfully created package 'Extensions\System\Net\Http\HttpClientQuery\Build\bin\netfx-System.Net.Http.HttpClientQuery.1.0.0.12.nupkg'.

Now you can open another instance of VS (or VS Experimental if you have the VSSDK), and add the bin path as a new package source for testing install/uninstall.

Now you can commit your extension, send a pull request, and for the NETFx team is just a matter of running your Push.ps1 Smile

D:\..> powershell .\Push.ps1
Pushing netfx-System.Net.Http.HttpClientQuery 1.0.0.12 to 'http://packages.nuget.org/v1/'...
Publishing netfx-System.Net.Http.HttpClientQuery 1.0.0.12 to 'http://packages.nuget.org/v1/'...
Your package was published.

Would be surprised if your extension doesn’t show up in mere minutes after approval of the pull request.

Now go and build your cool extension Smile

Comments