nuspec metadata extensibility

Jan 7, 2011 at 3:31 PM

I don't think this was asked before, so here's my scenario:

I'd like to extend the package metadata information with data that can be used by a powershell script. Typical example:
<package ...>
       <vs:reference xmlns:vs="vs-automation">PresentationFramework<vs:reference>
This metadata information could be read (plain XML reading from powershell on init.ps1 for example or install.ps1) and some action could happen (in this case, adding a reference to a library that is not included in lib but which is necessary maybe for some content files?
Another example:
(you get the idea :))
I've added this support in the schema as well as the code, added a unit test and made sure the rest still run green. Essentially, added an <xs:element name="extensions"> element to the metadata <xs:all>, and inside that, allowed any attribute (on ##other namespaces) as well as any element (both on ##other as well as ##local -that is, empty- namespace). This way, we prevent potential collisions if the nuget schema is evolved in the future with more elements, even under <extensions> (say nuget starts using this as a general-purpose extensibility/automation mechanism itself).
My fork is at Changes were pretty trivial and very focused.
Is this useful (I know it would be for me!)? Thoughts?


Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471



Jan 7, 2011 at 4:49 PM

Out of curiosity, if you have metadata specific to your package, why not just add another custom metadata file to your package?

Jan 7, 2011 at 5:29 PM

But then I'd have to manage different aspects of my package metadata in separate files, when it may be conceptually all part of the same thing.

But you're right, I could have an extra file in the package, say, vsautomation.xml, and invoke a dependency-provided command to process it:

  <dependency id="FancyVsAutomation" version="1.0.0" />

and install.ps1 could have a single line like:

Process-VsAutomation $installPath, $project

(or whatever)

Still feels like some out of the box extension processing should be possible and cool, so that package authors can just declare their dependency and leverage plain markup to make things happen.

Say the "FancyVsAutomation" had a powershell hook to say "I can process extensions of namespace http://foo", and NuGet would automatically call it on init/install/uninstall of any package that uses extensions in that namespace....


I think it could be pretty powerful to add mini-dsls via XML that can be easily implemented in powershell by extension authors. Just brainstorming :). I can give that full automatic thing a try if you think it's worth it.

Jan 7, 2011 at 5:37 PM

I’m not opposed to making NuSpec extensible in that way. I just haven’t put much thought behind it. I guess you could experiment with both approaches and let us know the pros/cons for each. J

Jan 7, 2011 at 7:48 PM

I accepted the @async change but have to reject the xsd schema change. I think it's better to keep the .nuspec file clean. We have many components which depend on it, including the gallery server. You can easily add a custom file to your package which contain extra medata for your needs.
Not sure if this means a decision has been made already or if you still think it's worth exploring this idea.
Changes in the schema have no impact on anything else as it's just one more optional element in the metadata, with skip processing for anything inside it. 
Jan 8, 2011 at 12:19 AM

How do you consume the custom metadata?

Jan 8, 2011 at 4:17 PM

I'm gonna experiment with the external solution first (a plain xml alongside the spec file, and powershell that locates it by convention)

Feb 1, 2011 at 12:23 AM


I have a similar requirement.
I'm using NuGet to allow people to extend my web application. A power user will be able to select an extension from a back-office and it will add feature to the system (as Orchard do). These extensions are specific to our application and we need to add some parameters.

I've got 2 ways :

  1. Add my custom metadata file to the package and get it from the ZipPackage class
  2. Extend the current .nuspec file by adding xml namespace, etc.

From what I read here, the solution #2 would be the best. This confirms my choice, do you agree?


Dec 26, 2012 at 2:46 AM

I have an interest similar to that expressed by cdurand.  That is, consolidation of nuspec metadata with custom "plugin" metadata.  I would like to add a namespace to the root package:

<package xmlns="" xmlns:shrm="">...

If I do that, and start adding package sub-elements with the "shrm" namespace, can I still upload nuget packages to the package source?  Will nuget strip-out my extraneous namespace data or reject the upload?

If the answer is "you must create your own custom nuget repository, with a custom nuget XSD for this", then this is not what I want.  Curious... 

Dec 26, 2012 at 7:00 PM

I don't know for sure either. The best way to know is to try it yourself. To avoid polluting the main feed, you can upload your package to

Jan 25, 2013 at 11:45 PM

Did you ever figure this out?

Oct 19 at 6:37 PM
Whatever became of this?