From the documentation:
How to contribute
Install the NETFx Contributor VSIX from the Extension Manager.
Restart VS, and now you’ll get the NETFx Extension template:
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 ), 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 ).
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:
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 . 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. 188.8.131.52.
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.184.108.40.206.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
D:\..> powershell .\Push.ps1 Pushing netfx-System.Net.Http.HttpClientQuery 220.127.116.11 to 'http://packages.nuget.org/v1/'... Publishing netfx-System.Net.Http.HttpClientQuery 18.104.22.168 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